From report at bugs.python.org  Mon Aug  1 00:17:37 2011
From: report at bugs.python.org (python272)
Date: Sun, 31 Jul 2011 22:17:37 +0000
Subject: [issue12640] test_ctypes seg fault (test_callback_register_double);
	armv7; gcc 4.5.1
In-Reply-To: <1311637071.74.0.758300374846.issue12640@psf.upfronthosting.co.za>
Message-ID: <1312150657.57.0.641164492538.issue12640@psf.upfronthosting.co.za>


python272 <letters.random13 at gmail.com> added the comment:

problem also occurs when built with configure option --with-system-ffi
not sure whether it might be a compiler bug or an invalid test?

some debug output:
[@localhost Python-2.7.2]$ gdb ./python
(gdb) run -Wd -3 -E -tt  ./Lib/test/regrtest.py -v test_ctypes

...
test_ushort (ctypes.test.test_callbacks.Callbacks) ... ok
test_callback_register_double (ctypes.test.test_callbacks.SampleCallbacksTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
0x99999998 in ?? ()
(gdb) where
#0  0x99999998 in ?? ()
#1  0x40409718 in _testfunc_cbk_reg_double (a=5.5, b=1.1964487668029418e-47,
    c=1.001023, d=0, e=1.5999999999999999e-05, func=0x9999999a)
    at /home/Python-2.7.2/Modules/_ctypes/_ctypes_test.c:39
#2  0x41edc9a0 in ffi_call_SYSV () from /usr/lib/libffi.so.5
#3  0x40160000 in slot_tp_iter (self=Cannot access memory at address 0xffffffe0
) at Objects/typeobject.c:5579
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

the referenced file snippets:

/home/Python-2.7.2/Modules/_ctypes/_ctypes_test.c

     35 EXPORT(double)
     36 _testfunc_cbk_reg_double(double a, double b, double c, double d, double         e,
     37                          double (*func)(double, double, double, double,         double))
     38 {
     39     return func(a*a, b*b, c*c, d*d, e*e);

/home/Python-2.7.2/Objects/typeobject.c

   5567 static PyObject *
   5568 slot_tp_iter(PyObject *self)
   5569 {
   5570     PyObject *func, *res;
   5571     static PyObject *iter_str, *getitem_str;
   5572
   5573     func = lookup_method(self, "__iter__", &iter_str);
   5574     if (func != NULL) {
   5575         PyObject *args;
   5576         args = res = PyTuple_New(0);
   5577         if (args != NULL) {
   5578             res = PyObject_Call(func, args, NULL);
   5579             Py_DECREF(args);
   5580         }
   5581         Py_DECREF(func);
   5582         return res;
   5583     }

----------

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

From report at bugs.python.org  Mon Aug  1 00:37:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 22:37:36 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1312151856.32.0.522660107261.issue12669@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Correction: the offending options are -j and *-W* (display test output on
failure), not -w (re-run failed tests in verbose mode).

----------

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

From report at bugs.python.org  Mon Aug  1 00:47:58 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 22:47:58 +0000
Subject: [issue12670] Fix struct code after forward declaration on ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/004974.html here's a patch (applicable on 2.7, 3.2 and 3.3) to fix the struct declaration in the "forward declaration" example.

----------
assignee: docs at python
components: Documentation
files: ctypes_fwd_declaration-default.patch
keywords: patch
messages: 141480
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix struct code after forward declaration on ctypes doc
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22814/ctypes_fwd_declaration-default.patch

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

From report at bugs.python.org  Mon Aug  1 01:04:49 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 31 Jul 2011 23:04:49 +0000
Subject: [issue12671] urlopen returning empty string
In-Reply-To: <1312153489.91.0.210559170724.issue12671@psf.upfronthosting.co.za>
Message-ID: <1312153489.91.0.210559170724.issue12671@psf.upfronthosting.co.za>


New submission from Matthew Barnett <python at mrabarnett.plus.com>:

Someone over at StackOverflow had a problem with urlopen in Python 3.2.1:

    http://stackoverflow.com/questions/6892573/problem-with-urlopen/6892843#6892843

This is the code:

    from urllib.request import urlopen
    f = urlopen('http://online.wsj.com/mdc/public/page/2_3020-tips.html?mod=topnav_2_3000')
    page = f.read()
    f.close()

With Python 3.1 and Python 3.2 it works OK, but with Python 3.2.1 the
read returns an empty string.

----------
components: Library (Lib)
messages: 141481
nosy: mrabarnett
priority: normal
severity: normal
status: open
title: urlopen returning empty string
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Aug  1 01:05:39 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 31 Jul 2011 23:05:39 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312153539.67.0.356614913431.issue12562@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Reason you are seeing the failure for this is following change from 2.5 in mmapmodule.c (:1109):

m_obj->data = (char *) MapViewOfFile(m_obj->map_handle,
				     dwDesiredAccess,
				     0,
				     0,
				     0);

changed to mmapmodule.c (:1414 in 3.3):

m_obj->data = (char *) MapViewOfFile(m_obj->map_handle,
                                     dwDesiredAccess,
                                     off_hi,
                                     off_lo,
                                     m_obj->size);

Previously size wasn't passed to MapViewOfFile. Passing new size to MapViewOfFile greater than the size of previous map causes an error. 

This seems to be by design. From MSDN:

MapViewOfFile:

dwNumberOfBytesToMap [in]
The number of bytes of a file mapping to map to the view. All bytes must be within the maximum size specified by CreateFileMapping. If this parameter is 0 (zero), the mapping extends from the specified offset to the end of the file mapping.

CreateFileMapping:

lpName [in, optional]
The name of the file mapping object.

If this parameter matches the name of an existing mapping object, the function requests access to the object with the protection that flProtect specifies.

So on second call, CreateFileMapping will get back the previous mapping object, which has 4096 bytes of memory mapped. MapViewOfFile will try to map beyond its limit and get an error.

I am curious how "resizing" worked before. I tried passing size=0 to MapViewOfFile on second call (length=8192) then call VirtualQuery on the returned map, which can query the size of the buffer. Size is still 4096. So even if length=8192 and we call CreateFileMapping with this length, it will return the previous 4096 byte-buffer.

This looks to me like an issue which existed until Python 2.5, namely this error was silenced and returned map was still 4096 bytes, just claiming to be 8192. The way it is behaving now seems to be the correct way.

----------
nosy: +vladris

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

From report at bugs.python.org  Mon Aug  1 01:16:22 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 31 Jul 2011 23:16:22 +0000
Subject: [issue12671] urlopen returning empty string
In-Reply-To: <1312153489.91.0.210559170724.issue12671@psf.upfronthosting.co.za>
Message-ID: <1312154182.22.0.428968863013.issue12671@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Just been told this bug has already been reported as issue #12576.

----------
resolution:  -> duplicate

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

From report at bugs.python.org  Mon Aug  1 01:16:57 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 31 Jul 2011 23:16:57 +0000
Subject: [issue12671] urlopen returning empty string
In-Reply-To: <1312153489.91.0.210559170724.issue12671@psf.upfronthosting.co.za>
Message-ID: <1312154217.94.0.688595284331.issue12671@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Mon Aug  1 01:31:32 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 31 Jul 2011 23:31:32 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312155092.22.0.0829826197956.issue11651@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I have attached a Python script which does what Antoine's patch does except
> which is expected to live in Tools/scripts. The perk of doing this in a
> Python script is that Windows users will be able to simply execute the script
> while the Makefile can be made to execute the script itself for those that
> prefer ``make test`` over ``./python Tools/scripts/run_tests.py``.

I've attached a patch that reworks the Makefile test targets to use this script
(with some minor modifications).

Some notes:
- By doing things this way, we lose the ability to specify custom arguments to
  the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
- The "test" and "quicktest" targets now use "-u all,-largefile,-audio,-gui",
  which permits more tests to be run. On my current system, this adds about 20s
  to the running time for "make test" (~3m45s instead of ~3m25s).
- regrtest.py now accepts "-u none", explicitly specifying the default setting
  (to override the setting used by run_tests.py). This isn't strictly necessary,
  but it seemed good to have, for the sake of completeness.
- I've changed the meaning of "-j 1" -- instead of using a single subprocess, it
  runs the tests directly in the current process. This allows us to use the
  run_tests.py script for "make buildbottest" and still have the exact same
  semantics (using even one subprocess can cause problems for e.g. test_curses).

Any thoughts?

----------
Added file: http://bugs.python.org/file22815/test-runner.patch

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

From report at bugs.python.org  Mon Aug  1 02:01:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Aug 2011 00:01:24 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312156884.94.0.660499732332.issue12648@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as I know, not as a top-level module in an installed version of Python (at least, not without mucking about in the registry).

Shadowing standard library modules is generally a bad idea, and this is one of the reasons.

----------

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

From report at bugs.python.org  Mon Aug  1 02:58:27 2011
From: report at bugs.python.org (Ann Elliott)
Date: Mon, 01 Aug 2011 00:58:27 +0000
Subject: [issue7089] shlex behaves unexpected if newlines are not whitespace
In-Reply-To: <1255075914.03.0.04545559487.issue7089@psf.upfronthosting.co.za>
Message-ID: <1312160307.32.0.574348064971.issue7089@psf.upfronthosting.co.za>


Ann Elliott <elliott.222 at osu.edu> added the comment:

This error still occurs in version 3.3.0a0.

----------
nosy: +elliotta
versions: +Python 3.3

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

From report at bugs.python.org  Mon Aug  1 04:38:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Aug 2011 02:38:42 +0000
Subject: [issue12668] 3.2 What's New: it's integer->string, not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <1312166322.01.0.848433149485.issue12668@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug  1 05:54:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 01 Aug 2011 03:54:54 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Reading the C API documentation: extending/newtypes.html

Some problems:

1. In the first paragraph of 2.1 - "to distinguish them from things like [].append", it's unclear what [].append is. Maybe "[] and append"?
2. The C coding convention is unusual and non PEP-7 in 2.1.1 (after "if (self->first == NULL)" in Noddy_new)
3. The previous problem repeats in other instances of Noddy_new in the document


I found these while reading the 2.7 docs, but they could also exist in 3.x (didn't check).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141487
nosy: docs at python, eli.bendersky
priority: low
severity: normal
status: open
title: Some problems in documentation extending/newtypes.html
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  1 06:13:29 2011
From: report at bugs.python.org (shane moore)
Date: Mon, 01 Aug 2011 04:13:29 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1312172009.92.0.536988035763.issue12659@psf.upfronthosting.co.za>


Changes by shane moore <dstory23 at gmail.com>:


----------
nosy: +shane.moore

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

From report at bugs.python.org  Mon Aug  1 08:00:10 2011
From: report at bugs.python.org (rpointel)
Date: Mon, 01 Aug 2011 06:00:10 +0000
Subject: [issue12673] SEGFAULT error on OpenBSD (sparc)
In-Reply-To: <1312178410.91.0.482012755622.issue12673@psf.upfronthosting.co.za>
Message-ID: <1312178410.91.0.482012755622.issue12673@psf.upfronthosting.co.za>


New submission from rpointel <python at xiri.fr>:

Hello,

on OpenBSD (arch: sparc), I got a SIGBUS error during the compilation.

gdb info:
#0  0x089f136c in listextend (self=0xb6232d8, b=0xb611060) at /home/ports/pobj/Python-2.7.1/Python-2.7.1/Objects/listobject.c:838
838                 Py_INCREF(o);
(gdb) list
833             /* populate the end of self with b's items */
834             src = PySequence_Fast_ITEMS(b);
835             dest = self->ob_item + m;
836             for (i = 0; i < n; i++) {
837                 PyObject *o = src[i];
838                 Py_INCREF(o);
839                 dest[i] = o;
840             }
841             Py_DECREF(b);
842             Py_RETURN_NONE;
(gdb) print src
$1 = (PyObject **) 0xb61106c
(gdb) print i  
$2 = 1
(gdb) print *src
$3 = (PyObject *) 0x8d8afdc
(gdb) print src[i]
$4 = (PyObject *) 0x0

Attached file is the complete log file.

Thanks,

Remi.

----------
components: Installation
files: python_segfault_sparc.log
messages: 141488
nosy: rpointel
priority: normal
severity: normal
status: open
title: SEGFAULT error on OpenBSD (sparc)
versions: Python 2.7
Added file: http://bugs.python.org/file22816/python_segfault_sparc.log

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

From report at bugs.python.org  Mon Aug  1 08:30:25 2011
From: report at bugs.python.org (kota)
Date: Mon, 01 Aug 2011 06:30:25 +0000
Subject: [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312180225.82.0.960530415846.issue12648@psf.upfronthosting.co.za>


kota <nospam.kotarou.dono at gmail.com> added the comment:

Ok. Time to get those people over at glib to fix up their python script then :)

----------

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

From report at bugs.python.org  Mon Aug  1 08:46:31 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 01 Aug 2011 06:46:31 +0000
Subject: [issue12631] Mutable Sequence Type in .remove() is consistent only
	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1312181191.49.0.0136652567379.issue12631@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Mon Aug  1 09:51:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Aug 2011 07:51:56 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1312185116.31.0.40103153838.issue12170@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See also #12631 regarding the remove() method for bytearray.

----------

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

From report at bugs.python.org  Mon Aug  1 11:04:13 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 01 Aug 2011 09:04:13 +0000
Subject: [issue12170] index() and count() methods of bytes and bytearray
	should accept byte ints
In-Reply-To: <1306266550.46.0.554812052221.issue12170@psf.upfronthosting.co.za>
Message-ID: <1312189453.28.0.382849413849.issue12170@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> See also #12631 regarding the remove() method for bytearray.

AFAICS, it's about bytearray.remove() working but bytearray.index() not working as documented, and that's why I marked is as a duplicate of this issue.

----------

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

From report at bugs.python.org  Mon Aug  1 12:33:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 10:33:11 +0000
Subject: [issue12667] Better logging.handler.SMTPHandler doc for 'secure'
	argument
In-Reply-To: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>
Message-ID: <E1Qnpo4-00044e-As@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 42f40f53fd73 by Vinay Sajip in branch '2.7':
Closes #12667: Corrected documentation for SMTPHandler secure argument.
http://hg.python.org/cpython/rev/42f40f53fd73

New changeset ba5bd8c1ae27 by Vinay Sajip in branch '3.2':
Closes #12667: Added documentation for SMTPHandler secure argument.
http://hg.python.org/cpython/rev/ba5bd8c1ae27

New changeset 2d69900c0820 by Vinay Sajip in branch 'default':
Closes #12667: Merged fix from 3.2.
http://hg.python.org/cpython/rev/2d69900c0820

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

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

From report at bugs.python.org  Mon Aug  1 13:38:25 2011
From: report at bugs.python.org (rpointel)
Date: Mon, 01 Aug 2011 11:38:25 +0000
Subject: [issue12673] SEGFAULT error on OpenBSD (sparc)
In-Reply-To: <1312178410.91.0.482012755622.issue12673@psf.upfronthosting.co.za>
Message-ID: <1312198705.26.0.0605792218708.issue12673@psf.upfronthosting.co.za>


rpointel <python at xiri.fr> added the comment:

This bug seems to be the same than 7424:
http://bugs.python.org/issue7424
Sorry I didn't seen it before.

----------

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

From report at bugs.python.org  Mon Aug  1 14:22:36 2011
From: report at bugs.python.org (thp)
Date: Mon, 01 Aug 2011 12:22:36 +0000
Subject: [issue12674] pydoc str.split does not find the method
In-Reply-To: <1312201356.72.0.545473144997.issue12674@psf.upfronthosting.co.za>
Message-ID: <1312201356.72.0.545473144997.issue12674@psf.upfronthosting.co.za>


New submission from thp <thp at thpinfo.com>:

If I want to get help on a method on a built-in class (e.g. list or str) I can use the help function in the interactive shell:

>>> help(str.split)
>>> help(list.append)

However, when I try to do the same with the command-line utility "pydoc" it does not work:

$ pydoc str.split

What does work with the pydoc command is that I use the following command and then search for the function in the resulting output:

$ pydoc str # after that, manually search for "split"

I've created a patch against Python 2.6's "pydoc.py" that tries to iteratively look up methods in builtins. This keeps the previous behavior as-is, but will give positive results in the cases listed above.

----------
components: Library (Lib)
files: pydoc_builtin-classmethods.patch
keywords: patch
messages: 141494
nosy: thp
priority: normal
severity: normal
status: open
title: pydoc str.split does not find the method
versions: Python 2.7
Added file: http://bugs.python.org/file22817/pydoc_builtin-classmethods.patch

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

From report at bugs.python.org  Mon Aug  1 14:40:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Aug 2011 12:40:53 +0000
Subject: [issue12674] pydoc str.split does not find the method
In-Reply-To: <1312201356.72.0.545473144997.issue12674@psf.upfronthosting.co.za>
Message-ID: <1312202453.45.0.390337789349.issue12674@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "pydoc str" works but not "pydoc str.translate"
type:  -> behavior

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

From report at bugs.python.org  Mon Aug  1 14:45:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Aug 2011 12:45:21 +0000
Subject: [issue12673] SEGFAULT error on OpenBSD (sparc)
In-Reply-To: <1312178410.91.0.482012755622.issue12673@psf.upfronthosting.co.za>
Message-ID: <1312202721.14.0.604950169705.issue12673@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> segmentation fault in listextend during install

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

From report at bugs.python.org  Mon Aug  1 14:45:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:45:24 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <E1Qnrs3-0006d2-Dx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d3e22d69d4f by ?ric Araujo in branch '3.2':
Fix regression with distutils MANIFEST handing (#11104, #8688).
http://hg.python.org/cpython/rev/5d3e22d69d4f

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

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

From report at bugs.python.org  Mon Aug  1 14:45:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:45:24 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <E1Qnrs3-0006d2-Dj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 313a71664781 by ?ric Araujo in branch '3.2':
Let ?make patchcheck? work for out-of-dir builds (#9860)
http://hg.python.org/cpython/rev/313a71664781

New changeset 5993f91598ce by ?ric Araujo in branch 'default':
Merge fixes for #9860, #11104/#8688 and #12331 from 3.2
http://hg.python.org/cpython/rev/5993f91598ce

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

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

From report at bugs.python.org  Mon Aug  1 14:45:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:45:26 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <E1Qnrs3-0006d2-Ds@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2b5a0c4e052b by ?ric Araujo in branch '3.2':
Stop trying to write into the stdlib during lib2to3 tests (#12331).
http://hg.python.org/cpython/rev/2b5a0c4e052b

New changeset 7ee8f413188e by ?ric Araujo in branch 'default':
Stop trying to write into the stdlib during packaging tests (#12331).
http://hg.python.org/cpython/rev/7ee8f413188e

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

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

From report at bugs.python.org  Mon Aug  1 14:47:48 2011
From: report at bugs.python.org (rpointel)
Date: Mon, 01 Aug 2011 12:47:48 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312202868.26.0.654879974112.issue7424@psf.upfronthosting.co.za>


Changes by rpointel <python at xiri.fr>:


----------
nosy: +rpointel

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

From report at bugs.python.org  Mon Aug  1 14:49:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:49:57 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <E1QnrwS-0006xK-FC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a425408f1e52 by ?ric Araujo in branch '2.7':
Stop trying to write into the stdlib during lib2to3 tests (#12331).
http://hg.python.org/cpython/rev/a425408f1e52

----------

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

From report at bugs.python.org  Mon Aug  1 14:49:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:49:58 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <E1QnrwS-0006xK-FH@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 21feea7f35e5 by ?ric Araujo in branch '2.7':
Fix regression with distutils MANIFEST handing (#11104, #8688).
http://hg.python.org/cpython/rev/21feea7f35e5

----------

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

From report at bugs.python.org  Mon Aug  1 14:49:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 12:49:59 +0000
Subject: [issue9860] Building python outside of source directory fails
In-Reply-To: <1284559695.71.0.359508650396.issue9860@psf.upfronthosting.co.za>
Message-ID: <E1QnrwS-0006xK-F3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bea11ce24bb0 by ?ric Araujo in branch '2.7':
Let ?make patchcheck? work for out-of-dir builds (#9860)
http://hg.python.org/cpython/rev/bea11ce24bb0

----------

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

From report at bugs.python.org  Mon Aug  1 14:52:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 12:52:14 +0000
Subject: [issue12331] lib2to3 and packaging tests fail because they write into
	protected directory
In-Reply-To: <1308039905.35.0.844130092935.issue12331@psf.upfronthosting.co.za>
Message-ID: <1312203134.82.0.623848549616.issue12331@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is now fixed.  Let me just eat these words: ?This should not be too hard to fix?.

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

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

From report at bugs.python.org  Mon Aug  1 14:57:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 12:57:21 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1312203441.56.0.774752048169.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I did some more work on the patch and committed.  Thanks again to both of you.

I also thought again about this remark:

> Changeset r83996 was introduced to prevent sdist from overwriting a
> project maintained manifest by testing for a comment at the head of
> the manifest file. It's not clear to me this was necessary because the
> write_manifest() should never have been called if the template was
> absent but a manifest existed.

I also wonder if that was necessary; I did not fully understand the bug at the time.  Unfortunately, now that we have a handful of releases out there with this change, we have to support the magic comment.  For distutils2 however (a.k.a. ?packaging? module in 3.3), I?ll open another bug report and if the same bugs apply (MANIFEST handling is a bit different there), I?ll try to fix the bug without using a magic comment.

----------
components:  -Distutils2
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Aug  1 14:58:39 2011
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 01 Aug 2011 12:58:39 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>


New submission from Gareth Rees <gdr at garethrees.org>:

The tokenize module is happy to tokenize Python source code that the real tokenizer would reject. Pretty much any instance where tokenizer.c returns ERRORTOKEN will illustrate this feature. Here are some examples:

    Python 3.3.0a0 (default:2d69900c0820, Aug  1 2011, 13:46:51) 
    [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from tokenize import generate_tokens
    >>> from io import StringIO
    >>> def tokens(s):
    ...    """Return a string showing the tokens in the string s."""
    ...    return '|'.join(t[1] for t in generate_tokens(StringIO(s).readline))
    ...
    >>> # Bad exponent
    >>> print(tokens('1if 2else 3'))
    1|if|2|else|3|
    >>> 1if 2else 3
      File "<stdin>", line 1
        1if 2else 3
             ^
    SyntaxError: invalid token
    >>> # Bad hexadecimal constant.
    >>> print(tokens('0xfg'))
    0xf|g|
    >>> 0xfg
      File "<stdin>", line 1
        0xfg
           ^
    SyntaxError: invalid syntax
    >>> # Missing newline after continuation character.
    >>> print(tokens('\\pass'))
    \|pass|
    >>> \pass 
      File "<stdin>", line 1
        \pass
            ^
    SyntaxError: unexpected character after line continuation character

It is surprising that the tokenize module does not yield the same tokens as Python itself, but as this limitation only affects incorrect Python code, perhaps it just needs a mention in the tokenize documentation. Something along the lines of, "The tokenize module generates the same tokens as Python's own tokenizer if it is given correct Python code. However, it may incorrectly tokenize Python code containing syntax errors that the real tokenizer would reject."

----------
components: Library (Lib)
messages: 141503
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: tokenize module happily tokenizes code with syntax errors
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug  1 15:19:34 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Mon, 01 Aug 2011 13:19:34 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>


New submission from Popa Claudiu <pcmanticore at gmail.com>:

There appears to be used a variable that is not defined in HTTPConnection.send method. The approximate line is 781. How to reproduce: 
import http.client
import urllib.parse
c = urllib.parse.urlencode({"user":"claudiu", "password":"1"})
c = http.client.HTTPConnection("192.168.71.38")
c.request("POST", "test", c) # silly, I now.

There should be raised a TypeError here, but instead the error is:
  File "C:\Python32\lib\http\client.py", line 781, in send
    or an iterable, got %r " % type(it))
NameError: global name 'it' is not defined

----------
components: Library (Lib)
messages: 141504
nosy: Popa.Claudiu
priority: normal
severity: normal
status: open
title: Bug in http.client
versions: Python 3.2

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

From report at bugs.python.org  Mon Aug  1 15:24:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 13:24:13 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1312155092.22.0.0829826197956.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312204953.3575.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Some notes:
> - By doing things this way, we lose the ability to specify custom arguments to
>   the interpreter with $(TESTPYTHONOPTS). Might this be a problem?

Yes, some buildbots use it. Can't you add support for it in the test
runner?

> - The "test" and "quicktest" targets now use "-u all,-largefile,-audio,-gui",
>   which permits more tests to be run. On my current system, this adds about 20s
>   to the running time for "make test" (~3m45s instead of ~3m25s).

Good idea.

> - I've changed the meaning of "-j 1" -- instead of using a single subprocess, it
>   runs the tests directly in the current process. This allows us to use the
>   run_tests.py script for "make buildbottest" and still have the exact same
>   semantics (using even one subprocess can cause problems for e.g. test_curses).

Ah, nice.

----------

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

From report at bugs.python.org  Mon Aug  1 15:25:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 13:25:07 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312205107.2.0.40596013426.issue12676@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It looks like ?it? should be ?data?.

----------
assignee:  -> orsenthil
keywords: +easy
nosy: +eric.araujo, orsenthil
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Aug  1 15:28:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Aug 2011 13:28:08 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312205288.67.0.279237974507.issue12675@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not familiar with the parser internals (I'm nosying someone who is), but I suspect what you are seeing at the command line is the errors being caught at a stage later than the tokenizer.

----------
nosy: +benjamin.peterson, r.david.murray

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

From report at bugs.python.org  Mon Aug  1 15:28:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 13:28:37 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312205317.31.0.102852976635.issue12562@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Vlad, thank you for the diagnosis.
Indeed by passing a different tagname (or no tagname at all), the problem doesn't occur.
Since mmap.mmap() matches the semantics chosen by Microsoft here, I tend to think this is not a bug; besides, "fixing" it would probably be intricate.

----------
resolution:  -> rejected
status: open -> pending
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug  1 15:33:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 13:33:21 +0000
Subject: [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1312205601.72.0.981616972386.issue12436@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I propose that we just narrow the scope of this report.  If you agree with my earlier message, the current docs just need a few patches:

- How to prepare a text editor
- How to run Python code from a file (if the tutorial or using docs don?t already have it).

It would also be nice to have feedback from beginners about our tutorial and using docs: Are they comprehensive and easy to find?

----------
keywords: +easy
status: pending -> open
title: Provide reference to detailed installation instructions -> Missing items in installation/setup instructions
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug  1 15:33:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 13:33:55 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312205635.28.0.602704746594.issue11651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As an aside, the "quicktest" would probably deserve an update.

----------

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

From report at bugs.python.org  Mon Aug  1 15:37:49 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 01 Aug 2011 13:37:49 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005235.html here's 2 patch (for 3.3 + 3.2 and 2.7) to correct the orientation in the documentation, using turtle.right instead of turtle.left, since the work 'counterclockwise' (even if correct and already used) might be "too heavy". I don't think the sense of the introductory part is voided with the change in the method name instead of fixing what it does.

----------
assignee: docs at python
components: Documentation
files: turtle_right-default.patch
keywords: patch
messages: 141511
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Turtle, fix right/left rotation orientation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22818/turtle_right-default.patch

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

From report at bugs.python.org  Mon Aug  1 15:38:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 01 Aug 2011 13:38:12 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312205892.87.0.0529000411924.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22819/turtle_right-2.7.patch

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

From report at bugs.python.org  Mon Aug  1 15:38:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 01 Aug 2011 13:38:50 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312205930.96.0.205329722359.issue11651@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

>> Some notes:
>> - By doing things this way, we lose the ability to specify custom arguments to
>>   the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
>
> Yes, some buildbots use it. Can't you add support for it in the test
> runner?

Working on it now; I'll upload a revised patch shortly.

> As an aside, the "quicktest" would probably deserve an update.

How so? Should it perhaps use "-u none"?

----------

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

From report at bugs.python.org  Mon Aug  1 15:40:41 2011
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 01 Aug 2011 13:40:41 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312206041.92.0.456560842565.issue12675@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

These errors are generated directly by the tokenizer. In tokenizer.c, the tokenizer generates ERRORTOKEN when it encounters something it can't tokenize. This causes parsetok() in parsetok.c to stop tokenizing and return an error.

----------

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

From report at bugs.python.org  Mon Aug  1 15:43:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 13:43:06 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1312205930.96.0.205329722359.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312206087.3575.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > As an aside, the "quicktest" would probably deserve an update.
> 
> How so? Should it perhaps use "-u none"?

No, I meant the list of tests that it disables.

----------

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

From report at bugs.python.org  Mon Aug  1 15:46:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 01 Aug 2011 13:46:34 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312206394.16.0.431619781191.issue11651@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

What changes do you suggest?

----------

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

From report at bugs.python.org  Mon Aug  1 15:55:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 13:55:30 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1312206394.16.0.431619781191.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312206831.3575.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What changes do you suggest?

Not sure, I never use it. But test_concurrent_futures is not in the list
for example.

----------

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

From report at bugs.python.org  Mon Aug  1 16:30:02 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Mon, 01 Aug 2011 14:30:02 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312209002.24.0.861368279698.issue12562@psf.upfronthosting.co.za>


Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com> added the comment:

OK. I will work around it.
 
I was using 'mapping object of a specified size that is backed by the system paging file instead of by a file in the file system' - map->handle == INVALID_HANDLE_VALUE (-1), i.e. shared memory for inter-process communication (not my choice)

A use case was when all process were stopped and one wanted to start "fresh" using the same tag but with a bigger size. 

BTW, here's the result of the following script in Python 2.5
>>> import mmap
>>> map1 = mmap.mmap(fileno=-1, tagname='MyData', length=4096)
>>> map1[0] = 'a'
>>> map1[4095]='b'
>>> print len(map1), map1[0], map1[4095]
4096 a b
>>> map2 = mmap.mmap(fileno=-1, tagname='MyData', length=8192)
>>> print len(map2), map2[0], map2[4095]
8192 a b

which would indicate that it does 'resize' and preserves the data.



which means t

----------
status: pending -> open

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

From report at bugs.python.org  Mon Aug  1 16:37:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 14:37:36 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312209456.16.0.938788753897.issue10087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  I made a few very minor style comments on Rietveld (follow the ?review? link).

----------

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

From report at bugs.python.org  Mon Aug  1 16:38:57 2011
From: report at bugs.python.org (Piotr Zolnierczuk)
Date: Mon, 01 Aug 2011 14:38:57 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312209537.4.0.18217218072.issue12562@psf.upfronthosting.co.za>


Piotr Zolnierczuk <piotr.zolnierczuk at gmail.com> added the comment:

Just looked into my "partner" C++ code and he's using it very much like in Python 2.5:

m_obj->map_handle = CreateFileMapping (INVALID_HANDLE_VALUE,
NULL,								PAGE_READWRITE,										 0,
pageSize,										 tagName);

m_obj->data = (char *) MapViewOfFile (m_obj->map_handle,								  FILE_MAP_ALL_ACCESS,										  0,										  0,									  0);

----------

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

From report at bugs.python.org  Mon Aug  1 16:41:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 14:41:32 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1312209002.24.0.861368279698.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312209593.3575.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note that multiprocessing can abstract this kind of things for you:
http://docs.python.org/library/multiprocessing#sharing-state-between-processes
http://docs.python.org/library/multiprocessing#module-multiprocessing.sharedctypes

----------

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

From report at bugs.python.org  Mon Aug  1 16:42:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 14:42:58 +0000
Subject: [issue12562] calling mmap twice fails on Windows
In-Reply-To: <1310666402.94.0.718224462838.issue12562@psf.upfronthosting.co.za>
Message-ID: <1312209778.11.0.959888712462.issue12562@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Mon Aug  1 16:59:02 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Aug 2011 14:59:02 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312210742.61.0.807232916311.issue12675@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This should probably be fixed (patches welcome). However, note even with valid Python code, the tokens are not the same.

----------

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

From report at bugs.python.org  Mon Aug  1 17:11:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Aug 2011 15:11:32 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312211492.03.0.455736499867.issue12675@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Aug  1 17:11:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Aug 2011 15:11:46 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312211506.54.0.930731109697.issue12675@psf.upfronthosting.co.za>


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


----------
stage:  -> test needed

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

From report at bugs.python.org  Mon Aug  1 17:31:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 15:31:49 +0000
Subject: [issue12295] Fix ResourceWarning in turtledemo help window
In-Reply-To: <1307634149.19.0.469203775523.issue12295@psf.upfronthosting.co.za>
Message-ID: <E1QnuT5-0005Ik-LN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 63bd8f42b511 by ?ric Araujo in branch '3.2':
Fix resource warning when looking at turtledemo?s help (#12295)
http://hg.python.org/cpython/rev/63bd8f42b511

New changeset 7af576e3cb0c by ?ric Araujo in branch 'default':
Merge #12295 fix from 3.2
http://hg.python.org/cpython/rev/7af576e3cb0c

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

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

From report at bugs.python.org  Mon Aug  1 17:32:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 15:32:31 +0000
Subject: [issue12295] Fix ResourceWarning in turtledemo help window
In-Reply-To: <1307634149.19.0.469203775523.issue12295@psf.upfronthosting.co.za>
Message-ID: <1312212751.65.0.789323684825.issue12295@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Mon Aug  1 17:49:04 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 01 Aug 2011 15:49:04 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312213744.32.0.0399921445801.issue11651@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Updated patch attached.

>> Some notes:
>> - By doing things this way, we lose the ability to specify custom arguments to
>>   the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
>
> Yes, some buildbots use it. Can't you add support for it in the test runner?

Done.

> But test_concurrent_futures is not in the list for example.

Done.


Out of interest, I measured the running times of the different test targets:
  quicktest      2m25s
  test           3m55s
  testall        8m30s
  buildbottest  14m50s

(these are on a 3-year-old Core 2 Duo laptop)

----------
Added file: http://bugs.python.org/file22820/test-runner-v2.patch

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

From report at bugs.python.org  Mon Aug  1 18:20:32 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 01 Aug 2011 16:20:32 +0000
Subject: [issue11640] Shelve references globals in its __del__ method
In-Reply-To: <1300832144.38.0.133902930927.issue11640@psf.upfronthosting.co.za>
Message-ID: <1312215632.31.0.219048667568.issue11640@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Could you add a comment above the lines defining self._BytesIO, describing why they're being set?  Someone else might see them as unnecessary and rip them out if there's no explanation.

Can a test launch Python in a subprocess, set up the appropriate data structure, let the subprocess Python shutdown, then check the subprocess's stderr for the error?

It's a little convoluted, but perhaps it could be built into a general utility function that could be used to test __del__ methods in other modules, too.

Not sure that it's worth the effort though.

----------

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

From report at bugs.python.org  Mon Aug  1 18:30:17 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 01 Aug 2011 16:30:17 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312216217.92.0.150674247878.issue12675@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

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

From report at bugs.python.org  Mon Aug  1 18:50:48 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 01 Aug 2011 16:50:48 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312217448.99.0.888361238149.issue12676@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Mon Aug  1 19:05:08 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 01 Aug 2011 17:05:08 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312218308.19.0.875847886289.issue12676@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Mon Aug  1 20:08:18 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 01 Aug 2011 18:08:18 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312222098.8.0.720313892034.issue12676@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22821/issue12676_py33.patch

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

From report at bugs.python.org  Mon Aug  1 20:11:05 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 01 Aug 2011 18:11:05 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
	path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1312222265.91.0.216300437554.issue10395@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Mon Aug  1 20:35:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 01 Aug 2011 18:35:37 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1312223737.31.0.520416713512.issue11657@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I looked at multiprocessing code, but didn't understand how to trigger a call to these functions. Makes it hard to come up with a unit test...

Ben: Do you still remember how you stumbled upon this issue?

----------

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

From report at bugs.python.org  Mon Aug  1 20:48:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 01 Aug 2011 18:48:12 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312224492.14.0.755934633459.issue11049@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

test_support fails in my environment, only when run from an installed Python, due to permissions issues:

======================================================================
ERROR: test_forget (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python3.3/test/test_support.py", line 59, in test_forget
    support.forget("smtplib")
  File "/usr/local/lib/python3.3/test/support.py", line 248, in forget
    unlink(imp.cache_from_source(source, debug_override=True))
  File "/usr/local/lib/python3.3/test/support.py", line 205, in unlink
    os.unlink(filename)
OSError: [Errno 13] Permission denied: '/usr/local/lib/python3.3/__pycache__/smtplib.cpython-33.pyc'

The issue is similar to #12331, which was recently fixed.

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Mon Aug  1 20:49:14 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Mon, 01 Aug 2011 18:49:14 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312224554.76.0.823309846915.issue11572@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

?ric, I think your points are good ones. (And, as I return to this patch after three months, I should thank the PSF for sponsoring the CPython sprint here at PyOhio, and creating this opportunity for me to continue trying to land this patch!) I am attaching a fourth version of the patch. It incorporates your two suggestions, ?ric. It also applies cleanly once against today's trunk; besides the usual line number changes as code has come and gone, I am happy to see that my change of an "assertTrue" for an "assertIs" in the test suite has already taken place thanks to another patch in the meantime.

----------
Added file: http://bugs.python.org/file22822/test_copy4.patch

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

From report at bugs.python.org  Mon Aug  1 20:59:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 18:59:33 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312225173.0.0.150469977927.issue11651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The latest patch looks ok to me.

----------

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

From report at bugs.python.org  Mon Aug  1 21:31:01 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Mon, 01 Aug 2011 19:31:01 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1312227061.17.0.468326908885.issue11561@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

?ric, I think your suggestions are all good ones, and I have incorporated them into the file. (But do note that the departures we are now making from Ned's own copy of the tracer code ?? removing the commented-out debugging statement, and the long comment, and the inheritance from object ? might make it harder to bring in changes from his own copy if he should ever further improve it.) I have tried to write the comments to be more informative, while also addressing your own ideas; let me know if you like the result!

Oh: and, I am continuing to use this new file in my own work on the Python core, and it has been working fine ? so no problems with the actual code have developed over these first 3+ months of use.

----------
Added file: http://bugs.python.org/file22823/fullcoverage2.patch

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

From report at bugs.python.org  Mon Aug  1 21:31:29 2011
From: report at bugs.python.org (Ben Darnell)
Date: Mon, 01 Aug 2011 19:31:29 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1312227089.21.0.651763899698.issue11657@psf.upfronthosting.co.za>


Ben Darnell <ben.darnell at gmail.com> added the comment:

These functions are used when passing a socket object across a multiprocessing.Queue.

----------

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

From report at bugs.python.org  Mon Aug  1 22:07:51 2011
From: report at bugs.python.org (Alexander)
Date: Mon, 01 Aug 2011 20:07:51 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1312229271.31.0.657865387513.issue670664@psf.upfronthosting.co.za>


Alexander <b3nder at yandex.ru> added the comment:

> It sounds like the early consensus on python-dev is that html5 support is a good thing. 

Yeah... But wait another 8 years untill these guys decides that there is enough  tests and other cool stuff.

----------

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

From report at bugs.python.org  Mon Aug  1 22:20:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Aug 2011 20:20:05 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1312230005.19.0.332597341583.issue670664@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Yeah... But wait another 8 years untill these guys decides that
> there is enough  tests and other cool stuff.

Which guys are you talking about?
Granted, this issue has been around for a loooong time... but now that we have a patch that seems ok (and has tests), we should be able to finally push this and include it in the next feature release, hopefully.

----------

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

From report at bugs.python.org  Mon Aug  1 22:50:30 2011
From: report at bugs.python.org (Matt Basta)
Date: Mon, 01 Aug 2011 20:50:30 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1312231830.59.0.788329078426.issue670664@psf.upfronthosting.co.za>


Matt Basta <bastawhiz at gmail.com> added the comment:

Seeing as everyone seems pretty satisfied with the 2.7 version, I'd be happy to put together a patch for 3 as well.

To confirm, though, this fix is NOT going behind the strict parameter, correct?

----------

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

From report at bugs.python.org  Mon Aug  1 22:57:54 2011
From: report at bugs.python.org (=?utf-8?q?Tiago_Gon=C3=A7alves?=)
Date: Mon, 01 Aug 2011 20:57:54 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1312232274.32.0.0277076999045.issue10141@psf.upfronthosting.co.za>


Tiago Gon?alves <tiagogoncalves at ua.pt> added the comment:

I think that this time i have included almost every proposed changes.

For the unitTest I did not included the condition "os.getuid() == 0" because of this information in the Linux documentation "3.3 network security issues (capabilities)" http://www.mjmwired.net/kernel/Documentation/networking/can.txt#212. For example, the Ubuntu 10.10 does not require to be root to access socketCAN network interfaces.

For the "return Py_BuildValue("O&h", PyUnicode_DecodeFSDefault, ifname, a->can_family);" i have kept the "h" because in the header file the "a->can_family" is defined as an short int.

----------
Added file: http://bugs.python.org/file22824/socketcan.v2.patch

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

From report at bugs.python.org  Mon Aug  1 23:21:59 2011
From: report at bugs.python.org (Eric Snow)
Date: Mon, 01 Aug 2011 21:21:59 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
	path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1312233719.86.0.899538092477.issue10395@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

You can already get the better prefix using os.path, albeit less efficiently.  Here's an example:

def commondirname(paths):
    subpath = os.path.commonprefix(paths)
    for path in paths:
        if path == subpath:
            return subpath
    else:
        return os.path.join(os.path.split(subpath)[0], "")

However, would it be better to implicitly normalize paths first rather than doing a character-by-character comparison?  Here is an unoptimized demonstration of what I mean:

def commondirname(paths):
    result = ""
    for path in paths:
        path = os.path.normcase(os.path.abspath(path))
        if not result:
            result = path
        else:
            while not path.startswith(result + os.path.sep):
                result, _ = os.path.split(result)
                if os.path.splitdrive(result)[1] == os.path.sep:
                    return result
    return result

----------
nosy: +ericsnow

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

From report at bugs.python.org  Mon Aug  1 23:44:37 2011
From: report at bugs.python.org (Maxim Bublis)
Date: Mon, 01 Aug 2011 21:44:37 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1312235077.1.0.87546631495.issue8639@psf.upfronthosting.co.za>


Maxim Bublis <b at codemonkey.ru> added the comment:

I've ran into the same problem with getfullargspec not supporting callables, so I've written patch with docs and tests, that adds support for any Python callable. As a result of getfullargspec's implementation change, getargspec function also supports callables.

----------
keywords: +patch
nosy: +maxbublis
Added file: http://bugs.python.org/file22825/inspect.patch

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

From report at bugs.python.org  Tue Aug  2 00:04:03 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 01 Aug 2011 22:04:03 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312236243.19.0.0597311919996.issue12666@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've created a patch to address (1) and (2).

Is there any value in also including this in the 2to3 fixer? I can see that it's a simple translation, but adds complexity to the converted code. I'd be content to go with just a documentation patch. I'll defer to Benjamin or his delegate on whether or not to update 2to3.

----------
hgrepos: +50
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Aug  2 00:16:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 22:16:43 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <E1Qo0mw-0002Nw-9M@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c68a80779434 by Nadeem Vawda in branch 'default':
Issue #11651: Move options for running tests into a Python script.
http://hg.python.org/cpython/rev/c68a80779434

----------

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

From report at bugs.python.org  Tue Aug  2 00:36:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Aug 2011 22:36:15 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1312238175.17.0.219435333501.issue8639@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm -0.5. I think the current patch makes too many assumptions for the caller. For example, someone calling a class may really desire __new__'s signature, not that of __init__. Moreover, conceptually, getargspec() returns the argspec of a directly callable *function* or *method*.

----------

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

From report at bugs.python.org  Tue Aug  2 00:44:17 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Aug 2011 22:44:17 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1312238657.38.0.717265362784.issue8639@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Right. For a callable object (instance with __call__ method), it's unambiguous which signature you want. For a class it's ambiguous.

----------

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

From report at bugs.python.org  Tue Aug  2 01:20:50 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 01 Aug 2011 23:20:50 +0000
Subject: [issue12612] Valgrind suppressions
In-Reply-To: <1311352571.88.0.0623185894462.issue12612@psf.upfronthosting.co.za>
Message-ID: <1312240850.22.0.213343850849.issue12612@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/issue12612>
_______________________________________

From report at bugs.python.org  Tue Aug  2 02:30:25 2011
From: report at bugs.python.org (Maxim Bublis)
Date: Tue, 02 Aug 2011 00:30:25 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1312245025.94.0.41211306475.issue8639@psf.upfronthosting.co.za>


Maxim Bublis <b at codemonkey.ru> added the comment:

Agree, support for __new__ or __init__ methods would add some ambiquity, so i've decided to drop __init__ support from patch. Patch has been reuploaded.

----------
Added file: http://bugs.python.org/file22826/inspect2.patch

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

From report at bugs.python.org  Tue Aug  2 02:54:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Aug 2011 00:54:16 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Seen on the buildbots, seems very recent:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%202.7/builds/968
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.2/builds/440
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/3232

----------
assignee: eric.araujo
components: Distutils, Distutils2, Tests
messages: 141542
nosy: alexis, eric.araujo, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test_packaging and test_distutils failures under Windows
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  2 04:45:32 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Tue, 02 Aug 2011 02:45:32 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312253132.6.0.146712421563.issue12675@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

How come tokenizer module is not based on actual C tokenizer? Wouldn't that make more sense (and prevent this kind of issues)?

----------
nosy: +vladris

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

From report at bugs.python.org  Tue Aug  2 05:27:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 03:27:27 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <E1Qo5de-0008D4-8d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1a978892a105 by Eli Bendersky in branch 'default':
Issue #11049: fix test_forget to work on installed Python, by using a temporary module for import/forget
http://hg.python.org/cpython/rev/1a978892a105

----------

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

From report at bugs.python.org  Tue Aug  2 06:42:18 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Aug 2011 04:42:18 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312260138.12.0.274972215839.issue12675@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

tokenize has useful features that the builtin tokenizer does not possess such as the NL token.

----------

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

From report at bugs.python.org  Tue Aug  2 07:59:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 02 Aug 2011 05:59:01 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <1312264741.03.0.703982952542.issue11651@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  2 08:46:51 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 02 Aug 2011 06:46:51 +0000
Subject: [issue12679] ThreadError is not in threading.__all__
In-Reply-To: <1312267611.8.0.542884260268.issue12679@psf.upfronthosting.co.za>
Message-ID: <1312267611.8.0.542884260268.issue12679@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

>>> from threading import *
>>> ThreadError
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ThreadError' is not defined

----------
components: Library (Lib)
files: export-thread-error.patch
keywords: patch
messages: 141546
nosy: anacrolix
priority: normal
severity: normal
status: open
title: ThreadError is not in threading.__all__
versions: Python 3.2
Added file: http://bugs.python.org/file22827/export-thread-error.patch

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

From report at bugs.python.org  Tue Aug  2 09:08:20 2011
From: report at bugs.python.org (Scott Dial)
Date: Tue, 02 Aug 2011 07:08:20 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1312268900.48.0.901489045121.issue10639@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

I haven't seen anyone use a side-effect-less statement (a string) as a comment before, but I doubt that is an approved style for the CPython codebase. Please change the string preceeding the spec_line definition into a proper comment.

----------
nosy: +scott.dial

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

From report at bugs.python.org  Tue Aug  2 10:16:09 2011
From: report at bugs.python.org (Sagiv Malihi)
Date: Tue, 02 Aug 2011 08:16:09 +0000
Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe
	imports
In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>
Message-ID: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>


New submission from Sagiv Malihi <sagivmalihi at gmail.com>:

When trying to cPickle.loads() from several threads at once, there is a race condition when threads try to import modules.

An example will explain it best:
suppose I have module foo.py which takes some time to load:

import time
class A(object):
    def __setstate__(self, state):
        self.x = x
time.sleep(1)
x = 5

and a pickled version of an A() object stored in 'A.pkl'.
the following code, when run for the first time, will raise a NameError about 'x':

>>> p = open('A.pkl','rb').read()
>>> [thread.start_new(cPickle.loads, (p,)) for x in xrange(2)]

Unhandled exception in thread started by <built-in function loads>
Traceback (most recent call last):
  File "foo.py", line 7, in __setstate__
    self.x = x
NameError: global name 'x' is not defined


since the module is now loaded, subsequent calls to cPickle.loads will work as expected.

This was tested on 2.5.2, 2.7.1, and 3.2 on Ubuntu and on Windows 7.

please note that this bug was discovered when unpickling the standard 'decimal.Decimal' class (decimal.py is quite long and takes some time to import), and this is not some corner case.

----------
components: Extension Modules
messages: 141548
nosy: Sagiv.Malihi
priority: normal
severity: normal
status: open
title: cPickle.loads is not thread safe due to non-thread-safe imports
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  2 10:48:35 2011
From: report at bugs.python.org (Sagiv Malihi)
Date: Tue, 02 Aug 2011 08:48:35 +0000
Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe
	imports
In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>
Message-ID: <1312274915.97.0.144720506946.issue12680@psf.upfronthosting.co.za>


Sagiv Malihi <sagivmalihi at gmail.com> added the comment:

OK, digging deeper reveals that there are actually two bugs here, one is conceptual in the python importing mechanism, and the other is technical in cPickle.

The first bug: 
PyImport_ExecCodeModuleEx adds the module to sys.modules *before* actually executing the code. This is a design flaw (can it really be changed? )
Demonstrating this bug is easy using the foo.py module from the previous comment:

def f():
    if 'bla' in sys.modules:
        bla = sys.modules['bla']
    else:
        import bla
    return bla.A()
running two instances of f in two threads results in the same error.

The second bug: in cPickle.c: func_class() 
cPickle 'manually' checks if a module is in sys.modules instead of letting the import mechanism do it for him (hence breaking the import lock's defense here).

----------

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

From report at bugs.python.org  Tue Aug  2 11:41:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Aug 2011 09:41:46 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1312278106.28.0.511181738632.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Unrelated to the Fedora issue: The test is currently skipped on the
FreeBSD bot, but completes successfully with:

diff -r 0b52b6f1bfab Lib/test/test_locale.py
--- a/Lib/test/test_locale.py   Tue Aug 02 10:16:45 2011 +0200
+++ b/Lib/test/test_locale.py   Tue Aug 02 11:37:39 2011 +0200
@@ -399,7 +399,7 @@
         oldlocale = locale.setlocale(locale.LC_CTYPE)
         self.addCleanup(locale.setlocale, locale.LC_CTYPE, oldlocale)
         try:
-            locale.setlocale(locale.LC_CTYPE, 'tr_TR')
+            locale.setlocale(locale.LC_CTYPE, 'tr_TR.UTF-8')
         except locale.Error:
             # Unsupported locale on this system
             self.skipTest('test needs Turkish locale')

----------

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

From report at bugs.python.org  Tue Aug  2 12:21:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Aug 2011 10:21:36 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1312280496.04.0.202649482563.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

As I wrote on python-dev, this test also fails on Debian lenny, which has
the same setlocale() bug as Fedora.

So, indeed the test should be skipped on a multitude of platforms.

----------

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

From report at bugs.python.org  Tue Aug  2 12:33:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:33:56 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <E1QoCIN-0000fe-00@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1013c9fbd83c by Senthil Kumaran in branch '3.2':
Fix closes Issue12676 - Invalid identifier used in TypeError message in http.client.
http://hg.python.org/cpython/rev/1013c9fbd83c

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

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

From report at bugs.python.org  Tue Aug  2 12:35:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:35:08 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <E1QoCJX-0000qy-6Q@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c099ba0a278e by Senthil Kumaran in branch 'default':
Fix closes Issue12676 - Invalid identifier used in TypeError message in http.client.
http://hg.python.org/cpython/rev/c099ba0a278e

----------

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

From report at bugs.python.org  Tue Aug  2 12:37:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 10:37:49 +0000
Subject: [issue12676] Bug in http.client
In-Reply-To: <1312204774.15.0.0451791288151.issue12676@psf.upfronthosting.co.za>
Message-ID: <1312281469.04.0.406948496814.issue12676@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the bug report, Popa Claudiu and Patch Santoso Wijaya. 
Ouch, pretty ugly bug - shows the code lacked test coverage.

----------

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

From report at bugs.python.org  Tue Aug  2 12:51:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 10:51:23 +0000
Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe
	imports
In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>
Message-ID: <1312282283.68.0.726746665105.issue12680@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, ncoghlan

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

From report at bugs.python.org  Tue Aug  2 12:53:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:53:23 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoCbB-0002Cz-OI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 209ad8920b03 by Senthil Kumaran in branch '2.7':
Fix closes Issue12183 - Explain the Symlink copy behavior in shutil.copytree. Patch by Petri Lehtinen.
http://hg.python.org/cpython/rev/209ad8920b03

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

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

From report at bugs.python.org  Tue Aug  2 12:55:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:55:23 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoCd8-0002P3-Ej@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 299992730c87 by Senthil Kumaran in branch '3.2':
Fix closes Issue12183 - Explain the Symlink copy behavior in shutil.copytree. Patch by Petri Lehtinen.
http://hg.python.org/cpython/rev/299992730c87

----------

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

From report at bugs.python.org  Tue Aug  2 12:57:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 10:57:13 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1312282633.01.0.810915039861.issue12183@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Petri, Thanks for the patch. It would also be helpful to track -  "shutil.copytree() use lutimes in Python 3.3 to copy symlink metadata if symlinks=True". You can raise a feature request if it is not already raised. Thanks!.

----------

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

From report at bugs.python.org  Tue Aug  2 12:58:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 10:58:34 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <1312282714.67.0.606719134891.issue10639@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, this is actually blessed by http://www.python.org/dev/peps/pep-0257/, but if that convention were actually followed the docstring would go *after* the assignment.  But I agree that it is rarely used, and as far as I know is not used in the stdlib at all.

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

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

From report at bugs.python.org  Tue Aug  2 13:34:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 11:34:30 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1312284870.5.0.589680507721.issue1813@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Tue, 02 Aug 2011 12:12:37 +0200, Stefan Krah <stefan at bytereef.org> wrote:
> I suspect many buildbots are green because they don't have tr_TR and
> tr_TR.iso8859-9 installed.

This is true for my Gentoo buildbots.  Once we've figured out the
best way to handle this, I'll fix that (install the other locales) for
my two.

When I run the C test program I get null as the final output of that
regardless of whether I use 'tr_TR' or 'tr_TR.utf8'.

This is with glibc-2.13-r2 (the r2 is Gentoo's mod number).

As someone pointed out on python-dev, if this isn't fixable then it should be an expected failure, not a skip.

One question is, is there any platform on which the turkish locale is installed where this test actually works?

----------

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

From report at bugs.python.org  Tue Aug  2 13:41:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 11:41:56 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I think that it would be good for expectedFailure to take a message argument like skip does.  My thought is that it would be printed both when it is triggered (the test fails as expected) so that one case from the verbose output why the test is expected to fail, and when the test passes unexpectedly.  My specific use case is OS bugs, where we could mark a test as an expected failure instead of a skip, and then we would see the unexpected pass when the OS fixes the bug, but in the meantime the verbose output would show the 'skip' reason.

Hmm.  I suppose this means I want expectedFailureIf, too...

----------
components: Library (Lib)
keywords: easy
messages: 141560
nosy: michael.foord, r.david.murray
priority: low
severity: normal
status: open
title: unittest expectedFailure could take a message argument like skip does
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  2 14:01:13 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Aug 2011 12:01:13 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1312286473.38.0.29715048181.issue1813@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Re-opening to fix the skips]

Yes, the test works on:

  Ubuntu Lucid (libc-2.11.1), OpenSUSE (libc-2.11.1), FreeBSD-8.2


Failure:

  Fedora 14 (libc-2.13), Debian lenny (libc-2.7), Gentoo (libc-2.13-r2)


So perhaps this test should be marked as expected failure on Linux
altogether (unless we test for the libc version).

----------
status: closed -> open

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

From report at bugs.python.org  Tue Aug  2 14:06:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Aug 2011 12:06:32 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1312284870.5.0.589680507721.issue1813@psf.upfronthosting.co.za>
Message-ID: <1312286691.3588.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As someone pointed out on python-dev, if this isn't fixable then it
> should be an expected failure, not a skip.

The Python bug is fixed, the problem is apparently some libcs have the
same bug as we did...

> One question is, is there any platform on which the turkish locale is
> installed where this test actually works?

Well, it works here (Mageia).

----------

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

From report at bugs.python.org  Tue Aug  2 14:20:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 12:20:53 +0000
Subject: [issue10639] reindent.py should not convert newlines
In-Reply-To: <1291653413.79.0.461728889357.issue10639@psf.upfronthosting.co.za>
Message-ID: <E1QoDxr-0001dh-Sy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dc96af0e7f60 by Jason R. Coombs in branch 'default':
Corrected attribute docstring per pep-257 (reference #10639)
http://hg.python.org/cpython/rev/dc96af0e7f60

----------

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

From report at bugs.python.org  Tue Aug  2 15:13:32 2011
From: report at bugs.python.org (Maxim Bublis)
Date: Tue, 02 Aug 2011 13:13:32 +0000
Subject: [issue8639] Allow callable objects in inspect.getfullargspec
In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za>
Message-ID: <1312290812.71.0.252103778302.issue8639@psf.upfronthosting.co.za>


Changes by Maxim Bublis <b at codemonkey.ru>:


Removed file: http://bugs.python.org/file22825/inspect.patch

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

From report at bugs.python.org  Tue Aug  2 16:42:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 14:42:40 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoGB5-00078X-5i@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 746dc0a2398e by Ezio Melotti in branch 'default':
#12183: merge with 3.2.
http://hg.python.org/cpython/rev/746dc0a2398e

----------

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

From report at bugs.python.org  Tue Aug  2 16:47:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 14:47:58 +0000
Subject: [issue12670] Fix struct code after forward declaration on ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <E1QoGGC-0007iu-KM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2aa8dd4df650 by Sandro Tosi in branch '2.7':
#12670: Fix struct code after forward declaration on ctypes doc
http://hg.python.org/cpython/rev/2aa8dd4df650

New changeset 25dd1d3f4b88 by Sandro Tosi in branch '3.2':
#12670: Fix struct code after forward declaration on ctypes doc
http://hg.python.org/cpython/rev/25dd1d3f4b88

New changeset 01192d30365a by Sandro Tosi in branch 'default':
#12670: merge with 3.2
http://hg.python.org/cpython/rev/01192d30365a

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

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

From report at bugs.python.org  Tue Aug  2 16:50:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 14:50:09 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <E1QoGB5-00078X-5i@dinsdale.python.org>
Message-ID: <20110802144955.GA2980@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Ezio,

It was intentional that I did not merge it to default. We want
shutil.copystat to use lutimes which is available in 3.3 and in which
case, we will have to remove this once that change is done.

----------

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

From report at bugs.python.org  Tue Aug  2 16:52:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Aug 2011 14:52:16 +0000
Subject: [issue12183] Document behaviour of shutil.copy2 and copystat with
	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1312296736.85.0.506919518952.issue12183@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I applied it because the patch is valid on 3.3 too until we actually change copystat to use lutimes.  If/when shutil is changed the doc can be updated accordingly.

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

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

From report at bugs.python.org  Tue Aug  2 16:57:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 02 Aug 2011 14:57:22 +0000
Subject: [issue12670] Fix struct code after forward declaration on ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <1312297042.05.0.0334236691812.issue12670@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  2 17:07:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 15:07:12 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The devguide documents the 'accepted' resolution as follows:

     Submitted patch was applied, still needs verifying (for example by
     watching the buildbots) that everything went fine. At that point the
     resolution should be set to fixed and the status changed to closed.

I've never run into this usage while working with the tracker.  I *have* seen people set 'accepted' when they want to indicate that the issue is considered valid to be fixed, or that a feature request has been accepted but there's no patch ready for commit yet.

Formally I believe that the 'accepted' resolution is for committed feature requests (since "fixed" doesn't make English sense in that context).  Any other use is creative license :)

----------
assignee: docs at python
components: Documentation
messages: 141568
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Meaning of 'accepted' resolution as documented in devguide

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

From report at bugs.python.org  Tue Aug  2 17:12:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Aug 2011 15:12:55 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312297975.1.0.926107114766.issue12682@psf.upfronthosting.co.za>


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


----------
components: +Devguide -Documentation
nosy: +ezio.melotti
resolution:  -> accepted
stage:  -> needs patch

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

From report at bugs.python.org  Tue Aug  2 17:28:54 2011
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Tue, 02 Aug 2011 15:28:54 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1312298934.67.0.849915158077.issue9561@psf.upfronthosting.co.za>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Ping. What's the progress on this? Will this ever be fixed?

----------

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

From report at bugs.python.org  Tue Aug  2 17:38:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Aug 2011 15:38:32 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312299512.58.0.678933302287.issue12646@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not a zlib specialist, but I think what this means is that the stream is not finished, but it's valid anyway.

For example, you get the same behaviour by doing:

c = zlib.compressobj()
s = c.compress(b'This is just a test string.')
s += c.flush(zlib.Z_FULL_FLUSH)

The resulting bytestring is a non-terminated zlib stream. It still decompresses to the original data fine.

I think the appropriate fix is to add an argument to flush(). Here is a patch, I named the argument "strict" by lack of imagination :)

----------
Added file: http://bugs.python.org/file22828/zlibflushstrict.patch

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

From report at bugs.python.org  Tue Aug  2 18:11:21 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Aug 2011 16:11:21 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312301481.24.0.271637884264.issue12682@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/issue12682>
_______________________________________

From report at bugs.python.org  Tue Aug  2 18:24:06 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Tue, 02 Aug 2011 16:24:06 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312302246.53.0.132722743921.issue12646@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I like the new patch, but shouldn?t the default be to behave the same way zlib.decompress() behaves, i.?e. raise? (Or perhaps zlib.decompress() should be modified not to raise instead. I?m just aiming at consistency.) Of course this will break code that relies on the old behaviour but the fix (adding strict=False) is trivial.

----------

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

From report at bugs.python.org  Tue Aug  2 18:32:16 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 02 Aug 2011 16:32:16 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312302736.51.0.00268838021513.issue12682@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> Formally I believe that the 'accepted' resolution is for committed feature requests

That's what I also thought originally.

Perhaps this should be discussed on Python-Dev to see what people think it should mean?

----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Tue Aug  2 18:44:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 16:44:57 +0000
Subject: [issue12665] Dictionary view example has error in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <E1QoI5P-0002Ck-Fc@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a70cdec027e7 by Sandro Tosi in branch '3.2':
#12665: Dictionary view example has error in set operation
http://hg.python.org/cpython/rev/a70cdec027e7

New changeset b2dc821058fe by Sandro Tosi in branch 'default':
#12665: merge with 3.2
http://hg.python.org/cpython/rev/b2dc821058fe

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

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

From report at bugs.python.org  Tue Aug  2 18:47:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 02 Aug 2011 16:47:57 +0000
Subject: [issue12665] Dictionary view example has error in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <1312303677.87.0.733745456003.issue12665@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  2 18:56:19 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 02 Aug 2011 16:56:19 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1312304179.03.0.342513676607.issue12681@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

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

From report at bugs.python.org  Tue Aug  2 20:02:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 18:02:43 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <E1QoJIg-0000tb-Hr@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aebe3243bb2c by ?ric Araujo in branch '2.7':
Fix incorrect mtime comparison in distutils (#11933).
http://hg.python.org/cpython/rev/aebe3243bb2c

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

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

From report at bugs.python.org  Tue Aug  2 20:06:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 18:06:29 +0000
Subject: [issue12679] ThreadError is not in threading.__all__
In-Reply-To: <1312267611.8.0.542884260268.issue12679@psf.upfronthosting.co.za>
Message-ID: <E1QoJMK-0001EC-1O@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bbeda42ea6a8 by Benjamin Peterson in branch 'default':
add ThreadError to threading.__all__ (closes #12679)
http://hg.python.org/cpython/rev/bbeda42ea6a8

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

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

From report at bugs.python.org  Tue Aug  2 20:20:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Aug 2011 18:20:19 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1312309219.29.0.7170500732.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Here?s the distutils error:

ERROR: test_manual_manifest (distutils.tests.test_sdist.SDistTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\tarfile.py", line 1802, in gzopen
    fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "D:\Buildslave\3.x.moore-windows\build\lib\gzip.py", line 145, in __init__
    fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: 'c:\\docume~1\\pydev\\locals~1\\temp\\tmptlkdmc\\dist\\fake-1.0.tar.gz'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\Buildslave\3.x.moore-windows\build\lib\distutils\tests\test_sdist.py", line 385, in test_manual_manifest
    archive = tarfile.open(archive_name)
  File "D:\Buildslave\3.x.moore-windows\build\lib\tarfile.py", line 1736, in open
    return func(name, "r", fileobj, **kwargs)
  File "D:\Buildslave\3.x.moore-windows\build\lib\tarfile.py", line 1806, in gzopen
    fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'

It looks like an issue with a temporary file removed too soon.  I?ll look into it shortly.


For packaging, the bug is related to os.path.relpath.  I actually want to remove the use of relpath because of another bug (not reported yet, will do soon), so we?ll have to live with this failure for a while until the code is changed.

----------

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

From report at bugs.python.org  Tue Aug  2 20:22:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Aug 2011 18:22:23 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1312309343.09.0.756957704347.issue11561@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22622/unnamed

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

From report at bugs.python.org  Tue Aug  2 20:29:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Aug 2011 18:29:59 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1312309799.2.0.505626346006.issue11561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think your suggestions are all good ones, and I have incorporated
> them into the file.
Great :)  You left some commented-out debugging prints.

> (But do note that the departures we are now making from Ned's own
> copy of the tracer code ?? removing the commented-out debugging
> statement, and the long comment, and the inheritance from object ?
> might make it harder to bring in changes from his own copy if he
> should ever further improve it.)
I?m not concerned by this.  I?ve been doing merges all the time for more that a year, and having a few diverging lines is not a big deal.

> I have tried to write the comments to be more informative, while also
> addressing your own ideas; let me know if you like the result!
I do!

> Oh: and, I am continuing to use this new file in my own work on the
> Python core, and it has been working fine ? so no problems with the
> actual code have developed over these first 3+ months of use.
This is a good thing to know.

I?ll let Brett take over now.

----------

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

From report at bugs.python.org  Tue Aug  2 20:51:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Aug 2011 18:51:50 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1312311110.18.0.477715697584.issue12681@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Too late I'm afraid as expectedFailure not expectedFailure() is the decorator.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Aug  2 21:36:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Aug 2011 19:36:14 +0000
Subject: [issue11933] newer() function in dep_util.py mixes up new vs. old
	files due stat.st_mtime vs stat
In-Reply-To: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
Message-ID: <1312313774.47.0.292114668505.issue11933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks again!

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

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

From report at bugs.python.org  Tue Aug  2 22:26:53 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Aug 2011 20:26:53 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I say just  go ahead and change  it. I was probably just thinking how I wish we would use it when I wrote that.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Wed Aug  3 00:15:23 2011
From: report at bugs.python.org (Jasper van den Bosch)
Date: Tue, 02 Aug 2011 22:15:23 +0000
Subject: [issue12683] urlparse.urljoin different behavior for different scheme
In-Reply-To: <1312323323.6.0.0555659867891.issue12683@psf.upfronthosting.co.za>
Message-ID: <1312323323.6.0.0555659867891.issue12683@psf.upfronthosting.co.za>


New submission from Jasper van den Bosch <japsai at gmail.com>:

urlparse.urljoin successfully joins 'http://localhost/repo1' with a filename, but not 'svn://localhost/repo1' (only scheme different). But the documentation states that the svn: scheme is supported:
http://docs.python.org/library/urlparse.html

Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urlparse import urljoin
>>> urljoin('svn://localhost/repo1', 'xxx.xyz')
'xxx.xyz'
>>> urljoin('http://localhost/repo1', 'xxx.xyz')
'http://localhost/xxx.xyz'

----------
components: None
messages: 141581
nosy: Jasper.van.den.Bosch
priority: normal
severity: normal
status: open
title: urlparse.urljoin different behavior for different scheme
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  3 00:18:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Aug 2011 22:18:34 +0000
Subject: [issue12683] urlparse.urljoin different behavior for different scheme
In-Reply-To: <1312323323.6.0.0555659867891.issue12683@psf.upfronthosting.co.za>
Message-ID: <1312323514.52.0.93733287768.issue12683@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -None
nosy: +ezio.melotti, orsenthil
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug  3 00:19:31 2011
From: report at bugs.python.org (Vlada Peric)
Date: Tue, 02 Aug 2011 22:19:31 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1312323571.34.0.586811275661.issue12611@psf.upfronthosting.co.za>


Vlada Peric <vlada.peric at gmail.com> added the comment:

Confirmed with the file Aaron linked to. I'm using "2to3-3.2 -w -n -d sympy/ntheory/factor_.py". This is what Python says about itself:

Python 3.2 (r32:88445, Jun  8 2011, 16:34:06) 
[GCC 4.5.1 20101208 [gcc-4_5-branch revision 167585]] on linux2

----------
status: pending -> open

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

From report at bugs.python.org  Wed Aug  3 00:30:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 22:30:43 +0000
Subject: [issue12655] Expose sched.h functions
In-Reply-To: <1311959395.98.0.305576868025.issue12655@psf.upfronthosting.co.za>
Message-ID: <E1QoNU1-0007BI-O8@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 89e92e684b37 by Benjamin Peterson in branch 'default':
expose sched.h functions (closes #12655)
http://hg.python.org/cpython/rev/89e92e684b37

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

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

From report at bugs.python.org  Wed Aug  3 00:36:17 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 02 Aug 2011 22:36:17 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312324577.08.0.721905672401.issue11049@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

test_forget still doesn't work using my installed Python:

test test_support failed -- Traceback (most recent call last):
  File "/usr/local/lib/python3.3/test/test_support.py", line 62, in test_forget
    mod = __import__(TESTFN)
ImportError: No module named '@test_20485_tmp'

----------

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

From report at bugs.python.org  Wed Aug  3 01:45:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 23:45:07 +0000
Subject: [issue12663] ArgumentParser.error writes to stderr not to stdout
In-Reply-To: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>
Message-ID: <E1QoOe2-0004f2-J4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5ff56995976c by Senthil Kumaran in branch '3.2':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/5ff56995976c

New changeset a5b3d5051fc7 by Senthil Kumaran in branch 'default':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/a5b3d5051fc7

New changeset 1e8dc34ece30 by Senthil Kumaran in branch '2.7':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/1e8dc34ece30

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

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

From report at bugs.python.org  Wed Aug  3 01:49:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 23:49:08 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110802234859.GA2542@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I propose that we remove 'accepted' as the meaning seems ambiguous and
it is of little practical (/tracking) use.

----------
nosy: +orsenthil

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

From senthil at uthcode.com  Wed Aug  3 01:48:59 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 3 Aug 2011 07:48:59 +0800
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>
References: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
	<1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110802234859.GA2542@mathmagic>

I propose that we remove 'accepted' as the meaning seems ambiguous and
it is of little practical (/tracking) use.

From senthil at uthcode.com  Wed Aug  3 02:08:10 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 3 Aug 2011 08:08:10 +0800
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205892.87.0.0529000411924.issue12677@psf.upfronthosting.co.za>
References: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
	<1312205892.87.0.0529000411924.issue12677@psf.upfronthosting.co.za>
Message-ID: <20110803000809.GB2542@mathmagic>

The orientation depends upon the mode, which is explained further
down.
http://docs.python.org/py3k/library/turtle.html#turtle.left

So, the correct fix would be: 
"would turn clockwise/counterclockwise depending upon the mode."

From report at bugs.python.org  Wed Aug  3 02:08:19 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Aug 2011 00:08:19 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205892.87.0.0529000411924.issue12677@psf.upfronthosting.co.za>
Message-ID: <20110803000809.GB2542@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The orientation depends upon the mode, which is explained further
down.
http://docs.python.org/py3k/library/turtle.html#turtle.left

So, the correct fix would be: 
"would turn clockwise/counterclockwise depending upon the mode."

----------
nosy: +orsenthil

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

From report at bugs.python.org  Wed Aug  3 02:16:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Aug 2011 00:16:03 +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: <1312330563.93.0.883749782738.issue11598@psf.upfronthosting.co.za>


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


----------
nosy: +brian.curtin, loewis

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

From report at bugs.python.org  Wed Aug  3 02:20:30 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 03 Aug 2011 00:20:30 +0000
Subject: [issue12681] unittest expectedFailure could take a message argument
	like skip does
In-Reply-To: <1312285316.59.0.648531105022.issue12681@psf.upfronthosting.co.za>
Message-ID: <1312330830.12.0.106588035945.issue12681@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, expectedFailure could dispatch on the type of the argument, with different behaviour for strings and anything else (presumed to be a function / method). That would be inconsistent with the api for skipping though. (I'm not wild on the message argument to the skip decorators - I keep forgetting it.)

----------

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

From report at bugs.python.org  Wed Aug  3 02:26:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Aug 2011 00:26:34 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312331194.62.0.608387422364.issue12682@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is not ambigous.  As I said, bugs are fixed, feature requests are accepted.

----------

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

From report at bugs.python.org  Wed Aug  3 03:15:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Aug 2011 01:15:09 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312334109.0.0.127984307373.issue12682@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I thought "fixed" was enough. A kind of binary state where we say, okay we have it and otherwise no, we don't. I know for feature requests the terminology does not make sense, but I believe I have worked with bug trackers where fixed was the ultimate state where a particular change (be a bug-fix or a feature request) was in the code.

Well, as long as it is helpful, I am fine with it, but too many options can confuse (just as 'accepted' did) and it will be helpful to prune down some.

----------
resolution: accepted -> 

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

From report at bugs.python.org  Wed Aug  3 03:43:18 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 03 Aug 2011 01:43:18 +0000
Subject: [issue12684] profile does not dump stats on exception like cProfile
	does
In-Reply-To: <1312335798.44.0.743453347572.issue12684@psf.upfronthosting.co.za>
Message-ID: <1312335798.44.0.743453347572.issue12684@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

Here's a patch that fixes it.

----------
components: Library (Lib)
files: exception-in-profile.patch
keywords: patch
messages: 141591
nosy: anacrolix
priority: normal
severity: normal
status: open
title: profile does not dump stats on exception like cProfile does
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22829/exception-in-profile.patch

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

From report at bugs.python.org  Wed Aug  3 03:47:45 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 03 Aug 2011 01:47:45 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312336065.88.0.00612329118743.issue12437@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Should I just submit a patch for this myself? Can someone confirm the behaviour is incorrect so I don't waste time fixing it?

----------

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

From report at bugs.python.org  Wed Aug  3 04:21:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Aug 2011 02:21:43 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <E1QoR5Z-0006VU-MO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 07d94cf3521e by Eli Bendersky in branch 'default':
Issue #11049: fix test_forget on installed Python - add os.curdir to sys.path
http://hg.python.org/cpython/rev/07d94cf3521e

----------

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

From report at bugs.python.org  Wed Aug  3 04:22:41 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 03 Aug 2011 02:22:41 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312338161.56.0.710194528836.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Vinay, I can't reproduce your problem here (tried installing Python and running from there), but I suspect it's a sys.path issue (you don't have os.curdir on it, I do). Please let me know if it works now.

----------

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

From report at bugs.python.org  Wed Aug  3 04:24:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Aug 2011 02:24:48 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312338288.46.0.0247474278619.issue12540@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I've added a couple of review comments to the one Peter already made in Rietveld.  Here is an updated patch that addresses all of the comments.  I've tested in briefly on Windows and on OS X and it seems to work OK.  Eli, if you're OK with it, feel free to commit or I will do it.

----------
keywords: +3.2regression, patch -buildbot
stage: needs patch -> commit review
versions: +Python 3.3
Added file: http://bugs.python.org/file22830/issue12540_rev2.patch

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

From report at bugs.python.org  Wed Aug  3 05:40:57 2011
From: report at bugs.python.org (py.user)
Date: Wed, 03 Aug 2011 03:40:57 +0000
Subject: [issue12685] The backslash escape doesn't concatenate two strings in
	one in the with statement
In-Reply-To: <1312342857.65.0.519087958431.issue12685@psf.upfronthosting.co.za>
Message-ID: <1312342857.65.0.519087958431.issue12685@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> with open('/etc/passwd') as f1, \
...      open('/etc/profile) as f2:
  File "<stdin>", line 2
    open('/etc/profile) as f2:
                             ^
SyntaxError: EOL while scanning string literal
>>>

>>> with open('/etc/passwd') as f1,          open('/etc/profile') as f2:
...

working example for a loop:

>>> for i, j in zip(range(10), \
...                 range(5, 15)):
...   print(i, j)
... 
0 5
1 6
2 7
3 8
4 9
5 10
6 11
7 12
8 13
9 14
>>>

>>> for i, j in \
...             zip(range(10), range(5, 15)):
...   print(i, j)
... 
0 5
1 6
2 7
3 8
4 9
5 10
6 11
7 12
8 13
9 14
>>>

----------
components: Interpreter Core
messages: 141596
nosy: py.user
priority: normal
severity: normal
status: open
title: The backslash escape doesn't concatenate two strings in one in the with statement
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Aug  3 06:19:51 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Aug 2011 04:19:51 +0000
Subject: [issue12685] The backslash escape doesn't concatenate two strings in
	one in the with statement
In-Reply-To: <1312342857.65.0.519087958431.issue12685@psf.upfronthosting.co.za>
Message-ID: <1312345191.69.0.31928333911.issue12685@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Why would you expect that to concatenate strings? You have an unterminated quote?

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Aug  3 07:01:31 2011
From: report at bugs.python.org (py.user)
Date: Wed, 03 Aug 2011 05:01:31 +0000
Subject: [issue12685] The backslash escape doesn't concatenate two strings in
	one in the with statement
In-Reply-To: <1312342857.65.0.519087958431.issue12685@psf.upfronthosting.co.za>
Message-ID: <1312347691.35.0.350897723079.issue12685@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

yes, you're right, this is my mistake

----------

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

From report at bugs.python.org  Wed Aug  3 07:16:12 2011
From: report at bugs.python.org (rpointel)
Date: Wed, 03 Aug 2011 05:16:12 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312348572.09.0.482547506285.issue7424@psf.upfronthosting.co.za>


rpointel <python at xiri.fr> added the comment:

Hi,
we have the same problem on OpenBSD (sparc).
You could find more information:
http://marc.info/?l=openbsd-ports&m=131219537505698
Thanks,
Remi.

----------

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

From report at bugs.python.org  Wed Aug  3 07:31:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 03 Aug 2011 05:31:54 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312349514.27.0.251446599681.issue12682@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The "Accepted" Resolution was copied from SF. I recall seeing documentation on SF for the resolutions, but can't find that anymore.

I also recall that on SF, the "accepted" resolution was used to indicate that a patch was accepted (be it a bug fix or a feature request), and also in combination with the "open" status (in the sense of an "approved" resolution, also).

----------
nosy: +loewis

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

From report at bugs.python.org  Wed Aug  3 08:08:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 03 Aug 2011 06:08:14 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312351694.03.0.648519394785.issue12682@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Wed Aug  3 09:23:41 2011
From: report at bugs.python.org (BJ Dierkes)
Date: Wed, 03 Aug 2011 07:23:41 +0000
Subject: [issue12686] argparse - add 'hide' feature
In-Reply-To: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>
Message-ID: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>


New submission from BJ Dierkes <wdierkes at gmail.com>:

Having the ability to 'hide' positional/option arguments and subparsers in argparse would be useful.  For example, I might want to add a subparser for 'somecommand-help' which would be a commands specifically for displaying help output of 'somecommand'.  There is no reason I'd want to display this as an available argument... but rather simply add to the description "For more info try <command>-help".

Something like:

parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
somecommand_help = sub.add_parser('somecommand-help', hide=True)

OR

parser.add_argument('--some-crazy-option', hide=True).


It would then not display in the '--help' output, but would still function when 'somecommand-help' or '--some-crazy-option' is passed at command line.  Would also be an extra bonus to add some sort of interface to 'list_hidden_arguments').

----------
components: None
messages: 141601
nosy: derks
priority: normal
severity: normal
status: open
title: argparse - add 'hide' feature
type: feature request

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

From report at bugs.python.org  Wed Aug  3 11:55:15 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 03 Aug 2011 09:55:15 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

The attached 2.x-written protocol 0 pickle file cannot be loaded by Python 3.2 or 3.3, though it loads successfully in 2.x.

Code used to load:

data = pickle.load(open('test.bin', 'rb'))

Error:

Traceback (most recent call last):
  File "load_it.py", line 4, in <module>
    data = pickle.load(open(sys.argv[1], 'rb'))
ValueError: invalid literal for int() with base 10: "273\n(g8\nS'uint64_t'\np274\ntp275\nsS'Module'\np276\n(g45\n(g39\nS'objc_module'\np277\nNtp278\ntp279\nsS'mach_msg_trailer_size_t'\np280\n(g4\ng190\ntp281\nsS'uint_fast16_t'\np282\n(g8\nS'uint16_t'\np283\ntp284\nsS'pthread_m"

The failure occurs on Ubuntu Natty. This does not appear to be the same issue as #6137.

AFAIK the data contains no classes: just dictionaries, tuples, lists, strings and numbers.

----------
components: Library (Lib)
files: test.bin
messages: 141602
nosy: alexandre.vassalotti, pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: Python 3.2 fails to load protocol 0 pickle
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22831/test.bin

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

From report at bugs.python.org  Wed Aug  3 12:01:18 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 03 Aug 2011 10:01:18 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312365678.82.0.888442595226.issue12687@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I also noticed that in the file there are numerous previous integer values in a similar context, which were parsed without error. For example, if you look at the test.bin file in an editor, the failure occurs while parsing line 515. Notice the similar constructs at lines 510, 507, 504 etc.

----------

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

From senthil at uthcode.com  Wed Aug  3 12:24:59 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 3 Aug 2011 18:24:59 +0800
Subject: [issue12683] urlparse.urljoin different behavior for different
	scheme
In-Reply-To: <1312323514.52.0.93733287768.issue12683@psf.upfronthosting.co.za>
References: <1312323323.6.0.0555659867891.issue12683@psf.upfronthosting.co.za>
	<1312323514.52.0.93733287768.issue12683@psf.upfronthosting.co.za>
Message-ID: <20110803102459.GD2499@mathmagic>

The reason for that seems that svn scheme did not support relative paths
to being with (at least when urlparse was originally written).

>From 1.5 onwards (released sometime in 2008), it has the support for
relative urls and can work with urljoin (by giving relative paths).

http://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls

Since the support was added in 2008 itself, I am okay to consider this
as a bug in Python and fix it in 2.7,3.2 and 3.3

From report at bugs.python.org  Wed Aug  3 12:25:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Aug 2011 10:25:09 +0000
Subject: [issue12683] urlparse.urljoin different behavior for different scheme
In-Reply-To: <1312323514.52.0.93733287768.issue12683@psf.upfronthosting.co.za>
Message-ID: <20110803102459.GD2499@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The reason for that seems that svn scheme did not support relative paths
to being with (at least when urlparse was originally written).

>From 1.5 onwards (released sometime in 2008), it has the support for
relative urls and can work with urljoin (by giving relative paths).

http://subversion.apache.org/docs/release-notes/1.5.html#externals-relative-urls

Since the support was added in 2008 itself, I am okay to consider this
as a bug in Python and fix it in 2.7,3.2 and 3.3

----------

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

From report at bugs.python.org  Wed Aug  3 12:47:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Aug 2011 10:47:24 +0000
Subject: [issue12683] urlparse.urljoin different behavior for different scheme
In-Reply-To: <1312323323.6.0.0555659867891.issue12683@psf.upfronthosting.co.za>
Message-ID: <E1QoYyw-0003xe-JZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5278aa2d9d9a by Senthil Kumaran in branch '2.7':
Fix closes issue12683 - urljoin to work with relative join of svn scheme.
http://hg.python.org/cpython/rev/5278aa2d9d9a

New changeset 57a836eb6916 by Senthil Kumaran in branch '3.2':
Fix closes issue12683 - urljoin to work with relative join of svn scheme.
http://hg.python.org/cpython/rev/57a836eb6916

New changeset a3981d0c4d9b by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue12683 - urljoin to work with relative join of svn scheme.
http://hg.python.org/cpython/rev/a3981d0c4d9b

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

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

From report at bugs.python.org  Wed Aug  3 13:06:33 2011
From: report at bugs.python.org (Jeremy Bicha)
Date: Wed, 03 Aug 2011 11:06:33 +0000
Subject: [issue12627] Implement PEP 394: The "python" Command on Unix-Like
	Systems
In-Reply-To: <1311474695.62.0.740113282168.issue12627@psf.upfronthosting.co.za>
Message-ID: <1312369593.76.0.247301924368.issue12627@psf.upfronthosting.co.za>


Changes by Jeremy Bicha <jbicha at ubuntu.com>:


----------
nosy: +jbicha

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

From report at bugs.python.org  Wed Aug  3 13:46:58 2011
From: report at bugs.python.org (Alex Leon)
Date: Wed, 03 Aug 2011 11:46:58 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312372018.0.0.112232867709.issue12541@psf.upfronthosting.co.za>


Alex Leon <aeleon at gmail.com> added the comment:

For some reason a caret went missing in the regex fix.
It should read

'realm=(["\']?)([^"\']*)\\2', re.I)

----------

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

From report at bugs.python.org  Wed Aug  3 13:54:09 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 03 Aug 2011 11:54:09 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312372449.61.0.368374912454.issue11049@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Eli, test_support is now completing on my system without errors.

----------

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

From report at bugs.python.org  Wed Aug  3 13:58:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Aug 2011 11:58:55 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312372735.58.0.621980950531.issue12541@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/issue12541>
_______________________________________

From report at bugs.python.org  Wed Aug  3 14:06:47 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 03 Aug 2011 12:06:47 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1312373207.52.0.697886655527.issue11049@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Vinay, great news. Thanks.

----------

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

From report at bugs.python.org  Wed Aug  3 14:30:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Aug 2011 12:30:59 +0000
Subject: [issue12686] argparse - document (and improve?) use of SUPPRESS with
	help=
In-Reply-To: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>
Message-ID: <1312374659.32.0.188289132073.issue12686@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is partly a doc issue, but there also appear to be bugs in the way the existing functionality works (although it is hard to tell for sure since it isn't documented :)

Try using the value argparse.SUPPRESS as the value of help= in various places and you'll see what I mean.

----------
assignee:  -> docs at python
components: +Documentation, Library (Lib) -None
keywords: +easy
nosy: +bethard, docs at python, r.david.murray
stage:  -> needs patch
title: argparse - add 'hide' feature -> argparse - document (and improve?) use of SUPPRESS with help=
versions: +Python 3.3

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

From report at bugs.python.org  Wed Aug  3 14:58:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Aug 2011 12:58:51 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312376331.82.0.429815402498.issue12677@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It seems to me that right() always turns the turtle clockwise, both with the "standard" and the "logo" mode.
I agree that changing left->right and leave clockwise is better than changing clockwise->counterclockwise.
I don't think it's worth mentioning the mode here.
(On a side note: I was expecting the 'turtle' to be an instance of some Turtle class defined in the turtle module, or perhaps a singleton, but it turned out that in 'turtle.right()' turtle is the module itself.  It might be better to say something like "After importing the :mod:`turtle` module, ...".)

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

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

From report at bugs.python.org  Wed Aug  3 16:34:32 2011
From: report at bugs.python.org (Peter Caven)
Date: Wed, 03 Aug 2011 14:34:32 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312382072.79.0.00291468091743.issue12540@psf.upfronthosting.co.za>


Peter Caven <pcaven at gmail.com> added the comment:

Terry,  sorry about the delay in responding: I'm using 32bit Python. I haven't had a chance yet to try the 64 bit release.

----------

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

From report at bugs.python.org  Wed Aug  3 18:04:12 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 03 Aug 2011 16:04:12 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312387452.48.0.749876812529.issue7424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just a guess: it might be a stack overflow. Could you try to reduce
Py_DEFAULT_RECURSION_LIMIT in Python/ceval.c and see if you get
a RuntimeError instead?

See also: issue #1212900

----------

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

From report at bugs.python.org  Wed Aug  3 21:46:36 2011
From: report at bugs.python.org (Jon)
Date: Wed, 03 Aug 2011 19:46:36 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1312400796.04.0.401443596565.issue12641@psf.upfronthosting.co.za>


Jon <jon.forums at gmail.com> added the comment:

are you ok with a targeted patch similar to what's being discussed at

http://sourceforge.net/mailarchive/message.php?msg_id=27895558

assuming the regex search the output of `gcc -dumpspecs` idea is valid?

----------

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

From report at bugs.python.org  Wed Aug  3 22:33:28 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 03 Aug 2011 20:33:28 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1312403608.45.0.55096035925.issue12641@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

it is save to remove  -mno-cygwin from Mingw32CCompiler

----------

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

From report at bugs.python.org  Wed Aug  3 22:40:13 2011
From: report at bugs.python.org (Eli_B)
Date: Wed, 03 Aug 2011 20:40:13 +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: <1312404013.99.0.61760321754.issue6792@psf.upfronthosting.co.za>


Changes by Eli_B <eli.boyarski at gmail.com>:


----------
nosy: +Eli_B

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

From report at bugs.python.org  Wed Aug  3 23:18:47 2011
From: report at bugs.python.org (John Simon)
Date: Wed, 03 Aug 2011 21:18:47 +0000
Subject: [issue12688] ConfigParser.__init__(iterpolation=None) documentation
	!= behavior
In-Reply-To: <1312406327.25.0.971358646262.issue12688@psf.upfronthosting.co.za>
Message-ID: <1312406327.25.0.971358646262.issue12688@psf.upfronthosting.co.za>


New submission from John Simon <john at johnsoft.com>:

The ConfigParser docs say that when __init__ is called with interpolation=None, no interpolation occurs. But when this is done in Python 3.2.1, it actually results in an AttributeError upon getting or setting a value, due to self._interpolation being set to None.

This incredibly simple patch brings the behavior inline with the docs.

----------
components: Library (Lib)
files: patch.txt
messages: 141615
nosy: zildjohn01
priority: normal
severity: normal
status: open
title: ConfigParser.__init__(iterpolation=None) documentation != behavior
type: behavior
Added file: http://bugs.python.org/file22832/patch.txt

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

From report at bugs.python.org  Wed Aug  3 23:27:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Aug 2011 21:27:00 +0000
Subject: [issue12688] ConfigParser.__init__(iterpolation=None) documentation
	!= behavior
In-Reply-To: <1312406327.25.0.971358646262.issue12688@psf.upfronthosting.co.za>
Message-ID: <1312406820.47.0.390514350278.issue12688@psf.upfronthosting.co.za>


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


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Thu Aug  4 00:15:27 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 03 Aug 2011 22:15:27 +0000
Subject: [issue12688] ConfigParser.__init__(iterpolation=None) documentation
	!= behavior
In-Reply-To: <1312406327.25.0.971358646262.issue12688@psf.upfronthosting.co.za>
Message-ID: <1312409727.75.0.713396470712.issue12688@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Hey there! Thanks for your report. However:

1. this is a duplicate of #11324

2. AFAICT this is corrected in 3.2.1 (3.2.0 had the bug). Just downloaded the source distribution from python.org, it is indeed fixed.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> ConfigParser(interpolation=None) doesn't work

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

From report at bugs.python.org  Thu Aug  4 02:27:38 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 04 Aug 2011 00:27:38 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312417658.74.0.474008468425.issue12437@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

At least in Windows, the exception object has its `winerror` attribute correctly set to 126, which is also translated to POSIX `errno` with `winerror_to_errno()`; the latter gives us EINVAL (22).

----------
versions: +Python 3.3

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

From report at bugs.python.org  Thu Aug  4 02:37:59 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Thu, 04 Aug 2011 00:37:59 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312418279.23.0.776383702495.issue12437@psf.upfronthosting.co.za>


Santoso Wijaya <santoso.wijaya at gmail.com> added the comment:

>From what I gather from the code, when dlopen fails in POSIX platforms, ctypes raises an PyExc_OSError instantiated with a simple string (via PyErr_SetString()). I suppose this could be changed to raise a more complex tuple, instead (like its WindowsError equivalent when LoadLibrary fails in Windows platforms), but that might break existing code that relies on this behavior. 3.3 only?

----------

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

From report at bugs.python.org  Thu Aug  4 02:43:52 2011
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Xavier_Bourlet?=)
Date: Thu, 04 Aug 2011 00:43:52 +0000
Subject: [issue12498] asyncore.dispatcher_with_send,
	disconnection problem + miss-conception
In-Reply-To: <1311540678.07.0.080079698738.issue12498@psf.upfronthosting.co.za>
Message-ID: <CAG9r-DZThJf5WEgnoLUfsA7fzDHJAVrk0eixBoYWg=1vXbV5-g@mail.gmail.com>


Fran?ois-Xavier Bourlet <bombela at gmail.com> added the comment:

I am currently busy, but i will try to allocate some time to propose a
path soon.

Cheers,

2011/7/24 Charles-Fran?ois Natali <report at bugs.python.org>:
>
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
> Hello,
>
>> Actually the class asyncore.dispatcher_with_send do not handle properly
>> disconnection. When the endpoint shutdown his sending part of the socket,
>> but keep the socket open in reading, the current implementation of
>> dispatcher_with_send will close the socket without sending pending data.
>
> Yes, that's a common problem with "naive" networking code.
>
>> Note also that this class try to initiate a send even if the socket is maybe
>> not ready for writing:
>>
>> Here's a simple fix:
>> ? ? def send(self, data):
>> ? ? ? ? if self.debug:
>> ? ? ? ? ? ? self.log_info('sending %s' % repr(data))
>> ? ? ? ? self.out_buffer = self.out_buffer + data
>> - ? ? ? self.initiate_send()
>>
>
> Hum, I'm not sure about this.
> dispatcher is just a thin wrapper around the underlying socket, so the
> semantic of `send` should be the same as `socket.send`, i.e. just call
> the send(2) syscall. I think it's the application's reponsibility to
> check that the socket is indeed writable, and to cope with potential
> failures (e.g. EAGAIN or ENOTCONN).
>
>> Last but not last, the buffer size of each socket send are way to small
>> (512, a third of an usual TCP frame). Here's the code with a bumped value:
>
> Indeed, 1/3 of the ethernet MTU is quite small.
>
> Would you like to submit a patch?
>
> ----------
> nosy: +neologix
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12498>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Aug  4 03:54:51 2011
From: report at bugs.python.org (Andrew Luzin)
Date: Thu, 04 Aug 2011 01:54:51 +0000
Subject: [issue12689] IDLE crashes after pressing ctrl+space
In-Reply-To: <1312422891.25.0.508224720605.issue12689@psf.upfronthosting.co.za>
Message-ID: <1312422891.25.0.508224720605.issue12689@psf.upfronthosting.co.za>


New submission from Andrew Luzin <andrew.luzin at gmail.com>:

Steps to reproduce:
1. Open IDLE
2. File -> New Window
3. Just press <ctrl>+<space>
4. IDLE crashes

IDLE version: 3.2
Python version: 3.2
Tk version 8.5

Thanks!

----------
components: IDLE
messages: 141620
nosy: Andrew.Luzin
priority: normal
severity: normal
status: open
title: IDLE crashes after pressing ctrl+space
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug  4 03:56:08 2011
From: report at bugs.python.org (Andrew Luzin)
Date: Thu, 04 Aug 2011 01:56:08 +0000
Subject: [issue12689] IDLE crashes after pressing ctrl+space
In-Reply-To: <1312422891.25.0.508224720605.issue12689@psf.upfronthosting.co.za>
Message-ID: <1312422968.88.0.297367120986.issue12689@psf.upfronthosting.co.za>


Changes by Andrew Luzin <andrew.luzin at gmail.com>:


----------
type:  -> crash

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

From report at bugs.python.org  Thu Aug  4 03:58:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Aug 2011 01:58:32 +0000
Subject: [issue12689] IDLE crashes after pressing ctrl+space
In-Reply-To: <1312422891.25.0.508224720605.issue12689@psf.upfronthosting.co.za>
Message-ID: <1312423112.4.0.606211773999.issue12689@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duplicate of 1028.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Tkinter binding involving Control-spacebar raises unicode error
type: crash -> behavior

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

From report at bugs.python.org  Thu Aug  4 04:33:31 2011
From: report at bugs.python.org (Gary Levin)
Date: Thu, 04 Aug 2011 02:33:31 +0000
Subject: [issue12690] tkinter bug 2643483
In-Reply-To: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>
Message-ID: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>


New submission from Gary Levin <gary.marc.levin at gmail.com>:

A bug from Tkinter is present in the current release.

https://sourceforge.net/tracker/index.php?func=detail&aid=2643483&group_id=5649&atid=105649

8tixFileEntry:OpenFile dialogtype tk_chooseDirectory only opens once.

There is a bug fix in the code.  I tried it in my copy and it does fix the problem.  Perhaps it can be propagated in Python 3 releases.  Or push for tkinter to update their copy.

----------
components: Tkinter
messages: 141622
nosy: Gary.Levin
priority: normal
severity: normal
status: open
title: tkinter bug 2643483
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  4 06:31:23 2011
From: report at bugs.python.org (Elias Pipping)
Date: Thu, 04 Aug 2011 04:31:23 +0000
Subject: [issue1099] Mac compile fails with pydebug and framework enabled
In-Reply-To: <1188886622.31.0.867109013105.issue1099@psf.upfronthosting.co.za>
Message-ID: <1312432283.15.0.449193633459.issue1099@psf.upfronthosting.co.za>


Changes by Elias Pipping <pipping at exherbo.org>:


----------
nosy:  -pipping

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

From report at bugs.python.org  Thu Aug  4 06:31:43 2011
From: report at bugs.python.org (Elias Pipping)
Date: Thu, 04 Aug 2011 04:31:43 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1312432303.38.0.886556105414.issue7247@psf.upfronthosting.co.za>


Changes by Elias Pipping <pipping at exherbo.org>:


----------
nosy: +pipping

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

From report at bugs.python.org  Thu Aug  4 10:24:05 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Aug 2011 08:24:05 +0000
Subject: [issue12690] Tix bug 2643483
In-Reply-To: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>
Message-ID: <1312446245.98.0.214584222704.issue12690@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I think you are confusing the Tix widget set, an independent Tk-based project, with Tkinter, the Python interface to Tk, which is part of Python.  The problem you linked to appears to be a Tix issue.  That code is not part of Python.  It needs to be addressed by the Tix project.

----------
nosy: +ned.deily
resolution:  -> rejected
status: open -> closed
title: tkinter bug 2643483 -> Tix bug 2643483

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

From report at bugs.python.org  Thu Aug  4 13:54:05 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 04 Aug 2011 11:54:05 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312458845.29.0.271443778062.issue12675@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

I'm having a look to see if I can make tokenize.py better match the real tokenizer, but I need some feedback on a couple of design decisions. 

First, how to handle tokenization errors? There are three possibilities:

1. Generate an ERRORTOKEN, resynchronize, and continue to tokenize from after the error. This is what tokenize.py currently does in the two cases where it detects an error.

2. Generate an ERRORTOKEN and stop tokenizing. This is what tokenizer.c does.

3. Raise an exception (IndentationError, SyntaxError, or TabError). This is what the user sees when the parser is invoked from pythonrun.c.

Since the documentation for tokenize.py says, "It is designed to match the working of the Python tokenizer exactly", I think that implementing option (2) is best here. (This will mean changing the behaviour of tokenize.py in the two cases where it currently detects an error, so that it stops tokenizing.)

Second, how to record the cause of the error? The real tokenizer records the cause of the error in the 'done' field of the 'tok_state" structure, but tokenize.py loses this information. I propose to add fields to the TokenInfo structure (which is a namedtuple) to record this information. The real tokenizer uses numeric constants from errcode.h (E_TOODEEP, E_TABSPACE, E_DEDENT etc), and pythonrun.c converts these to English-language error messages (E_TOODEEP: "too many levels of indentation"). Both of these pieces of information will be useful, so I propose to add two fields "error" (containing a string like "TOODEEP") and "errormessage" (containing the English-language error message).

----------

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

From report at bugs.python.org  Thu Aug  4 14:21:06 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 04 Aug 2011 12:21:06 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312460466.34.0.685267027573.issue12675@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Having looked at some of the consumers of the tokenize module, I don't think my proposed solutions will work.

It seems to be the case that the resynchronization behaviour of tokenize.py is important for consumers that are using it to transform arbitrary Python source code (like 2to3.py). These consumers are relying on the "roundtrip" property that X == untokenize(tokenize(X)). So solution (1) is necessary for the handling of tokenization errors.

Also, that fact that TokenInfo is a 5-tuple is relied on in some places (e.g. lib2to3/patcomp.py line 38), so it can't be extended. And there are consumers (though none in the standard library) that are relying on type=ERRORTOKEN being the way to detect errors in a tokenization stream. So I can't overload that field of the structure.

Any good ideas for how to record the cause of error without breaking backwards compatibility?

----------

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

From report at bugs.python.org  Thu Aug  4 14:26:06 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 04 Aug 2011 12:26:06 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312460766.99.0.687342823254.issue12675@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Ah ... TokenInfo is a *subclass* of namedtuple, so I can add extra properties to it without breaking consumers that expect it to be a 5-tuple.

----------

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

From report at bugs.python.org  Thu Aug  4 15:44:05 2011
From: report at bugs.python.org (Matthias Troffaes)
Date: Thu, 04 Aug 2011 13:44:05 +0000
Subject: [issue6695] PyXXX_ClearFreeList for dict, set, and list
In-Reply-To: <1250181931.61.0.791211788439.issue6695@psf.upfronthosting.co.za>
Message-ID: <1312465445.79.0.940036222474.issue6695@psf.upfronthosting.co.za>


Matthias Troffaes <matthias.troffaes at gmail.com> added the comment:

Patch against current tip attached.

I can no longer reproduce the large memory leaks with the current tip (which is of course wonderful!), so I guess the second part of the patch (freeing the freelists during gc.collect) makes no longer sense.

----------
Added file: http://bugs.python.org/file22833/py3k-04082011-clearfreelist-dict_set_list.patch

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

From report at bugs.python.org  Thu Aug  4 15:51:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 13:51:39 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312465899.52.0.650896425535.issue12677@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

As mentioned by Ezio, and I also verified myself, mode() doesn't influence the orientation on left()/right() methods (probably it affects some other functs?). Following was Ezio and I discussed on IRC, I've updated the 2 patches to add a small note that you have to import turtle before trying the mentioned commands.

----------
Added file: http://bugs.python.org/file22834/turtle_right-default-v2.patch

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

From report at bugs.python.org  Thu Aug  4 15:51:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 13:51:50 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312465910.19.0.856099425612.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22835/turtle_right-2.7-v2.patch

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

From report at bugs.python.org  Thu Aug  4 16:14:35 2011
From: report at bugs.python.org (rpointel)
Date: Thu, 04 Aug 2011 14:14:35 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312467275.68.0.609507638622.issue7424@psf.upfronthosting.co.za>


rpointel <python at xiri.fr> added the comment:

I changed the value from 1000 to 200, and it crashed the same way, then I tested with 20, and it ran into a runtime error but in a different place:

c++ -pthread -L/home/ports/pobj/Python-2.7.1/Python-2.7.1 -Wl,--export-dynamic -o python  Modules/python.o  -lpython2.7 -pthread  -lutil   -lm  
/home/ports/pobj/Python-2.7.1/Python-2.7.1/libpython2.7.so.0.0: warning: tmpnam() possibly used unsafely; consider using mkstemp()
/home/ports/pobj/Python-2.7.1/Python-2.7.1/libpython2.7.so.0.0: warning: tempnam() possibly used unsafely; consider using mkstemp()
/home/ports/pobj/Python-2.7.1/Python-2.7.1/libpython2.7.so.0.0: warning: strcpy() is almost always misused, please use strlcpy()
/home/ports/pobj/Python-2.7.1/Python-2.7.1/libpython2.7.so.0.0: warning: sprintf() is often misused, please use snprintf()
/home/ports/pobj/Python-2.7.1/Python-2.7.1/libpython2.7.so.0.0: warning: strcat() is almost always misused, please use strlcat()
Traceback (most recent call last):
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/site.py", line 553, in <module>
    main()
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sysconfig.py", line 282, in _init_posix
    _parse_makefile(makefile, vars)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sysconfig.py", line 195, in _parse_makefile
    _variable_rx = re.compile("([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*)")
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/re.py", line 243, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_compile.py", line 500, in compile
    p = sre_parse.parse(p, flags)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_parse.py", line 673, in parse
    p = _parse_sub(source, pattern, 0)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_parse.py", line 308, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_parse.py", line 633, in _parse
    p = _parse_sub(source, state)
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_parse.py", line 308, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/sre_parse.py", line 381, in _parse
    subpattern = SubPattern(state)
RuntimeError: maximum recursion depth exceeded while calling a Python object
*** Error code 1

Then I tried again with the value set to 100, and it ran into the original segfault again.

Thanks for your help.

----------

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

From report at bugs.python.org  Thu Aug  4 16:22:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Aug 2011 14:22:19 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312467739.32.0.903039877075.issue7424@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem with such issues is that:
- they are not reproduceable by someone of the core team
- they only seem to occur in non-debug mode
- they are probably tied to a specific compiler variant, either because of a compiler bug, or some aggressive optimization combined with some misled assumption in Python's code

To narrow it down, you could:
- try with other compiler versions
- try with other Python versions from python.org (for example the recent 3.2.1)

----------

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

From report at bugs.python.org  Thu Aug  4 17:59:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Aug 2011 15:59:37 +0000
Subject: [issue12690] Tix bug 2643483
In-Reply-To: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>
Message-ID: <1312473577.8.0.514640135188.issue12690@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ah, I see now that the question is actually about the python.org Windows installers which, as a service to the user, pull in the external source of Tix during the build.  (Tix is not included in the Python source distribution nor with the Mac OS X installers.)  Martin, any interest in adding a Tix patch to the installer build?

----------
components: +Windows -Tkinter
nosy: +loewis
status: closed -> pending
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

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

From report at bugs.python.org  Thu Aug  4 21:11:09 2011
From: report at bugs.python.org (Elias Pipping)
Date: Thu, 04 Aug 2011 19:11:09 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1312485069.1.0.543280922726.issue7247@psf.upfronthosting.co.za>


Elias Pipping <pipping at exherbo.org> added the comment:

I had this problem as well. Recompiling my kernel with CONFIG_DNOTIFY=y fixed it (Thanks to David Leverton for pointing this out to me).

----------

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

From report at bugs.python.org  Thu Aug  4 23:10:07 2011
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 04 Aug 2011 21:10:07 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1312492207.16.0.66590780577.issue7424@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Thanks Antoine for your response.
Python 3.2.1 and Python 2.4.6 have been successfully installed (but Python 2.5.4 and Python 2.7.1 failed).

----------

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

From report at bugs.python.org  Fri Aug  5 00:21:29 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 04 Aug 2011 22:21:29 +0000
Subject: [issue12691] tokenize.untokenize is broken
Message-ID: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>


New submission from Gareth Rees <gdr at garethrees.org>:

tokenize.untokenize is completely broken.

    Python 3.2.1 (default, Jul 19 2011, 00:09:43) 
    [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import tokenize, io
    >>> t = list(tokenize.tokenize(io.BytesIO('1+1'.encode('utf8')).readline))
    >>> tokenize.untokenize(t)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tokenize.py", line 250, in untokenize
        out = ut.untokenize(iterable)
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tokenize.py", line 179, in untokenize
        self.add_whitespace(start)
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/tokenize.py", line 165, in add_whitespace
        assert row <= self.prev_row
    AssertionError

The assertion is simply bogus: the <= should be >=.

The reason why no-one has spotted this is that the unit tests for the tokenize module only ever call untokenize() in "compatibility" mode, passing in a 2-tuple instead of a 5-tuple.

I propose to fix this, and add unit tests, at the same time as fixing other problems with tokenize.py (issue12675).

----------
components: Library (Lib)
messages: 141634
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: tokenize.untokenize is broken
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug  5 00:22:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Aug 2011 22:22:27 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312496547.8.0.857376241078.issue12691@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> test needed

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

From report at bugs.python.org  Fri Aug  5 00:30:01 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 22:30:01 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312497001.08.0.993512629694.issue11572@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Brandon, I really like to see your patch applied, let's see what I can do (I also added Ezio in the loop).

I think you only addressed half of msg132140 : could you please have a look at the first ?ric's question?

Also, still ?ric made a comment on rietveld (you'd access to it clicking on 'review' next to your patch) so it would be nice if you can reply to that too.

About the ~100% coverage, it's probably me but I can't get more then 67%:

$ ./python -m coverage run --pylib --source=copy Lib/test/regrtest.py test_copy
[1/1] test_copy
1 test OK.
$ ./python -m coverage report | grep copy
Lib/copy     182     60    67%

How did you compute the coverage?

----------
nosy: +ezio.melotti, sandro.tosi

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

From report at bugs.python.org  Fri Aug  5 00:32:14 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 22:32:14 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312497134.77.0.656672117454.issue12691@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Gareth, would you like to provide a patch to fix the bug you spotted and add the relative case into the testsuite?

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Fri Aug  5 00:59:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Aug 2011 22:59:09 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312498749.43.0.693225777354.issue11572@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

ISTM that the patch is trying to do too many things at once:
1) increase the test coverage, possibly fixing some bugs discovered while doing so;
2) refactor the tests to use the correct assert methods;
3) get rid of old code, and do some refactoring in copy.py;

I'm not sure any of the changes in copy.py is necessary to make the test suite pass, even after the additions you included in the patch (I haven't tested though).  If this is the case, the refactoring/cleanup of copy.py should IMHO be committed separately.
For the tests it's probably fine to commit both the additions and the refactoring together (i.e., it's not worth wasting time splitting the patch).

----------

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

From report at bugs.python.org  Fri Aug  5 01:01:01 2011
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 04 Aug 2011 23:01:01 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312498861.23.0.594872824679.issue12691@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

See my last paragraph: I propose to deliver a single patch that fixes both this bug and issue12675. I hope this is OK. (If you prefer, I'll try to split the patch in two.)

I just noticed another bug in untokenize(): in compatibility mode, if untokenize() is passed an iterator rather than a list, then the first token gets discarded:

    Python 3.3.0a0 (default:c099ba0a278e, Aug  2 2011, 12:35:03) 
    [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from tokenize import untokenize
    >>> from token import *
    >>> untokenize([(NAME, 'hello')])
    'hello '
    >>> untokenize(iter([(NAME, 'hello')]))
    ''

No-one's noticed this because the unit tests only ever pass lists to untokenize().

----------

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

From report at bugs.python.org  Fri Aug  5 01:03:52 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 04 Aug 2011 23:03:52 +0000
Subject: [issue9338] argparse optionals with nargs='+' can't be followed by
	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1312499032.88.0.253986456075.issue9338@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

is there a chance to fix this issue?

----------
nosy: +wrobell

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

From report at bugs.python.org  Fri Aug  5 01:15:16 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 23:15:16 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312499716.03.0.475649155238.issue11572@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After a quick chat with Ezio, we tried to revert the changes to copy.py while keeping the ones on test, and the test suite passes.

The next steps would probably be to just commit the diff for test_copy.py and see if the changes on copy.py are really worth.

Nick, since this issue is assigned to you, what do you want to do? would you like me to handle the test-commit part and still be assigned to you for the remaining part?

----------

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

From report at bugs.python.org  Fri Aug  5 01:22:52 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 23:22:52 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312500172.89.0.53450428334.issue12691@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

The general rule would be to have separate patches. But in this case, if we have interdipendent changes, then those should be "packed" in a single patch (f.e. if changes to tokenize break untokenize, than those parts should be joined).

----------

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

From report at bugs.python.org  Fri Aug  5 01:27:34 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 04 Aug 2011 23:27:34 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312500454.69.0.305920041228.issue12691@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ericsnow

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

From report at bugs.python.org  Fri Aug  5 01:28:12 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 04 Aug 2011 23:28:12 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312500492.23.0.973832864619.issue11572@psf.upfronthosting.co.za>


Brandon Craig Rhodes <brandon at rhodesmill.org> added the comment:

Ezio and Sandro, thank you very much for your attention to this issue, and for helping me split it into manageable chunks! To answer the question about why "coverage" does not show as high a total as it ought: it's because coverage normally can't see the outer, global scope execution of modules that are already imported by the time "coverage" itself can take control and install a tracer. I have another patch outstanding that fixes this ? we are still working on it, but the code works fine ? if you want to run "coverage" and see a more accurate number: http://bugs.python.org/issue11561

----------

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

From report at bugs.python.org  Fri Aug  5 01:29:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Aug 2011 23:29:33 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1312500573.92.0.379005825459.issue11561@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/issue11561>
_______________________________________

From report at bugs.python.org  Fri Aug  5 01:46:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 04 Aug 2011 23:46:08 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312501568.45.0.331277644252.issue11572@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd assigned this to myself since I was discussing it with Brandon when he was working on it at the PyCon sprints. Since I certainly don't want to block anyone else getting to it, I'm unassigning it - feel free to take it forward :)

IIRC, the copy.py changes were things Brandon and I discussed at the sprints as cases where they were legacy code that was no longer needed in Py3k, so it made more sense to just delete them rather than add tests to cover them. Definitely makes sense to split those changes out into a separate patch, though (easier to revert if we later discover the code isn't as useless as we think it is).

----------
assignee: ncoghlan -> 

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

From report at bugs.python.org  Fri Aug  5 03:35:36 2011
From: report at bugs.python.org (Jon Buller)
Date: Fri, 05 Aug 2011 01:35:36 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1312492207.16.0.66590780577.issue7424@psf.upfronthosting.co.za>
Message-ID: <4E3B48CB.3000401@bullers.net>


Jon Buller <jon at bullers.net> added the comment:

I recently upgraded my SparcStation20 to NetBSD-current and thought I 
would try installing python again.  I found that both 2.7.1 and whatever 
was the most current 2.5 pkgsrc version as of a few months ago built and 
installed just fine.  I'm sorry I can no longer help debug this, but the 
bug was very repeatable on 2.6 and 2.7 for several years and often 
happened with 2.5 as well. But I can no longer repeat it.  I also can't 
say if it is a GCC bug, a NetBSD kernel or libc bug, or a python bug. I 
was sort of expecting it to be a NetBSD bug since I don't remember ever 
having problems with x86, amd64, or sparc64 NetBSD systems, but I still 
believe it could be just about anywhere.

Jon

----------

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

From report at bugs.python.org  Fri Aug  5 07:02:32 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Aug 2011 05:02:32 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
Message-ID: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Specifically, test.test_urllib2net.OtherNetworkTests.test_sites_no_connection_close is leaving a socket open somewhere, but tracking down exactly whom is to blame is a mess since socket.SocketIO.close() explicitly relies on refcounting to shut down a socket.

----------
components: Tests
messages: 141645
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: test_urllib2net is triggering a ResourceWarning
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  5 07:14:31 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Aug 2011 05:14:31 +0000
Subject: [issue12693] test.support.transient_internet prints to stderr when
	verbose is false
Message-ID: <1312521271.03.0.978158187308.issue12693@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

When verbose mode if OFF, test.support.transient_internet prints out what resource was unavailable before raising the ResourceDenied exception. Not sure if this is a bug (since it has existed for a while) or it is on purpose and just happens to seem counter-intuitive.

Assigning to Victor since it seems to be his code (that Antoine applied).

----------
assignee: haypo
components: Tests
messages: 141646
nosy: brett.cannon, haypo
priority: low
severity: normal
status: open
title: test.support.transient_internet prints to stderr when verbose is false

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

From report at bugs.python.org  Fri Aug  5 08:39:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Aug 2011 06:39:20 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <E1QpE3y-0007n2-K9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cc86f4ca5020 by Ned Deily in branch '3.2':
Issue #12540: Prevent zombie IDLE processes on Windows due to changes
http://hg.python.org/cpython/rev/cc86f4ca5020

New changeset c2fd1ce1c6d4 by Ned Deily in branch 'default':
Issue #12540: Prevent zombie IDLE processes on Windows due to changes
http://hg.python.org/cpython/rev/c2fd1ce1c6d4

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

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

From report at bugs.python.org  Fri Aug  5 08:43:12 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Aug 2011 06:43:12 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312526592.71.0.637913394434.issue12540@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With Eli's concurrence, I have applied the updated patch to 3.2 (for 3.2.2) and to default (for 3.3).

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Aug  5 09:36:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 05 Aug 2011 07:36:36 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <1312529796.75.0.157837001812.issue12692@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Relevant: http://mail.python.org/pipermail/python-dev/2011-July/112551.html

----------
nosy: +nadeem.vawda

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

From report at bugs.python.org  Fri Aug  5 09:38:02 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 05 Aug 2011 07:38:02 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <1312529882.88.0.768315448621.issue12692@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
versions: +Python 3.2

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

From report at bugs.python.org  Fri Aug  5 11:29:01 2011
From: report at bugs.python.org (Alexander Belchenko)
Date: Fri, 05 Aug 2011 09:29:01 +0000
Subject: [issue12694] crlf.py script from Tools doesn't work with Python 3.2
Message-ID: <1312536541.59.0.919567642334.issue12694@psf.upfronthosting.co.za>


New submission from Alexander Belchenko <bialix at ukr.net>:

Attempt to use crlf.py script from standard windows install always fail with traceback:

C:\Python32\Tools\Scripts>C:\Python32\python.exe crlf.py 2to3.py
Traceback (most recent call last):
  File "crlf.py", line 23, in <module>
    main()
  File "crlf.py", line 12, in main
    if '\0' in data:
TypeError: Type str doesn't support the buffer API

C:\Python32\Tools\Scripts>C:\Python32\python.exe -V
Python 3.2

----------
messages: 141650
nosy: bialix
priority: normal
severity: normal
status: open
title: crlf.py script from Tools doesn't work with Python 3.2
versions: Python 3.2

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

From report at bugs.python.org  Fri Aug  5 12:45:18 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 10:45:18 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1312541118.76.0.0806109779339.issue12326@psf.upfronthosting.co.za>


Changes by Martin von Gagern <Martin.vGagern at gmx.net>:


----------
nosy: +gagern

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

From report at bugs.python.org  Fri Aug  5 12:49:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 10:49:39 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1311594636.15.0.883172354063.issue12326@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj2TX91GgN6A=dhY3=T_GmWpA5GS7XOsU6K6xeM1O-zxLQ@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Mon, Jul 25, 2011 at 13:50, ?ric Araujo <report at bugs.python.org> wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

Luckily that has just been reverted.

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Fri Aug  5 12:50:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Aug 2011 10:50:46 +0000
Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe
	imports
In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>
Message-ID: <1312541446.23.0.959003233163.issue12680@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> PyImport_ExecCodeModuleEx adds the module to sys.modules *before*
> actually executing the code. This is a design flaw (can it really be
> changed? )

I guess it is done so to allow for circular imports.

> The second bug: in cPickle.c: func_class() 
> cPickle 'manually' checks if a module is in sys.modules instead of
> letting the import mechanism do it for him (hence breaking the import
> lock's defense here).

I would guess it is an optimization shortcut. A solution (while keeping the optimization) would be to take the import lock before checking sys.modules.

Note that the _pickle module in 3.x has the same kind of logic, and therefore probably the same issue too (haven't tested).

----------
nosy: +pitrou
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug  5 12:53:44 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 10:53:44 +0000
Subject: [issue12695] subprocess.Popen: OSError: [Errno 9] Bad file descriptor
Message-ID: <1312541623.96.0.711973395002.issue12695@psf.upfronthosting.co.za>


New submission from Martin von Gagern <Martin.vGagern at gmx.net>:

suprocess.Popen on POSIX (using _posixsubprocess Module) has a good chance of repeatedly closing the same file descriptor if the descriptor for stdin is also used for stdout and/or stderr. Only stdout and stderr are checked for equality with one another.

This breaks webbrowser.open for me, as the browser remote has all three descriptors redirected from/to /dev/null. This breaks "pydoc -p". I've taken this scenario and turned it into a unit test, which you find attached together with a proposed fix.

On my currently installed Python 3.2, the unit tests results in this traceback (and two more like it for other test classes):

ERROR: test_inouterr_fileobj (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_subprocess.py", line 630, in test_inouterr_fileobj
    stderr = devnull)
  File "/usr/lib64/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.2/subprocess.py", line 1330, in _execute_child
    raise child_exception_type(errno_num, err_msg)
OSError: [Errno 9] Bad file descriptor

----------
components: Library (Lib)
files: subprocess.patch
keywords: patch
messages: 141653
nosy: gagern
priority: normal
severity: normal
status: open
title: subprocess.Popen: OSError: [Errno 9] Bad file descriptor
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22836/subprocess.patch

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

From report at bugs.python.org  Fri Aug  5 13:00:18 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 11:00:18 +0000
Subject: [issue12695] subprocess.Popen: OSError: [Errno 9] Bad file descriptor
In-Reply-To: <1312541623.96.0.711973395002.issue12695@psf.upfronthosting.co.za>
Message-ID: <1312542018.97.0.1475226076.issue12695@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Sorry, this is a duplicate of issue #11432. Failed to find that, and also failed to realize that python is now using hg and my svn checkout might be outdated. Sorry there.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Fri Aug  5 13:33:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Aug 2011 11:33:41 +0000
Subject: [issue12693] test.support.transient_internet prints to stderr when
	verbose is false
In-Reply-To: <1312521271.03.0.978158187308.issue12693@psf.upfronthosting.co.za>
Message-ID: <1312544021.98.0.0103979481445.issue12693@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm pretty sure this was intentional.  It is analogous to Skip messages and the messages issued when a resource hasn't been enabled, which also print when verbose is not true: the test wasn't run, and it lets you know why.

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

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

From report at bugs.python.org  Fri Aug  5 13:36:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Aug 2011 11:36:12 +0000
Subject: [issue12032] Tools/Scripts/crlf.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <1312544172.71.0.63718339298.issue12032@psf.upfronthosting.co.za>


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


----------
title: Tools/Scripts/crlv.py needs updating for python 3+ -> Tools/Scripts/crlf.py needs updating for python 3+
type: crash -> behavior

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

From report at bugs.python.org  Fri Aug  5 13:37:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Aug 2011 11:37:17 +0000
Subject: [issue12694] crlf.py script from Tools doesn't work with Python 3.2
In-Reply-To: <1312536541.59.0.919567642334.issue12694@psf.upfronthosting.co.za>
Message-ID: <1312544237.65.0.989013511815.issue12694@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> Tools/Scripts/crlf.py needs updating for python 3+

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

From report at bugs.python.org  Fri Aug  5 13:51:40 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 05 Aug 2011 11:51:40 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1312526592.71.0.637913394434.issue12540@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_WuCkVnn_coLvxqkXpTr1ybtYnvLbcf9OAbBM3dur6pg@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Fri, Aug 5, 2011 at 09:43, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at acm.org> added the comment:
>
> With Eli's concurrence, I have applied the updated patch to 3.2 (for 3.2.2)
> and to default (for 3.3).
>
> ----------
>

Tested this on Windows XP with Python 3.2 installed into "Program Files".
Works fine (including shell restart).

It would be great to get more people to test it though, especially people
who ran into the problem originally - Peter? Terry? Anish? Qiang Sun?

----------
Added file: http://bugs.python.org/file22837/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12540>
_______________________________________
-------------- next part --------------
<div dir="ltr"><div class="gmail_quote">On Fri, Aug 5, 2011 at 09:43, Ned Deily <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
Ned Deily &lt;<a href="mailto:nad at acm.org">nad at acm.org</a>&gt; added the comment:<br>
<br>
</div>With Eli&#39;s concurrence, I have applied the updated patch to 3.2 (for 3.2.2) and to default (for 3.3).<br>
<br>
----------<br></blockquote></div><br>Tested this on Windows XP with Python 3.2 installed into &quot;Program Files&quot;. Works fine (including shell restart).<br><br>It would be great to get more people to test it though, especially people who ran into the problem originally - Peter? Terry? Anish? Qiang Sun?<br>

<br><br><br></div>

From report at bugs.python.org  Fri Aug  5 14:23:09 2011
From: report at bugs.python.org (Tobias Klausmann)
Date: Fri, 05 Aug 2011 12:23:09 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1312546989.31.0.400375968786.issue10570@psf.upfronthosting.co.za>


Tobias Klausmann <klausman at gentoo.org> added the comment:

This bug is still not fixed and basically makes the curses module unusable except for very narrow use cases. Unfortunately, my C-fu is very weak, otherwise I'd try to make a patch.

----------
nosy: +klausman

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

From report at bugs.python.org  Fri Aug  5 15:39:40 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 13:39:40 +0000
Subject: [issue12696] pydoc error page due to lacking permissions on ./*
Message-ID: <1312551580.84.0.857436342215.issue12696@psf.upfronthosting.co.za>


New submission from Martin von Gagern <Martin.vGagern at gmx.net>:

I'd like to be able to run "pydoc -b" in whatever directory I'm currently in. Most of the time that would be the root of my home directory, which is an ext4fs mount. So it has a subdirectory called "lost+found" for which I don't have any access permissions. As a result, the main pydoc info page will simply print an error message:

OSError: [Errno 13] Permission denied: './lost+found'

I'm not sure how best to address this. There are several possibilities that come to my mind:

 1. Provide a command line switch to strip '.' from sys.path.
 2. Skip any sys.path elements which cause exceptions, possibly
    printing a warning in addition to the remaining page content.
 3. Skip any single subdirectry which causes an exception,
    as this more closely models what importing by name would do.
 4. Explicitely skip lost+found, or perhaps any directory name which
    would be invalid as a module name.

Obviously, the workaround is to change to a sufficiently empty directory before starting pydoc. So this is a minor issue, but annoying nevertheless.

----------
components: Library (Lib)
messages: 141658
nosy: gagern
priority: normal
severity: normal
status: open
title: pydoc error page due to lacking permissions on ./*
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Aug  5 16:05:14 2011
From: report at bugs.python.org (James Y Knight)
Date: Fri, 05 Aug 2011 14:05:14 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1312553114.83.0.523841091943.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

Oh wow, so it depends on the *build* time major version? That's really not useful at all for linux 2.x and 3.x; there is nothing useful anyone can possibly do with the distinction between platform == "linux2" and platform == "linux3". All it could possibly do is to break apps.

Given that:
a) old versions of Python won't even build without a patch and
b) changing platform to linux3 will break a lot of python apps that check sys.platform. 
c) It's completely useless to change it, as the change contains no actual information.

Why is forcing sys.platform to remain linux2 not the *obviously right thing to do*?

----------
nosy: +foom

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

From report at bugs.python.org  Fri Aug  5 17:20:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 15:20:15 +0000
Subject: [issue9338] argparse optionals with nargs='+' can't be followed by
	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1312557615.5.0.991471478936.issue9338@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is.  Someone wanting to help could reply to the question I asked :)

----------
type: feature request -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Fri Aug  5 17:28:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 15:28:27 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1312558107.88.0.964679690822.issue12641@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The necessity of walking on eggs with the distutils codebase restrains me.  I?ve read the thread on sourceforge (thanks Ruben) but don?t have enough information yet to decide whether to do a version check, call gcc -dumpspecs or remove the option altogether.

BTW, there?s no need to use re.search if you?re not using a regular expression: ?'no-cygwin' in output? will work.

----------

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

From report at bugs.python.org  Fri Aug  5 17:59:44 2011
From: report at bugs.python.org (Jon)
Date: Fri, 05 Aug 2011 15:59:44 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1312559984.67.0.216808416452.issue12641@psf.upfronthosting.co.za>


Jon <jon.forums at gmail.com> added the comment:

shortly after opening this issue i removed -mno-cygwin from my 2.7.2 install and have had no issues on win7 32bit. but i understand you're hesitation.

regardless what you decide, please consider placing a summary note in the source comments as a safety net.

if you'd like me to try building a limited set of extensions to help with your decision, let me know.  i have the following mingw toolchains on my win7 32bit system:

* tdm gcc 4.5.2 - http://tdm-gcc.tdragon.net/
* mingw-w64 prefix-stripped gcc 4.5.4 - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/
* Ruben's gcc 4.6.2 personal build - http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/4.6.2-1/

i'm not speaking for Ruben, but as he maintains https://github.com/rubenvb/MinGW-w64-build-scripts you might try cajoling him if you feel you need more test results ;)

re: re.search, understood, thanks...quick-testing.

----------

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

From report at bugs.python.org  Fri Aug  5 18:11:34 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 05 Aug 2011 16:11:34 +0000
Subject: [issue12697] timeiot documention still refers to the timeit.py script
Message-ID: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>


New submission from Alexis Metaireau <alexis at notmyidea.org>:

The example section of the timeit documentation still refers to "timeit.py", and isn't using the "python -m timeit" syntax used above.
http://docs.python.org/library/timeit.html#examples

I'm not sure when and if the timeit.py script has been removed from the python installation (and I'm not sure on where to look for this).

The timeit.py docstring also refers to this "old" syntax. Should we update it?

All credit for this report goes to Boris Feld.

----------
assignee: alexis
components: Library (Lib)
messages: 141663
nosy: alexis
priority: low
severity: normal
status: open
title: timeiot documention still refers to the timeit.py script
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/issue12697>
_______________________________________

From report at bugs.python.org  Fri Aug  5 18:11:53 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 05 Aug 2011 16:11:53 +0000
Subject: [issue12697] timeiot documention still refers to the timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <1312560713.14.0.530364119082.issue12697@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +Boris.FELD

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

From report at bugs.python.org  Fri Aug  5 18:12:15 2011
From: report at bugs.python.org (jimmi)
Date: Fri, 05 Aug 2011 16:12:15 +0000
Subject: [issue12698] urllib does not use no_proxy when it has blanks
Message-ID: <1312560735.85.0.0707078006924.issue12698@psf.upfronthosting.co.za>


New submission from jimmi <chris at computersalat.de>:

if you define your no_proxy var as mentioned in /etc/sysocnfig/proxy

# Example: NO_PROXY="www.me.de, do.main, localhost"

then python's urllib will never make use of it, cause there are blanks.
urllib does not remove blanks.

Reproducible: Always

Steps to Reproduce:
1.try it out

Actual Results:  
proxy will not be bypassed

Expected Results:  
proxy should be bypassed

you can also review this bug:
https://bugzilla.novell.com/show_bug.cgi?id=710736

----------
components: Library (Lib)
files: python-2.7-urllib-no_proxy.patch
keywords: patch
messages: 141664
nosy: jimmi.pip.verisignlabs.com.
priority: normal
severity: normal
status: open
title: urllib does not use no_proxy when it has blanks
versions: Python 2.7
Added file: http://bugs.python.org/file22838/python-2.7-urllib-no_proxy.patch

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

From report at bugs.python.org  Fri Aug  5 18:12:18 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 05 Aug 2011 16:12:18 +0000
Subject: [issue12697] timeit documention still refers to the timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <1312560738.79.0.103404238207.issue12697@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
title: timeiot documention still refers to the timeit.py script -> timeit documention still refers to the timeit.py script

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

From report at bugs.python.org  Fri Aug  5 18:25:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:25:02 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312561502.78.0.924196121166.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You should replace the v5 file (or even remove all files, for clarity) with the actual output of hg diff, not hg status ;-)

----------

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

From report at bugs.python.org  Fri Aug  5 18:26:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:26:59 +0000
Subject: [issue12662] Add support for duplicate options in configparser
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312561619.49.0.610191603499.issue12662@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Could you tell us more about the use cases?  Are you aware of some config files using this form?

----------
nosy: +eric.araujo
title: Allow configparser to process suplicate options -> Add support for duplicate options in configparser

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

From report at bugs.python.org  Fri Aug  5 18:28:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:28:23 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312561703.9.0.422656353598.issue12661@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It looks like this new function would just replace a loop using os.walk and fnmatch.  Is it really needed?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug  5 18:29:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:29:33 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312561773.92.0.40429463775.issue12666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(HTTPS repos are not supported)

----------
hgrepos: +51
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug  5 18:30:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:30:10 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312561810.64.0.11853642854.issue12666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you provide a public URI?

----------

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

From report at bugs.python.org  Fri Aug  5 18:33:45 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:33:45 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562025.09.0.407833908562.issue12666@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22839/bc362109eed8.diff

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

From report at bugs.python.org  Fri Aug  5 18:35:00 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:35:00 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562100.8.0.0554563004169.issue12666@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I don't know how that repo got to be private; I created it just like every other public repo I have, and I thought I was only allowed one private repo (this was my second). In any case, I updated the setting, and now it appears to be accessible via the bug tracker.

----------

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

From report at bugs.python.org  Fri Aug  5 18:39:04 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:39:04 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562344.42.0.745926304197.issue12666@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm not sure how the bugtracker patch mechanism works, but the patch it produced included a lot of changes that I didn't make (changesets already committed to the master repo).

----------
keywords:  -patch

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

From report at bugs.python.org  Fri Aug  5 19:33:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 17:33:34 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312565614.01.0.550293219384.issue12540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The replacement file, for anyone without a dev setup, is
http://hg.python.org/cpython/file/cc86f4ca5020/Lib/idlelib/PyShell.py

After renaming PyShell to PyShellBak and replacing with the above,
IDLE seems to run better than ever. On my XP system, the several second delay for the old process dying is gone and I never see 3 pythonw processes, even temporarily, as before. I can no longer tell from TaskManager that one process has been killed and another started. Testing included running tk windows. Will test later on new Win7 system.

Pending some unforeseen new problem, thank you Ned and Eli.

----------

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

From report at bugs.python.org  Fri Aug  5 19:58:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Aug 2011 17:58:34 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <1312567114.71.0.318834681271.issue12692@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the info, Nadeem.

----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Fri Aug  5 20:00:19 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Aug 2011 18:00:19 +0000
Subject: [issue12693] test.support.transient_internet prints to stderr when
	verbose is false
In-Reply-To: <1312544021.98.0.0103979481445.issue12693@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W745GGab=fd=4V1e=WBSDA8pirJ3BsKV+WoHmg9jGoeKA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Aug 5, 2011 at 04:33, R. David Murray <report at bugs.python.org>wrote:

It just seems odd to print when verbosity is  off, but not when it is on. I
don't have  the repo in front of me right now, but is there some other
mechanism which prints out similar info when verbosity is on?

> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12693>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22840/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12693>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Fri, Aug 5, 2011 at 04:33, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
I&#39;m pretty sure this was intentional. ??It is analogous to Skip messages and the messages issued when a resource hasn&#39;t been enabled, which also print when verbose is not true: the test wasn&#39;t run, and it lets you know why.<br>


<br></blockquote><div><br>It just seems odd to print when verbosity is?? off, but not when it is on. I don&#39;t have?? the repo in front of me right now, but is there some other mechanism which prints out similar info when verbosity is on?<br>

??</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
----------<br>
nosy: +r.david.murray<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue12693" target="_blank">http://bugs.python.org/issue12693</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Aug  5 20:14:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Aug 2011 18:14:21 +0000
Subject: [issue12693] test.support.transient_internet prints to stderr when
	verbose is false
In-Reply-To: <1312521271.03.0.978158187308.issue12693@psf.upfronthosting.co.za>
Message-ID: <1312568061.33.0.808654730858.issue12693@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see any such code in the 3.3 source for the context manager.  There the resource name is put in the ResourceDenied message.  I think we'll need the reproducer.

----------

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

From report at bugs.python.org  Fri Aug  5 20:27:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Aug 2011 18:27:53 +0000
Subject: [issue12694] crlf.py script from Tools doesn't work with Python 3.2
In-Reply-To: <1312536541.59.0.919567642334.issue12694@psf.upfronthosting.co.za>
Message-ID: <1312568873.38.0.882009682344.issue12694@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Fri Aug  5 21:00:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Aug 2011 19:00:18 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312570818.53.0.206161247942.issue12666@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  5 21:05:46 2011
From: report at bugs.python.org (ojab)
Date: Fri, 05 Aug 2011 19:05:46 +0000
Subject: [issue12662] Add support for duplicate options in configparser
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312571146.9.0.0911602337615.issue12662@psf.upfronthosting.co.za>


ojab <ojab at ojab.ru> added the comment:

There is some [leagcy] proprietary soft-switches, which uses this config format.
Personally I use [hacked] configparser to process Mera systems MVTS/SIP-HIT configs in this format, for example.

----------

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

From report at bugs.python.org  Fri Aug  5 21:11:30 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Aug 2011 19:11:30 +0000
Subject: [issue12662] Add support for duplicate options in configparser
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312571490.73.0.398105379017.issue12662@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This would break existing config files, including some of my own. 

It would also require that you have some end delimiter on every item in order to handle the event that someone duplicates options, otherwise the following would likely behave badly in your application

[sect]
opt=first
opt=second

This would give you "firstsecond" that you'd somehow need to parse. Sometimes if I'm testing out options, like I want to check how "second" works, I'll quickly just do it as above. With a change like this, I couldn't do that, I'd be forced to comment out the first line, or add a delimiter and split on it.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Aug  5 21:33:13 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 05 Aug 2011 19:33:13 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312572793.96.0.15388444848.issue12691@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Fri Aug  5 21:33:28 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 05 Aug 2011 19:33:28 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312572808.17.0.173045743077.issue12675@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Fri Aug  5 21:40:05 2011
From: report at bugs.python.org (ojab)
Date: Fri, 05 Aug 2011 19:40:05 +0000
Subject: [issue12662] Add support for duplicate options in configparser
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312573205.84.0.880739174756.issue12662@psf.upfronthosting.co.za>


ojab <ojab at ojab.ru> added the comment:

It may be impelmented as configparser.ConfigParser(strict=yes|no|multiline), so no existing configs will be broken.

----------

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

From report at bugs.python.org  Fri Aug  5 21:44:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 19:44:04 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312573444.73.0.928665044643.issue12666@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/issue12666>
_______________________________________

From report at bugs.python.org  Fri Aug  5 21:51:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Aug 2011 19:51:29 +0000
Subject: [issue12697] timeit documention still refers to the timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <1312573889.84.0.849882429432.issue12697@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Sounds good to me.

I would also replace the % with $ in the first example and use triple-quoted docstrings and spaces around the == in the last.

----------
keywords: +easy
nosy: +ezio.melotti, sandro.tosi
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Fri Aug  5 21:53:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 19:53:34 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312574014.54.0.075482283313.issue12675@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have not used tokenize, but if it is *not* intended to exactly reproduce the internal tokenizer  behavior, the claim that it is should be amended.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Aug  5 22:00:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 20:00:46 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312574446.4.0.119173467739.issue12682@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Adding a feature 'fixes' the deficiency of its absence. I personally have no use for 'accepted' and find it ambiguous. My best understanding is what David has seen (accepted in principle).

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Aug  5 22:10:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 20:10:55 +0000
Subject: [issue12690] Tix bug 2643483
In-Reply-To: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>
Message-ID: <1312575055.43.0.827549826508.issue12690@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Gary, did you mean that there is a fix in the Tix bug report?
(the addition of '-'?)
If so, what has it not been applied to the Tix repository?
Is it still active?
Once changed there, the change should be propagated to the Python distribution.

----------
nosy: +terry.reedy
status: pending -> open

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

From report at bugs.python.org  Fri Aug  5 22:23:11 2011
From: report at bugs.python.org (Feth AREZKI)
Date: Fri, 05 Aug 2011 20:23:11 +0000
Subject: [issue12699] strange behaviour of locale.getlocale() -> None, None
Message-ID: <1312575791.54.0.599260921956.issue12699@psf.upfronthosting.co.za>


New submission from Feth AREZKI <feth at tuttu.info>:

Tested on linux arch & debian, freeBSD and MacOSX :

% python2.7
[...]
>>> import locale
>>> locale.getlocale()
(None, None)
>>> locale.getlocale(locale.LC_CTYPE) ?#or any type
(None, None)

% python3.2
[...]
>>> import locale
>>> locale.getlocale()
('fr_FR', 'UTF-8')

We feel this is strange!

----------
messages: 141683
nosy: alexis, feth
priority: normal
severity: normal
status: open
title: strange behaviour of locale.getlocale() -> None, None
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  5 22:26:21 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 20:26:21 +0000
Subject: [issue12696] pydoc error page due to lacking permissions on ./*
In-Reply-To: <1312551580.84.0.857436342215.issue12696@psf.upfronthosting.co.za>
Message-ID: <1312575981.28.0.567048873737.issue12696@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Do any of you three have anything to do with pydoc?

Given that the manual simply says "pydoc -b will start the server and additionally open a web browser to a module index page." without qualifications, quitting when started from certain locations strikes me as a bug.  I do not see a reason to not just continue.

----------
nosy: +eric.araujo, ezio.melotti, georg.brandl, terry.reedy
stage:  -> test needed
type: feature request -> behavior
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Aug  5 22:34:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 20:34:47 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312576487.97.0.411604578208.issue12191@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22841/shutil_chown-default-v5.patch

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

From report at bugs.python.org  Fri Aug  5 22:35:10 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 20:35:10 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312576510.6.0.98318247408.issue12191@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Removed file: http://bugs.python.org/file22675/shutil_chown-default-v5.patch

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

From report at bugs.python.org  Fri Aug  5 22:35:37 2011
From: report at bugs.python.org (Gary Levin)
Date: Fri, 05 Aug 2011 20:35:37 +0000
Subject: [issue12690] Tix bug 2643483
In-Reply-To: <1312425211.65.0.926094356075.issue12690@psf.upfronthosting.co.za>
Message-ID: <1312576537.6.0.268858738418.issue12690@psf.upfronthosting.co.za>


Gary Levin <gary.marc.levin at gmail.com> added the comment:

Terry, I am just a new casual user.

The fix described in the Tix report (adding the '-') fixed the problem for me.  But the report (2009-02-26) is after the most recent Tix build (8.4.3	2008-03-17).  I don't know if it was ever added to the repository.   

Is Tix still being supported?  No, the last CVS change was FileEnt.tcl revision 1.7 by hobbs, Sun Mar 28 02:44:57 2004.  Looks pretty dead to me.

If not, a good reason for me to skip Tix and use tkinter and ttk.  There have been recent commits (last commit on 2011-06-30).

----------

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

From report at bugs.python.org  Fri Aug  5 22:36:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 20:36:29 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312576589.12.0.557676596499.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Gaaah, sorry about that: I've just uploaded the correct fifth version.

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

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

From report at bugs.python.org  Fri Aug  5 22:42:41 2011
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 05 Aug 2011 20:42:41 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312576961.91.0.0166865994894.issue12691@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

I think I can make these changes independently and issue two patches, one fixing the problems with untokenize listed here, and another improving tokenize.

I've just noticed a third bug in untokenize: in full mode, it doesn't handle backslash-continued lines correctly.

    Python 3.3.0a0 (default:c099ba0a278e, Aug  2 2011, 12:35:03) 
    [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from io import BytesIO
    >>> from tokenize import tokenize, untokenize
    >>> untokenize(tokenize(BytesIO('1 and \\\n not 2'.encode('utf8')).readline))
    b'1 andnot 2'

----------

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

From report at bugs.python.org  Fri Aug  5 22:46:46 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 05 Aug 2011 20:46:46 +0000
Subject: [issue12662] Add support for duplicate options in configparser
In-Reply-To: <1312117752.5.0.933932400203.issue12662@psf.upfronthosting.co.za>
Message-ID: <1312577206.28.0.0388027362468.issue12662@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This specific config format you're discussing strikes me as error prone and barely useful. With the use case you've given I cannot justify introducing support for it in the standard library. Remember that each switch, variant, however obscure and rarely used, increases source code complexity and introduces a maintenance burden.

As you've seen with the freshly introduced `strict` option, we're generally heading the other direction: to let application users know early they potentially made a misconfiguration that could confuse them later on.

So, thanks for your feedback but unfortunately I will have to say no to that proposal.

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

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

From report at bugs.python.org  Fri Aug  5 23:06:21 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Aug 2011 21:06:21 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <E1QpRb2-0005rm-3F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 74e79b2c114a by Sandro Tosi in branch 'default':
#11572: improvements to copy module tests along with removal of old test suite
http://hg.python.org/cpython/rev/74e79b2c114a

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

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

From report at bugs.python.org  Fri Aug  5 23:11:51 2011
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 05 Aug 2011 21:11:51 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312578711.21.0.396413594125.issue12675@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Terry: agreed. Does anyone actually use this module? Does anyone know what the design goals are for tokenize? If someone can tell me, I'll do my best to make it meet them.

Meanwhile, here's another bug. Each character of trailing whitespace is tokenized as an ERRORTOKEN.

    Python 3.3.0a0 (default:c099ba0a278e, Aug  2 2011, 12:35:03) 
    [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from tokenize import tokenize,untokenize
    >>> from io import BytesIO
    >>> list(tokenize(BytesIO('1 '.encode('utf8')).readline))
    [TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=2 (NUMBER), string='1', start=(1, 0), end=(1, 1), line='1 '), TokenInfo(type=54 (ERRORTOKEN), string=' ', start=(1, 1), end=(1, 2), line='1 '), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]

----------

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

From report at bugs.python.org  Fri Aug  5 23:20:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Aug 2011 21:20:57 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1312579257.82.0.139556492831.issue10570@psf.upfronthosting.co.za>


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


----------
nosy: +haypo

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

From report at bugs.python.org  Fri Aug  5 23:23:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 21:23:11 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312579391.6.0.406960725331.issue11572@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Brandon, thanks for your work on this patch! I've just committed the unittests update+removal of _test() part.

For the remaining part, I see that Nick and you worked on it during a sprint, so I'm quite sure it's fine, but nonetheless it would be awesome if you can fill in the missing bits.

re coverage: I saw the other issue, but I didn't connect the dots, thanks for doing it for me :)

----------
assignee:  -> sandro.tosi

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

From report at bugs.python.org  Fri Aug  5 23:25:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 21:25:12 +0000
Subject: [issue12675] tokenize module happily tokenizes code with syntax errors
In-Reply-To: <1312203519.76.0.918580877349.issue12675@psf.upfronthosting.co.za>
Message-ID: <1312579512.45.0.453584469001.issue12675@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Fri Aug  5 23:28:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Aug 2011 21:28:03 +0000
Subject: [issue12698] urllib does not use no_proxy when it has blanks
In-Reply-To: <1312560735.85.0.0707078006924.issue12698@psf.upfronthosting.co.za>
Message-ID: <1312579683.41.0.49073909737.issue12698@psf.upfronthosting.co.za>


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


----------
nosy: +orsenthil

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

From report at bugs.python.org  Fri Aug  5 23:34:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Aug 2011 21:34:37 +0000
Subject: [issue12699] strange behaviour of locale.getlocale() -> None, None
In-Reply-To: <1312575791.54.0.599260921956.issue12699@psf.upfronthosting.co.za>
Message-ID: <1312580077.19.0.656841297077.issue12699@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior

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

From report at bugs.python.org  Fri Aug  5 23:44:02 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 21:44:02 +0000
Subject: [issue12696] pydoc error page due to lacking permissions on ./*
In-Reply-To: <1312551580.84.0.857436342215.issue12696@psf.upfronthosting.co.za>
Message-ID: <1312580642.73.0.700214993805.issue12696@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

The server continues all right. It's the browser window which displays the error message. Not much better in my opinion, though.

To be completely accurate: currently the -b option doens't work as it should due to issue #11432. But using "-p 0" and opening the link manually is a suitable workaround for now.

----------

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

From report at bugs.python.org  Sat Aug  6 01:03:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 23:03:29 +0000
Subject: [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1312585409.06.0.166279271437.issue11047@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello, the patch seems indeed to fix a "reverse" description of issue 7902. Was there a reason (given the quite long list of nosy people) why it was not applied? "lack of time" doesn't count :)

----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> commit review
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug  6 01:04:05 2011
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 05 Aug 2011 23:04:05 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312585445.43.0.968598121256.issue12691@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Please find attached a patch containing four bug fixes for untokenize():

* untokenize() now always returns a bytes object, defaulting to UTF-8 if no ENCODING token is found (previously it returned a string in this case).
* In compatibility mode, untokenize() successfully processes all tokens from an iterator (previously it discarded the first token).
* In full mode, untokenize() now returns successfully (previously it asserted).
* In full mode, untokenize() successfully processes tokens that were separated by a backslashed newline in the original source (previously it ran these tokens together).

In addition, I've added some unit tests:

* Test case for backslashed newline.
* Test case for missing ENCODING token.
* roundtrip() tests both modes of untokenize() (previously it just tested compatibility mode).

and updated the documentation:

* Update the docstring for untokenize to better describe its actual behaviour, and remove the false claim "Untokenized source will match input source exactly". (We can restore this claim if we ever fix tokenize/untokenize so that it's true.)
* Update the documentation for untokenize in tokenize.rdt to match the docstring.

I welcome review: this is my first proper patch to Python.

----------
keywords: +patch
Added file: http://bugs.python.org/file22842/Issue12691.patch

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

From report at bugs.python.org  Sat Aug  6 01:18:34 2011
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 05 Aug 2011 23:18:34 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
Message-ID: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>


New submission from Gareth Rees <gdr at garethrees.org>:

On Mac OS 10.7, test_faulthandler fails. See test output below.

It looks as though the tests may be at fault in expecting to see "(?:Segmentation fault|Bus error)" instead of "(?:Segmentation fault|Bus error|Illegal instruction)".

    test_disable (__main__.FaultHandlerTests) ... ok
    test_dump_traceback (__main__.FaultHandlerTests) ... ok
    test_dump_traceback_file (__main__.FaultHandlerTests) ... ok
    test_dump_traceback_threads (__main__.FaultHandlerTests) ... ok
    test_dump_traceback_threads_file (__main__.FaultHandlerTests) ... ok
    test_dump_tracebacks_later (__main__.FaultHandlerTests) ... ok
    test_dump_tracebacks_later_cancel (__main__.FaultHandlerTests) ... ok
    test_dump_tracebacks_later_file (__main__.FaultHandlerTests) ... ok
    test_dump_tracebacks_later_repeat (__main__.FaultHandlerTests) ... ok
    test_dump_tracebacks_later_twice (__main__.FaultHandlerTests) ... ok
    test_enable_file (__main__.FaultHandlerTests) ... FAIL
    test_enable_single_thread (__main__.FaultHandlerTests) ... FAIL
    test_fatal_error (__main__.FaultHandlerTests) ... ok
    test_gil_released (__main__.FaultHandlerTests) ... FAIL
    test_is_enabled (__main__.FaultHandlerTests) ... ok
    test_read_null (__main__.FaultHandlerTests) ... FAIL
    test_register (__main__.FaultHandlerTests) ... ok
    test_register_chain (__main__.FaultHandlerTests) ... ok
    test_register_file (__main__.FaultHandlerTests) ... ok
    test_register_threads (__main__.FaultHandlerTests) ... ok
    test_sigabrt (__main__.FaultHandlerTests) ... ok
    test_sigbus (__main__.FaultHandlerTests) ... ok
    test_sigfpe (__main__.FaultHandlerTests) ... ok
    test_sigill (__main__.FaultHandlerTests) ... ok
    test_sigsegv (__main__.FaultHandlerTests) ... ok
    test_stack_overflow (__main__.FaultHandlerTests) ... ok
    test_unregister (__main__.FaultHandlerTests) ... ok

    ======================================================================
    FAIL: test_enable_file (__main__.FaultHandlerTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "test_faulthandler.py", line 207, in test_enable_file
        filename=filename)
      File "test_faulthandler.py", line 105, in check_fatal_error
        self.assertRegex(output, regex)
    AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 4 in <module>$' not found in 'Fatal Python error: Illegal instruction\n\nCurrent thread XXX:\n  File "<string>", line 4 in <module>'

    ======================================================================
    FAIL: test_enable_single_thread (__main__.FaultHandlerTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "test_faulthandler.py", line 217, in test_enable_single_thread
        all_threads=False)
      File "test_faulthandler.py", line 105, in check_fatal_error
        self.assertRegex(output, regex)
    AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nTraceback\\ \\(most\\ recent\\ call\\ first\\):\n  File "<string>", line 3 in <module>$' not found in 'Fatal Python error: Illegal instruction\n\nTraceback (most recent call first):\n  File "<string>", line 3 in <module>'

    ======================================================================
    FAIL: test_gil_released (__main__.FaultHandlerTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "test_faulthandler.py", line 195, in test_gil_released
        '(?:Segmentation fault|Bus error)')
      File "test_faulthandler.py", line 105, in check_fatal_error
        self.assertRegex(output, regex)
    AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$' not found in 'Fatal Python error: Illegal instruction\n\nCurrent thread XXX:\n  File "<string>", line 3 in <module>'

    ======================================================================
    FAIL: test_read_null (__main__.FaultHandlerTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "test_faulthandler.py", line 115, in test_read_null
        '(?:Segmentation fault|Bus error)')
      File "test_faulthandler.py", line 105, in check_fatal_error
        self.assertRegex(output, regex)
    AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$' not found in 'Fatal Python error: Illegal instruction\n\nCurrent thread XXX:\n  File "<string>", line 3 in <module>'

    ----------------------------------------------------------------------
    Ran 27 tests in 21.711s

    FAILED (failures=4)
    Traceback (most recent call last):
      File "test_faulthandler.py", line 550, in <module>
        test_main()
      File "test_faulthandler.py", line 547, in test_main
        support.run_unittest(FaultHandlerTests)
      File "/Users/gdr/hg.python.org/cpython/Lib/test/support.py", line 1327, in run_unittest
        _run_suite(suite)
      File "/Users/gdr/hg.python.org/cpython/Lib/test/support.py", line 1302, in _run_suite
        raise TestFailed(err)
    test.support.TestFailed: multiple errors occurred

----------
components: Tests
messages: 141695
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: test_faulthandler fails on Mac OS X Lion
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug  6 01:40:13 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 23:40:13 +0000
Subject: [issue12256] Link isinstance/issubclass doc to abc module
In-Reply-To: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>
Message-ID: <1312587613.87.0.253344664816.issue12256@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I think the patch is fine to apply.

----------
nosy: +ezio.melotti, sandro.tosi
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Aug  6 01:59:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 23:59:31 +0000
Subject: [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <1312588771.23.0.0481319298586.issue11481@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

A quick reword could be the one attached.

----------
keywords: +patch
nosy: +ezio.melotti, sandro.tosi
stage:  -> patch review
versions: +Python 2.7 -Python 3.1
Added file: http://bugs.python.org/file22843/issue11481.patch

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

From report at bugs.python.org  Sat Aug  6 02:17:56 2011
From: report at bugs.python.org (Gareth Rees)
Date: Sat, 06 Aug 2011 00:17:56 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1312589876.7.0.324222495693.issue12691@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

Thanks Ezio for the review. I've made all the changes you requested, (except for the re-ordering of paragraphs in the documentation, which I don't want to do because that would lead to the "round-trip property" being mentioned before it's defined). Revised patch attached.

----------
Added file: http://bugs.python.org/file22844/Issue12691.patch

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

From report at bugs.python.org  Sat Aug  6 02:42:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Aug 2011 00:42:59 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312591379.92.0.164134166761.issue12191@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I wonder if we should raise LookupError for unknown uids/gids. Do we have other APIs with similar semantics?

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

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

From report at bugs.python.org  Sat Aug  6 03:37:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Aug 2011 01:37:18 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312594638.91.0.571331014299.issue12661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I also think it sounds too specialized.

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

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

From report at bugs.python.org  Sat Aug  6 04:46:59 2011
From: report at bugs.python.org (deadshort)
Date: Sat, 06 Aug 2011 02:46:59 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
Message-ID: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>


New submission from deadshort <cploomis at gmail.com>:

Apple Radar ticket 9908625 has been filed. The clang 2.1 optimizer causes overflows in Object/intobject.c:int_pow() to be missed, so 2**63 turns into a negative integer. The attached test program narrows it down. llvm-gcc is fine, so this ticket is mostly an FYI.

idiotbox:Python-2.7.2 cloomis$ ./seqpoint-OK 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=-611686018
overflow detected: 1

  to turn into:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4294967296 4200000000
a=4294967296, b=4200000000, c(a*b)=-407881430509551616, c/b=4294967296
overflow detected: 0

----------
components: Interpreter Core
files: seqpoint.c
messages: 141701
nosy: deadshort
priority: normal
severity: normal
status: open
title: Apple's clang 2.1 (xcode 4.1, OSX 10.7) optimizer miscompiles intobject.c
versions: Python 2.7
Added file: http://bugs.python.org/file22845/seqpoint.c

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

From report at bugs.python.org  Sat Aug  6 04:48:45 2011
From: report at bugs.python.org (deadshort)
Date: Sat, 06 Aug 2011 02:48:45 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1312598925.24.0.500435824141.issue12701@psf.upfronthosting.co.za>


deadshort <cploomis at gmail.com> added the comment:

Blecch: cut-o.
The bad case should have been the matching:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=4000000000
overflow detected: 0

----------

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

From report at bugs.python.org  Sat Aug  6 04:52:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 02:52:36 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1312599156.7.0.116805937683.issue12701@psf.upfronthosting.co.za>


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


----------
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sat Aug  6 04:59:18 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 02:59:18 +0000
Subject: [issue12696] pydoc error page due to lacking permissions on ./*
In-Reply-To: <1312551580.84.0.857436342215.issue12696@psf.upfronthosting.co.za>
Message-ID: <1312599558.6.0.279109562668.issue12696@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is essentially a duplicate of Issue11914.  The root cause is that pkgutil.iter_modules doesn't deal with permission errors when traversing paths.  Issue7367 is also related.

----------
assignee:  -> ned.deily
nosy: +ned.deily

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

From report at bugs.python.org  Sat Aug  6 04:59:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 02:59:32 +0000
Subject: [issue11914] pydoc modules/help('modules') crash in dirs with
	unreadable subdirs
In-Reply-To: <1303616093.87.0.65824226669.issue11914@psf.upfronthosting.co.za>
Message-ID: <1312599572.06.0.978471742198.issue11914@psf.upfronthosting.co.za>


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


----------
assignee:  -> ned.deily
nosy: +ned.deily
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Aug  6 04:59:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 02:59:46 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1312599586.46.0.53592173716.issue7367@psf.upfronthosting.co.za>


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


----------
assignee:  -> ned.deily

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

From report at bugs.python.org  Sat Aug  6 05:00:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 03:00:20 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1312599620.0.0.202957475152.issue7367@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Aug  6 05:26:03 2011
From: report at bugs.python.org (Andrew Wilkins)
Date: Sat, 06 Aug 2011 03:26:03 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312601163.75.0.185160356006.issue12687@psf.upfronthosting.co.za>


Andrew Wilkins <axwalk at gmail.com> added the comment:

In _pickle.c, the load_put function calls _Unpickler_Readline, which may prefetch data and place it after the line read in with "readline". load_put then calls PyLong_FromString, which doesn't like the trailing data after the '\n'.

Maybe just use PyOS_strtol instead? Alternatively, replace the newline with a null byte.

----------
nosy: +axwalk

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

From report at bugs.python.org  Sat Aug  6 06:28:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Aug 2011 04:28:53 +0000
Subject: [issue12698] urllib does not use no_proxy when it has blanks
In-Reply-To: <1312560735.85.0.0707078006924.issue12698@psf.upfronthosting.co.za>
Message-ID: <E1QpYVH-0000pG-My@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c5a35bcfa3ee by Senthil Kumaran in branch '2.7':
Fix closes issue12698 - make the no_proxy environment variable handling a bit lenient (accomodate spaces in between the items)
http://hg.python.org/cpython/rev/c5a35bcfa3ee

New changeset 1d4bd059a9b6 by Senthil Kumaran in branch '3.2':
Fix closes issue12698 - make the no_proxy environment variable handling a bit lenient (accomodate spaces in between the items)
http://hg.python.org/cpython/rev/1d4bd059a9b6

New changeset 47573019bfc8 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue12698 - make the no_proxy environment variable handling a bit lenient (accomodate spaces in between the items)
http://hg.python.org/cpython/rev/47573019bfc8

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

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

From report at bugs.python.org  Sat Aug  6 06:56:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Aug 2011 04:56:40 +0000
Subject: [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <E1QpYw5-0003L6-Hj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 298df0970eec by Senthil Kumaran in branch '2.7':
Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/298df0970eec

New changeset dafdbd0d570a by Senthil Kumaran in branch '3.2':
merge from 2.7 - Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/dafdbd0d570a

New changeset aea6f588230b by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/aea6f588230b

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

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

From report at bugs.python.org  Sat Aug  6 06:57:28 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Aug 2011 04:57:28 +0000
Subject: [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1312585409.06.0.166279271437.issue11047@psf.upfronthosting.co.za>
Message-ID: <20110806045720.GB2530@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sandro, perhaps got overlooked. :) But yeah, why wait. Done.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sat Aug  6 07:19:18 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Aug 2011 05:19:18 +0000
Subject: [issue12653] Provide accelerators for all buttons in Windows
	installers
In-Reply-To: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>
Message-ID: <1312607958.6.0.847063608708.issue12653@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +markm

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

From report at bugs.python.org  Sat Aug  6 07:20:32 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sat, 06 Aug 2011 05:20:32 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312608032.29.0.482079739389.issue12646@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I have another proposition (as an alternative). The new _bz2.BZ2Decompressor objects have an attribute called eof which is False until the end of the stream is read. The same attribute could be added to zlib.Decompress objects.

----------

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

From report at bugs.python.org  Sat Aug  6 07:37:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Aug 2011 05:37:56 +0000
Subject: [issue12697] timeit documention still refers to the timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <E1QpZa7-0006Km-GL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fa1e5fe55664 by Senthil Kumaran in branch '2.7':
Fix closes Issue12697 - Update the usage syntax of timeit module in the docs.
http://hg.python.org/cpython/rev/fa1e5fe55664

New changeset 87de58db3d40 by Senthil Kumaran in branch '3.2':
Fix closes Issue12697 - Update the usage syntax of timeit module in the docs.
http://hg.python.org/cpython/rev/87de58db3d40

New changeset 46b801545126 by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes Issue12697 - Update the usage syntax of timeit module in the docs.
http://hg.python.org/cpython/rev/46b801545126

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

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

From report at bugs.python.org  Sat Aug  6 07:38:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Aug 2011 05:38:34 +0000
Subject: [issue12697] timeit documention still refers to the timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <1312609114.14.0.108693056245.issue12697@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the report, Boris Feld and Alexis.

----------
assignee: alexis -> docs at python
nosy: +docs at python, orsenthil

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

From report at bugs.python.org  Sat Aug  6 08:30:37 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 06 Aug 2011 06:30:37 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312574446.4.0.119173467739.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110806063035.GA2833@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

Terry J. Reedy wrote:
> Adding a feature 'fixes' the deficiency of its absence. I personally
> have no use for 'accepted' and find it ambiguous. My best
> understanding is what David has seen (accepted in principle).

Ditto.

Having separate resolutions for bugs and features makes it harder to
find all issues that have been closed as "bug fixed or feature
accepted", because you cannot select multiple resolutions when
searching.

With one resolution, you can simply search for "fixed" issues. If you
only want to find feature requests that were accepted, search for
type=feature and resolution=fixed.

----------

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

From report at bugs.python.org  Sat Aug  6 08:42:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 06 Aug 2011 06:42:48 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
Message-ID: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

As discussed in issue 12183, shutil.copytree(..., symlinks=True) should copy the metadata of symlinks instead of the metadata of the file that the symlink refers to.

This can be achieved by using os.lstat() and os.lutimes() (new in 3.3) on symlinks.

----------
components: Library (Lib)
keywords: easy
messages: 141712
nosy: orsenthil, petri.lehtinen
priority: normal
severity: normal
status: open
title: shutil.copytree() should use os.lutimes() to copy the metadata of symlinks
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug  6 11:24:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 06 Aug 2011 09:24:50 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312622690.91.0.992715449523.issue12646@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I have another proposition (as an alternative). The new _bz2.BZ2Decompressor
> objects have an attribute called eof which is False until the end of the
> stream is read. The same attribute could be added to zlib.Decompress objects.

+1, I like the idea of being consistent across related modules.
I'll put together a patch.

----------

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

From report at bugs.python.org  Sat Aug  6 12:24:38 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 06 Aug 2011 10:24:38 +0000
Subject: [issue11572] bring Lib/copy.py to 100% coverage
In-Reply-To: <1300293152.7.0.733550751317.issue11572@psf.upfronthosting.co.za>
Message-ID: <1312626278.47.0.313083426557.issue11572@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

JFTR, the same kind of check of __reduce_ex__ and then falling back on __reduce__ is prenset in pickle too: maybe it's worth align them?

----------

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

From report at bugs.python.org  Sat Aug  6 12:35:35 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Sat, 06 Aug 2011 10:35:35 +0000
Subject: [issue12703] Loading a module
Message-ID: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>


New submission from R?my HUBSCHER <remy.hubscher at ionyse.com>:

I patched it for redbarrel but there is the same bug on distutils2.

This patch allow to see the error raised when loading the module instead of saying that the module does not exists.

https://bitbucket.org/tarek/redbarrel/changeset/2cf6d7e32081#chg-redbarrel/util.py

----------
assignee: tarek
components: Distutils2
messages: 141715
nosy: Natim, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Loading a module

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

From report at bugs.python.org  Sat Aug  6 14:48:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Aug 2011 12:48:25 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312634905.1.0.487832194635.issue12682@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW that would be fine with me.  Even if there's nothing broken in a feature request, "fixed" applied to feature could mean "the lack of this feature has been fixed".
If the issue is valid, one can say so in a message without marking it as 'accepted'.

----------

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

From report at bugs.python.org  Sat Aug  6 16:41:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Aug 2011 14:41:05 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1312641665.83.0.408408998583.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Would you have time to make a code+test patch for the CPython repo?  distutils2 has moved there under the name packaging.

----------
assignee: tarek -> eric.araujo
stage:  -> needs patch
title: Loading a module -> Improve error reporting for packaging.util.resolve_name
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Sat Aug  6 16:53:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Aug 2011 14:53:26 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312642406.38.0.803637214788.issue12666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have reported the bugs to the metatracker.  In the meantime, could you manually upload a diff?

----------

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

From report at bugs.python.org  Sat Aug  6 17:20:53 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 06 Aug 2011 15:20:53 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312644053.27.0.19547891809.issue12646@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's the patch.

----------
Added file: http://bugs.python.org/file22846/zlib-eof

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

From report at bugs.python.org  Sat Aug  6 17:22:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 06 Aug 2011 15:22:30 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312644150.47.0.114591842018.issue12646@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Added file: http://bugs.python.org/file22847/zlib-eof.patch

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

From report at bugs.python.org  Sat Aug  6 17:22:40 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 06 Aug 2011 15:22:40 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312644160.83.0.756444637725.issue12646@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Removed file: http://bugs.python.org/file22846/zlib-eof

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

From report at bugs.python.org  Sat Aug  6 18:18:30 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Aug 2011 16:18:30 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312647510.88.0.632873595887.issue12666@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm attaching the diff at https://bitbucket.org/jaraco/cpython-issue12666/changeset/bc362109eed8

----------
keywords: +patch
Added file: http://bugs.python.org/file22848/cpython-issue12666-bc362109eed8.diff

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

From report at bugs.python.org  Sat Aug  6 18:47:37 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Sat, 06 Aug 2011 16:47:37 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312649257.7.0.954333117157.issue12301@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

I would like to help out with this, as there seems to be a lot of work that needs to be done.

I guess I'm a little unsure about what you mean by ``code`` instead of :data:. Is ``code`` generic? Like in Doc/tutorials/classes.rst I see a lot of things similar to ``eval()``. Are you saying that dhould be changed to :data:eval()?

----------
nosy: +louiscipher

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

From report at bugs.python.org  Sat Aug  6 19:00:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Aug 2011 17:00:57 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312650057.83.0.729030040288.issue12301@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Nope, ``...`` can be used for generic pieces of code, whereas e.g. :data:`sys.stdout` indicates that stdout is a "data" attribute of the sys module.
If you use :data:`...` and rebuild the doc (cd Doc/; make html), you will see that e.g. sys.stdout will be then a link to the sys.html page.

----------

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

From report at bugs.python.org  Sat Aug  6 19:14:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 06 Aug 2011 17:14:12 +0000
Subject: [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <1312650852.14.0.973832445388.issue11481@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After quite a long chat with Ezio, I'm just proposing this updated patch:

- it fixes the copy doc, explicitly acknowledging the use of copyreg functionalities
- it rewords the first paragraph of copyreg doc, which was a bit too pickle-centric
- it adds an example to copyreg, to give an initial clue of how it works.

I'd like to hear comments/suggestions about it.

----------
nosy: +fdrake, rhettinger
Added file: http://bugs.python.org/file22849/issue11481-v2.patch

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

From report at bugs.python.org  Sat Aug  6 20:12:27 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 06 Aug 2011 18:12:27 +0000
Subject: [issue12704] Language References does not specify exception raised by
	final yield()
Message-ID: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

>From http://docs.python.org/reference/simple_stmts.html#the-yield-statement:

"As of Python version 2.5, the yield statement is now allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator?s close() method will be called, allowing any pending finally clauses to execute."

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.

----------
assignee: docs at python
components: Documentation
messages: 141724
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Language References does not specify exception raised by final yield()
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Aug  6 20:16:40 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Sat, 06 Aug 2011 18:16:40 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312654600.29.0.201898274443.issue12301@psf.upfronthosting.co.za>


Bryce Verdier <bryceverdier at gmail.com> added the comment:

Is this more what was in mind for the bug?

----------
Added file: http://bugs.python.org/file22850/issue12301.test_patch

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

From report at bugs.python.org  Sat Aug  6 20:29:10 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 06 Aug 2011 18:29:10 +0000
Subject: [issue12704] Language References does not specify exception raised by
	final yield()
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1312655350.4.0.122132904025.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

>From http://www.python.org/dev/peps/pep-0342/ I believe that the last yield will raise GeneratorExit. So my suggestion is to replace the above mentioned paragraph with:

"""
As of Python version 2.5, yield is an expression rather than a statement and allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator?s close() method will be called, and the yield expression in the generator function will raise GeneratorExit. 

If the generator function raises GeneratorExit (either directly or by not catching it), future calls to the next() method of the generator iterator will raise StopIteration. GeneratorExit exceptions raised by the generator function are catched internally and do not result in a call to sys.excepthook.
"""

----------

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

From report at bugs.python.org  Sat Aug  6 21:18:53 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 06 Aug 2011 19:18:53 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1312658333.08.0.547692424572.issue12611@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch that adds a test case reproducing the issue. Hopely someone with more experience with lib2to3 can do the actual fixing...

----------
keywords: +patch
type:  -> behavior
Added file: http://bugs.python.org/file22851/issue12611_test.patch

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

From report at bugs.python.org  Sat Aug  6 23:00:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Aug 2011 21:00:20 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312664420.81.0.488994715855.issue12301@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume so. I believe ``x`` is meant for general code like ``for thing in group: print(thing)``. While ?ric specifically mentioned the :data: role, I presume the same idea applies to :func: and possibly other link-generating roles.

Is there a statement role, so that "effect of the ``global`` statement, " could be changed to link to the global statement doc?

This seems like a great project for a beginning developer to contribute patches.

Georg, do you have any reason to not have markup become more specific?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Aug  7 00:13:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 06 Aug 2011 22:13:57 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1312668837.51.0.365569082295.issue12702@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Keep in mind that os.lutimes() may not be available on the platform so the patch will need to test for that.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sun Aug  7 00:32:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Aug 2011 22:32:12 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312669932.93.0.967770212171.issue12301@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

For global there's :keyword:.  Also note that :data: should be used for module-level variables (or constant) not for attributes of e.g. classes and instances.

If there are other ``...`` that can be fixed (even using something else like e.g. :func: or :meth:), they should be fixed as well, but apparently ``...`` was often misused instead of :data: (maybe :data: was a recent addition).

----------

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

From report at bugs.python.org  Sun Aug  7 02:20:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 00:20:20 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1312676420.94.0.882388688333.issue12661@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello Leonid, I think the best way forward would be post it as a recipe in active state cookbook if you have not already and see the adoption. If there is enough, then it can be added to shutil module. AFAIK, a couple of shutil features have gained entry in this way.

----------

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

From report at bugs.python.org  Sun Aug  7 03:00:59 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 01:00:59 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312678859.86.0.770253706041.issue10087@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

FWIW, I think removing the encoding facility (more so because it can interfere with the terminal encoding) and just dealing with strings to output the html version of calendar seems a neater way than definiing write = sys.stdout.buffer.write and writing the bytes to the STDOUT.

Is this not feasible at the moment?

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sun Aug  7 03:20:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 07 Aug 2011 01:20:23 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1312680023.8.0.670313839334.issue12608@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks for the test case Albert.  The attached patch adds a unit test based off of the given repro case and fixes the bug in the FunctionDef compiler.  The compiler was hitting a NULL pointer deref on FunctionDefs with empty list bodies.

Reproduced and fixed on tip.  Full test suite ran on Fedora 15; no regressions.

----------
keywords: +patch
nosy: +meador.inge
stage:  -> patch review
Added file: http://bugs.python.org/file22852/issue12608.patch

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

From report at bugs.python.org  Sun Aug  7 03:23:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 07 Aug 2011 01:23:34 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312680214.35.0.47972249804.issue10087@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

BTW, accessing sys.stdout.buffer is not really safe, because if sys.stdout has been replaced with some other object, the buffer attribute might not be available (IIRC StringIO doesn't have it).

----------

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

From report at bugs.python.org  Sun Aug  7 03:39:51 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sun, 07 Aug 2011 01:39:51 +0000
Subject: [issue12705] Make compile('1\n2\n', '',
	'single') raise an exception instead of silently truncating?
Message-ID: <1312681191.75.0.586407900237.issue12705@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

(this is copy-pasted from http://mail.python.org/pipermail/python-ideas/2011-July/010787.html )

compile('1\n2\n', '','single') == compile('1\n', '','single').

That is, it ignores the second statement ('2\n'),
without offering a way for the caller to detect this.

Considering that 'single' is primarily used to emulate the behaviour
of the Python interpreter, most of the time, giving it multiple
statements is an impossibility, and so that case doesn't matter and
could raise an exception without affecting existing code. For example,
the code module meets this description, as do debuggers and such.

However, in cases where it _is_ possible to give the compiler multiple
statements, the user should be warned that his input isn't valid,
somehow. For example, the following doctest will mysteriously fail,
because it was written incorrectly (doctest uses 'single'):

   >>> import sys
   ... sys.stdout.write('foo\n')
   foo

This is because the second statement in the doctest was silently
discarded by compile(). It might not always be clear to users how to
fix this, and I think this kind of non-obvious error would exist in
any use of 'single' that can in theory involve multiple statements,
through user error or program bug. So I'd appreciate it if compile()
raised an exception in this case. Perhaps SyntaxError or ValueError.

----------
components: Interpreter Core
messages: 141735
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Make compile('1\n2\n', '', 'single') raise an exception instead of silently truncating?
versions: Python 3.3

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

From report at bugs.python.org  Sun Aug  7 03:40:12 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 07 Aug 2011 01:40:12 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312681212.2.0.965698460587.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Senthil: I think that would fundamentally make things worse. The HTML calendar apparently always provides a bytes type, but lets assume it provided you with unicode and we used sys.stdout.write on the output. Fundamentally you would get the same behavior as the patch provides since if you don't provide an encoding it uses sys.getdefaultencoding() which, IIUC is fundamentally what happens if you sys.stdout.write a unicode string.

Ezio: I think it is highly unlikely that someone would be fiddling around with sys.stdout and then calling the main() function on calendar.main() (after setting up sys.args so that option parser gets the right parameters).

----------

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

From report at bugs.python.org  Sun Aug  7 03:44:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 01:44:52 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312681492.53.0.638768763935.issue12677@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sandro - You could go ahead and commit this.

----------

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

From report at bugs.python.org  Sun Aug  7 03:46:40 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 07 Aug 2011 01:46:40 +0000
Subject: [issue1346874] httplib simply ignores CONTINUE
Message-ID: <1312681600.69.0.960451640544.issue1346874@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
nosy: +Nikratio

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

From report at bugs.python.org  Sun Aug  7 08:06:43 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 06:06:43 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312697203.15.0.909649558635.issue10087@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Chris, as you already suggested in msg124410, I would prefer the removal of encoding specification from command line. Providing the encoding argument via API with deprecating warning is a good idea.

The output should be string and it should be just be printed. It should not be converted to bytes and then decoded back to string.

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

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

From report at bugs.python.org  Sun Aug  7 08:07:40 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 06:07:40 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1312697260.54.0.511321008841.issue12398@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Sun Aug  7 10:26:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:26:58 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312705618.78.0.576869660202.issue12541@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Here is a patch with the test for accepting the badly formed headers. I would like to ensure that change in the regex is fool-proof in order to accomodate this bad behavior, so that we don't break the existing stuff.

It is problem at the server end,I found that browsers thrown warning before accepting that.

----------
keywords: +patch
Added file: http://bugs.python.org/file22853/issue12541.patch

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

From report at bugs.python.org  Sun Aug  7 10:33:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:33:01 +0000
Subject: [issue12706] timeout sentinel in ftplib and poplib
Message-ID: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

- ftplib and poplib, has them as timeout=None, while they default                                                                               
 to socket._GLOBAL_DEFAULT_TIMEOUT object.                                                                                                           
                                                                                                                                                      
This is wrong; someone may pass None thinking it will trigger the                                                                                     
default behaviour, and have nasty surprises.

----------
assignee: docs at python
messages: 141740
nosy: docs at python, orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: timeout sentinel in ftplib and poplib
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Aug  7 10:33:16 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:33:16 +0000
Subject: [issue12706] timeout sentinel in ftplib and poplib documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1312705996.77.0.898288094662.issue12706@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
title: timeout sentinel in ftplib and poplib -> timeout sentinel in ftplib and poplib documentation

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

From report at bugs.python.org  Sun Aug  7 11:07:30 2011
From: report at bugs.python.org (Landry Breuil)
Date: Sun, 07 Aug 2011 09:07:30 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1312708050.56.0.328083793347.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

floatobject.c is compiled with 

cc -pthread -c -fno-strict-aliasing -O2 -pipe  -Wall -DTHREAD_STACK_SIZE=0x20000 -fPIC -O2 -pipe -Wall -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c

----------

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

From report at bugs.python.org  Sun Aug  7 11:08:39 2011
From: report at bugs.python.org (Landry Breuil)
Date: Sun, 07 Aug 2011 09:08:39 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1312708119.26.0.975700231214.issue12589@psf.upfronthosting.co.za>


Changes by Landry Breuil <landry at openbsd.org>:


Added file: http://bugs.python.org/file22854/pyconfig.h

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

From report at bugs.python.org  Sun Aug  7 11:08:59 2011
From: report at bugs.python.org (Landry Breuil)
Date: Sun, 07 Aug 2011 09:08:59 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1312708139.42.0.818066358966.issue12589@psf.upfronthosting.co.za>


Changes by Landry Breuil <landry at openbsd.org>:


Added file: http://bugs.python.org/file22855/math.h

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

From report at bugs.python.org  Sun Aug  7 12:16:54 2011
From: report at bugs.python.org (Landry Breuil)
Date: Sun, 07 Aug 2011 10:16:54 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1312712214.75.0.140852507824.issue12589@psf.upfronthosting.co.za>


Landry Breuil <landry at openbsd.org> added the comment:

Interestingly, after an update of the system i can't build python 3.2.1 anymore :

/usr/include/util.h:102: error: conflicting types for 'openpty'
Include/pyport.h:634: error: previous declaration of 'openpty' was here
/usr/include/util.h:105: error: conflicting types for 'forkpty'
Include/pyport.h:635: error: previous declaration of 'forkpty' was here

./Modules/posixmodule.c: In function 'posix_lstat':
./Modules/posixmodule.c:5155: error: 'lstat' undeclared (first use in this function)
./Modules/posixmodule.c:5155: error: (Each undeclared identifier is reported only once
./Modules/posixmodule.c:5155: error: for each function it appears in.)


Relevant lines of configure output (so those seem to come from systemwide config.site) :
checking for lstat... (cached) yes
checking for openpty... (cached) no
checking for openpty in -lutil... (cached) yes
checking for forkpty... yes

I'm attaching the generated pyconfig.h and the build log, but now that seems to be a different issue.. as pyconfig.h clearly contains wrong defs.

Don't count on me too much for that issue, i have honestly no interest in python and lost enough time on that... i trust remi to pick up on it :)

----------
Added file: http://bugs.python.org/file22856/pyconfig.h.wrong

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

From report at bugs.python.org  Sun Aug  7 12:17:24 2011
From: report at bugs.python.org (Landry Breuil)
Date: Sun, 07 Aug 2011 10:17:24 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1312712244.77.0.524286666539.issue12589@psf.upfronthosting.co.za>


Changes by Landry Breuil <landry at openbsd.org>:


Added file: http://bugs.python.org/file22857/build-macppc.log

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

From report at bugs.python.org  Sun Aug  7 15:43:15 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 13:43:15 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312724595.57.0.933632288762.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

grepping over the stdlib, LookupError is only used in codecs exception; also the documentation of LE is "The base class for the exceptions that are raised when a key or index used on a mapping or sequence is invalid: IndexError, KeyError. This can be raised directly by codecs.lookup()." so I guess it's not the right exception of this case.

----------

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

From report at bugs.python.org  Sun Aug  7 17:13:37 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 07 Aug 2011 15:13:37 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312730017.28.0.911345962796.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Senthil: I wasn't advocating the removal of the ability to specify encoding, only stating that avoiding the use of sys.stdout.buffer.write could only sensibly be done if we also removed the ability to specify an encoding (I can see how my wording might have been confusing). Earlier (msg122219) I said that we probably can't remove the encoding option because that would break backwards compatibility.

FWIW, I think that the encoding parameter to the console program is probably sensible because there are no guarantees that the sys.getdefaultencoding() is actually set to the console encoding and I would guess that most people using the html option are not sending output to the console anyway. They are likely redirecting the output somewhere else because there is no "output this to a file" option.

----------

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

From report at bugs.python.org  Sun Aug  7 17:15:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Aug 2011 15:15:06 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <E1Qq54A-0004FZ-PL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a30e6c4bf486 by Sandro Tosi in branch '2.7':
#12677: correct turtle orientation in doc
http://hg.python.org/cpython/rev/a30e6c4bf486

New changeset bf4f65043d7d by Sandro Tosi in branch '3.2':
#12677: correct turtle orientation in doc
http://hg.python.org/cpython/rev/bf4f65043d7d

New changeset a7365994f4d6 by Sandro Tosi in branch 'default':
#12677: merge with 3.2
http://hg.python.org/cpython/rev/a7365994f4d6

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

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

From report at bugs.python.org  Sun Aug  7 17:17:41 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 15:17:41 +0000
Subject: [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312730261.99.0.140374689661.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  7 21:31:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Aug 2011 19:31:29 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312745489.31.0.802022344756.issue10087@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think "WARNING: this may corrupt your terminal" is warranted. Also, I think we can safely remove the --encoding option. Calling a module from the command-line is intended as a demonstration of the module's functionality, it's not an official API that we have to keep compatible.

Apart from that, Chris' latest patch and Catherine's minimal test look ok to me.

----------

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

From report at bugs.python.org  Sun Aug  7 23:10:20 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 07 Aug 2011 21:10:20 +0000
Subject: [issue5149] syntactic sugar: type coercion on pointer assignment
In-Reply-To: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za>
Message-ID: <1312751420.9.0.217288177462.issue5149@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

The main reason for this issue is that internally ctypes doesn't consider c_char_p as a pointer type. This is a bit counter-intuitive, but c_char_p is treated as a simple type and has some other sugar built-in, like easier integration with Python strings. Alternative pointer type is POINTER(c_char), which allows assignment from array.

I would make this clear in the documentation. Even now, documentation says following about c_char_p:

Represents the C char * datatype when it points to a zero-terminated string. For a general character pointer that may also point to binary data, POINTER(c_char) must be used. The constructor accepts an integer address, or a string.

So there already is a hint that c_char_p has limited use for convenience. We should maybe make documentation more clear. If you want equivalent of C char* behavior, POINTER(c_char) is the way to go.

----------
nosy: +vladris

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

From report at bugs.python.org  Sun Aug  7 23:14:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 21:14:39 +0000
Subject: [issue10741] PyGILState_GetThisThreadState() lacks a doc entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1312751679.4.0.898721987395.issue10741@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here attached a very simple patch, made by slightly re-editing the comment in pystate.h.

----------
keywords: +patch
nosy: +ezio.melotti, sandro.tosi
stage:  -> patch review
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file22858/issue10741-default.patch

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

From report at bugs.python.org  Mon Aug  8 00:12:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Aug 2011 22:12:34 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312755154.56.0.585238670606.issue12191@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, you could consider codecs an example in the stdlib of using it, and the doc could be changed to something like "stdlib modules that look up information in specialized data sources may raise this error directly".  Whether this is a good idea or not, I'm not sure, but it feels more logical than ValueError.

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

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

From report at bugs.python.org  Mon Aug  8 00:16:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Aug 2011 22:16:04 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312755364.4.0.161932042947.issue12541@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Perhaps we should issue a warning, then, too?

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

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

From report at bugs.python.org  Mon Aug  8 00:20:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Aug 2011 22:20:31 +0000
Subject: [issue10741] PyGILState_GetThisThreadState() lacks a doc entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <E1QqBhu-0006V8-4q@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8852e4a9aa1e by Sandro Tosi in branch '2.7':
#10741: add documentation for PyGILState_GetThisThreadState()
http://hg.python.org/cpython/rev/8852e4a9aa1e

New changeset 53b8260b9ea7 by Sandro Tosi in branch '3.2':
#10741: add documentation for PyGILState_GetThisThreadState()
http://hg.python.org/cpython/rev/53b8260b9ea7

New changeset 6adfeec8c482 by Sandro Tosi in branch 'default':
#10741: merge with 3.2
http://hg.python.org/cpython/rev/6adfeec8c482

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

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

From report at bugs.python.org  Mon Aug  8 00:22:13 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 22:22:13 +0000
Subject: [issue10741] PyGILState_GetThisThreadState() lacks a doc entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1312755733.55.0.851014314789.issue10741@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I just committed an improved version of the proposed patch (thanks Ezio for the review and help!).

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

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

From report at bugs.python.org  Mon Aug  8 00:26:30 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 22:26:30 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1312755154.56.0.585238670606.issue12191@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj3F3hitHz=bfmES0JKVXR_wx5tcZKpS3g0u7AWeJ1iJ1g@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Mon, Aug 8, 2011 at 00:12, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Well, you could consider codecs an example in the stdlib of using it, and the doc could be changed to something like "stdlib modules that look up information in specialized data sources may raise this error directly". ?Whether this is a good idea or not, I'm not sure, but it feels more logical than ValueError.

Sure, I was just showing my line of reasoning :) I'm ok either way: if
you feel LookupError is best, I'll change shutil.chown() code and also
the doc for LE (about that, is it ok a single patch or 2 separate?)

----------

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

From report at bugs.python.org  Mon Aug  8 00:45:50 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 07 Aug 2011 22:45:50 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312757150.51.0.665981166711.issue12437@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Not sure how this can be fixed actually. I don't think PyErr_SetFromErrno instead of PyErr_SetString would work because as far as I can tell, standard does not mention dlopen making use of errno. Unlike Windows, where LoadLibrary will change last-error, if dlopen fails, only way to retrieve error is to dlerror which returns a string, no error code.

----------
nosy: +vladris

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

From report at bugs.python.org  Mon Aug  8 00:52:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Aug 2011 22:52:01 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312757521.87.0.556592863036.issue12682@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, as long as 'accepted' is under 'resolution', I'm likely to keep using it for feature requests, I suppose because I'm too much of a precisonist.  If someone wants to re-engineer the interface, that would be fine with me :)

I personally don't mind other uses, nor do I find myself searching on resolutions.

----------

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

From report at bugs.python.org  Mon Aug  8 01:46:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 07 Aug 2011 23:46:10 +0000
Subject: [issue12707] Deprecate addinfourl getters
Message-ID: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The documentation for urllib.request.urlopen [0] says that:
"""
This function returns a file-like object [addinfourl] with two additional methods from the urllib.response module
    geturl() ? return the URL of the resource retrieved, [...]
    info() ? return the meta-information of the page, [...]
"""

There's also a third undocumented method: getcode().  Looking at the code[1] ISTM that the 3 getters (geturl(), info(), and getcode()):
  1) have an inconsistent interface (why not getinfo() or getheaders()?);
  2) they just return the url, headers, and code attributes;

For these two reasons I propose to:
  * document the 3 attributes as the suggested way to access this information;
  * deprecate the 3 getters;
  * avoid to document the now undocumented getcode();


[0]: http://docs.python.org/py3k/library/urllib.request.html
[1]: Lib/urllib/response.py:83

----------
components: Library (Lib)
keywords: easy
messages: 141756
nosy: ezio.melotti, orsenthil, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate addinfourl getters
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug  8 01:54:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 07 Aug 2011 23:54:48 +0000
Subject: [issue10050] urllib.request still has old 2.x urllib primitives
In-Reply-To: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>
Message-ID: <1312761288.61.0.417298067439.issue10050@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/issue10050>
_______________________________________

From report at bugs.python.org  Mon Aug  8 02:26:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 00:26:11 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1312763171.77.0.398168303762.issue12707@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Another possible improvement that can be done is providing a proper Response object instead of addbase, addinfo, addinfourl (yes, those are oddly-named classes, not functions [0]).
The Response object could be like 'addbase', but with this signature:

class Response:
    def __init__(self, fp, headers=None, url=None, code=None):
        ...
and without additional getters.

The addclosehook class could be provided via an alternative constructor:

    @classmethod
    def with_close_hook(cls, fp, hook, *hookargs):
        ...

[0]: Lib/urllib/response.py

----------

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

From report at bugs.python.org  Mon Aug  8 03:09:17 2011
From: report at bugs.python.org (Craig McQueen)
Date: Mon, 08 Aug 2011 01:09:17 +0000
Subject: [issue1205239] Let shift operators take any integer value
Message-ID: <1312765757.13.0.351001119897.issue1205239@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

So this has been rejected I see. Too bad, since I stub my metaphorical toe on this issue from time to time. Just for the record, here is an example:

http://stackoverflow.com/questions/4130936/perfect-hash-function/6976723#6976723

----------

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

From report at bugs.python.org  Mon Aug  8 08:08:04 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 08 Aug 2011 06:08:04 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1312783684.08.0.842985346177.issue12707@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

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

From report at bugs.python.org  Mon Aug  8 09:25:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Aug 2011 07:25:04 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312788304.34.0.40966738773.issue12437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, it looks more like a bug in the POSIX standard unfortunately.
I'm suggesting to close as "won't fix".

----------
nosy: +pitrou
resolution:  -> wont fix
status: open -> pending

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

From report at bugs.python.org  Mon Aug  8 09:30:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Aug 2011 07:30:38 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312788638.01.0.498436583536.issue12700@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +haypo

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

From report at bugs.python.org  Mon Aug  8 09:34:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 08 Aug 2011 07:34:15 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1312788855.1.0.796473936471.issue12646@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Mon Aug  8 09:42:33 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 08 Aug 2011 07:42:33 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312789353.71.0.011959203345.issue12437@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

I didn't notice there was no use of errno. It's quite possible that dlopen might be used without the C library present, so perhaps this is why it wasn't included. The error strings however are very C-like, which made me think of this in the first place. Thanks all.

----------
status: pending -> open

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

From report at bugs.python.org  Mon Aug  8 09:49:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Aug 2011 07:49:21 +0000
Subject: [issue12437] _ctypes.dlopen does not include errno in OSError
In-Reply-To: <1309306027.41.0.167603787283.issue12437@psf.upfronthosting.co.za>
Message-ID: <1312789761.62.0.109772220322.issue12437@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Mon Aug  8 10:21:47 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 08:21:47 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
Message-ID: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

After I've seen a co-worker to unpack tuples while using multiprocessing.Pool.map(), I realized that the module is missing a starmap() method like itertools has.

I took it as a opportunity to contribute some code and implemented both starmap() and starmap_async().

The patch including tests is attached, please let me know, what you think. Please don't call me names, it's my first patch for such a high profile project like Python. ;)

----------
components: Library (Lib)
files: mp-starmap.diff
keywords: patch
messages: 141761
nosy: hynek, jnoller
priority: normal
severity: normal
status: open
title: multiprocessing.Pool is missing a starmap[_async]() method.
type: feature request
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/file22859/mp-starmap.diff

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

From report at bugs.python.org  Mon Aug  8 10:56:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 08:56:41 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312793801.6.0.291345493091.issue12700@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_enable_file, test_enable_single_thread, test_gil_released and test_read_null read an int (4 bytes) from the address 0 (NULL).

test_sigsegv pass: this test raises explicitly a SIGSEGV and the signal handler writes the right message ("Segmentation fault").

Mac OS X Lion raises maybe a SIGILL on a segmentation fault if the address is zero? I suppose that it raises a SIGSEGV if the address is not zero.

Can you try to modify the function faulthandler_read_null() in Modules/faulthandler.c: replace "int *x = NULL, y;" by "int *x = (int *)1, y;" ? Then recompile (make) and rerun the test (./python.exe -m test -v test_faulthandler).

----------

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

From report at bugs.python.org  Mon Aug  8 11:36:52 2011
From: report at bugs.python.org (Pere Martir)
Date: Mon, 08 Aug 2011 09:36:52 +0000
Subject: [issue12600] Support parameterized TestCases in unittest
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1312796212.62.0.851061200491.issue12600@psf.upfronthosting.co.za>


Changes by Pere Martir <pere.martir4 at gmail.com>:


----------
nosy: +pere.martir

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

From report at bugs.python.org  Mon Aug  8 12:10:09 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:10:09 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
Message-ID: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

While working on #12708 , I noticed that the error_callback argument of multiprocessing.Pool.map_async() isn't documented (callback is).

----------
assignee: docs at python
components: Documentation
messages: 141763
nosy: docs at python, hynek
priority: normal
severity: normal
status: open
title: In multiprocessing, error_callback isn't documented for map_async
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug  8 12:37:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 10:37:12 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312799832.68.0.222354828739.issue12709@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Would you like to provide a doc patch about it? Thanks in advance

----------
nosy: +sandro.tosi
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

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

From report at bugs.python.org  Mon Aug  8 12:46:20 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Aug 2011 10:46:20 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312800380.17.0.493303569251.issue10087@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I agree with Chris's point that people using html format in console are probably redirecting to a file and encoding parameter should be helpful.

What do we settle upon? Leave the encoding argument as such?

Antoine - I was specifically interested to know if sys.stdout.buffer.write as in the patch was good(/proper) way to go forward writing the bytes?

----------

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

From report at bugs.python.org  Mon Aug  8 12:48:23 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Aug 2011 10:48:23 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1312755364.4.0.161932042947.issue12541@psf.upfronthosting.co.za>
Message-ID: <20110808104814.GB1992@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I don't think so. We are just making our regex bit lenient. I am not
sure how we can raise a warning with more lenient regex.

As with any parsing changes, I would like to be careful and that we
don't introduce any regression.

----------

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

From report at bugs.python.org  Mon Aug  8 12:50:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Aug 2011 10:50:17 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312757521.87.0.556592863036.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110808105007.GC1992@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

R. David Murray wrote:
>  If someone wants to re-engineer the interface, that would be fine with me :)

Does that mean, that if vote for removing the 'accepted' keyword it
becomes an issue for the meta-tracker?

----------

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

From report at bugs.python.org  Mon Aug  8 12:52:06 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:52:06 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1312800726.84.0.161928250282.issue12708@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

In all my excitement, I somehow presumed that the docstring automagically lands in the docs. Added doc entries to patch (I hope they aren't too crude, I'm not a native speaker).

Same as first patch otherwise.

----------
Added file: http://bugs.python.org/file22860/mp-starmap-w-docs.diff

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

From report at bugs.python.org  Mon Aug  8 12:53:59 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:53:59 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312800839.96.0.735383956402.issue12709@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Yeah, if my 3G hadn't failed on me, it would have been already here. :)

As a matter of fact, the argument is discussed in the body of the doc, it just has been omitted in the method definition, so the patch is trivial.

----------
keywords: +patch
Added file: http://bugs.python.org/file22861/map_async-doc-fix.diff

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

From report at bugs.python.org  Mon Aug  8 13:12:46 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 11:12:46 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1312801966.15.0.892958770931.issue12708@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


Removed file: http://bugs.python.org/file22859/mp-starmap.diff

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

From report at bugs.python.org  Mon Aug  8 13:19:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 11:19:25 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1312802365.75.0.965495158036.issue10087@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy:  -haypo

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

From report at bugs.python.org  Mon Aug  8 13:21:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 11:21:54 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1312802514.24.0.0408827094235.issue10570@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #12567.

----------

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

From report at bugs.python.org  Mon Aug  8 13:22:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 11:22:09 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1312802529.82.0.5913767424.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #10570.

----------

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

From report at bugs.python.org  Mon Aug  8 13:35:06 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 08 Aug 2011 11:35:06 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1312803306.53.0.147040932134.issue10570@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

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

From report at bugs.python.org  Mon Aug  8 13:39:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 11:39:32 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1312803572.21.0.0111606730924.issue12669@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Correction: the offending options are -j and *-W*

I changed regrtest -W recently to only run the tests once using StringIO as stdout. So it's a regression in Python 3.3.

Can't we create a dummy/temporary TTY for the curses tests using pty.openpty()?

----------

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

From report at bugs.python.org  Mon Aug  8 13:42:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 11:42:58 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1312298934.67.0.849915158077.issue9561@psf.upfronthosting.co.za>
Message-ID: <4E3FCBBA.3020002@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Ping. What's the progress on this? Will this ever be fixed?

Some functions has been fixed in the new packaging module, but not in 
the distutils yet.

----------

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

From report at bugs.python.org  Mon Aug  8 14:49:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Aug 2011 12:49:07 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312807747.18.0.124597539391.issue12682@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think we've moved from discussing a documentation issue to discussing a procedural issue in the development process.  I'm not sure what forum that belongs in, though I believe in the past we have used tracker-discuss for that.

That said, I'm really fine with whatever is decided, and don't think it is that big a deal in any regard.

----------

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

From report at bugs.python.org  Mon Aug  8 15:08:23 2011
From: report at bugs.python.org (Toni Boni)
Date: Mon, 08 Aug 2011 13:08:23 +0000
Subject: [issue12710] GTK crash
Message-ID: <1312808903.85.0.866514845542.issue12710@psf.upfronthosting.co.za>


New submission from Toni Boni <toniboni88 at gmail.com>:

Deluge Gui crash with this error (image in attachment).
I've Ubuntu 10.10 updated, Python 2.6.6.2ubuntu2

The bug is reported: http://dev.deluge-torrent.org/ticket/1914

----------
assignee: tarek
components: Distutils
files: 1rx5ec.jpg.png
messages: 141775
nosy: eric.araujo, tarek, toniboni88
priority: normal
severity: normal
status: open
title: GTK crash
versions: Python 2.6
Added file: http://bugs.python.org/file22862/1rx5ec.jpg.png

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

From report at bugs.python.org  Mon Aug  8 15:10:12 2011
From: report at bugs.python.org (david)
Date: Mon, 08 Aug 2011 13:10:12 +0000
Subject: [issue11357] Add support for PEP 381 Mirror Authenticity
In-Reply-To: <1298948795.56.0.864012658533.issue11357@psf.upfronthosting.co.za>
Message-ID: <1312809012.82.0.348926913309.issue11357@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
nosy: +db

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

From report at bugs.python.org  Mon Aug  8 15:10:45 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 13:10:45 +0000
Subject: [issue12710] GTK crash
In-Reply-To: <1312808903.85.0.866514845542.issue12710@psf.upfronthosting.co.za>
Message-ID: <1312809045.79.0.600422565219.issue12710@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello, this is not a but in the python interpreter (f.e., the traceback in the image is referring to twisted) so I'm closing it as invalid. The best way of action is contacting the deluge developers, as you did with the other report.

----------
nosy: +sandro.tosi
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Aug  8 15:33:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 13:33:42 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1312810422.87.0.519172796839.issue11836@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here's a patch to add SimpleQueue to doc and __all__ .

I didn't document the 'sentinels' argument of SimpleQueue.get() because I got lost into Pipe _pool and can't understand how those sentinels are actually used/useful. Any hint is appreciated :)

----------
nosy: +ezio.melotti, sandro.tosi
stage: needs patch -> patch review
versions: +Python 2.7 -Python 3.1

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

From report at bugs.python.org  Mon Aug  8 15:34:02 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 13:34:02 +0000
Subject: [issue11836] multiprocessing.queues.SimpleQueue is undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1312810442.12.0.730027094066.issue11836@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22863/issue11836-default.patch

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

From report at bugs.python.org  Mon Aug  8 16:23:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 14:23:29 +0000
Subject: [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312813409.04.0.603191454931.issue12666@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The content of the patch is very helpful, but I question its location: I?m not sure people will find this nugget in the 3.2+ version of the What?s New in Python 3.0 document (sorry for not bringing that up sooner).  Maybe you could update Doc/library/functions.rst instead, and/or Doc/howto/pyporting.rst?

----------

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

From report at bugs.python.org  Mon Aug  8 16:31:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 14:31:21 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312813881.33.0.389938190576.issue12301@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I would like to help out with this, as there seems to be a lot of
> work that needs to be done.

Thanks!  In my initial report, I was talking only about module-level names that are documented as code (``sys.path``) instead of module-level data (:data:`sys.path`); the point is that the latter form creates a link to the doc of the module-level name.

I wasn?t aware that some functions and keywords used code markup instead or link-creating markup, like you found out for eval and getattr.  These should be fixed too.

Terry: You?re right, ``x`` is the most generic markup for inline code in reST.  It is used for command lines, program options that are not Python?s options (see #9312), bits of Python code, etc.

Now, about the amount of work needed: Don?t waste hours looking for all of these in the docs!  If you know basic shell commands, it?s easy to have *all* instances of ``sys.path`` changed to :data:`sys.path` in one go.  The thing requiring human attention is first listing all of the misuses of ````, second reviewing the changes.

----------

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

From report at bugs.python.org  Mon Aug  8 16:35:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 14:35:05 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312814105.91.0.579798295786.issue12301@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

instead of*

An addition: in some cases, it may be on purpose that someone used ``somename`` instead of :func:`somename`, for example to avoid a ton of link in the doc of the somename function.  For the most part however, I believe it was just unawareness (or maybe unavailability) of the :data: construct that explains its absence.

One last precision: markup like ``getattr(spam, ham)`` should stay untouched: it is a code snippet, not just a reference to the function.

----------

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

From report at bugs.python.org  Mon Aug  8 16:40:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Aug 2011 14:40:47 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <E1QqR0Y-0006xF-5x@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b2835b8412e5 by Sandro Tosi in branch '2.7':
#12709: add error_callback argument to map_async documentation
http://hg.python.org/cpython/rev/b2835b8412e5

New changeset 41b816853819 by Sandro Tosi in branch '3.2':
#12709: add error_callback argument to map_async documentation
http://hg.python.org/cpython/rev/41b816853819

New changeset 0c922e7d26e1 by Sandro Tosi in branch 'default':
#12709: merge with 3.2
http://hg.python.org/cpython/rev/0c922e7d26e1

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

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

From report at bugs.python.org  Mon Aug  8 16:41:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 14:41:23 +0000
Subject: [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312814483.0.0.673525146888.issue12709@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hynek, thanks for your contribution to Python!

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

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

From report at bugs.python.org  Mon Aug  8 16:42:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 14:42:56 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312814576.91.0.570362181871.issue12301@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

``...`` should also be used for common names like True, False, None (no one needs links to their doc to see what they are), or, as ?ric said, to avoid creating links for each occurrence of a name (one such example is the name of a module in the page that documents it).

I think that ``getattr(spam, ham)`` could be also written as :func:`getattr(spam, ham) <getattr>` in case you want to generate explicitly a link to getattr.  However in most of the cases this is not necessary.

----------

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

From report at bugs.python.org  Mon Aug  8 16:46:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 14:46:36 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312814796.13.0.341517765961.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LookupError sounds good.  About the latest patch: I wonder if using !a instead of !r in the format strings for exceptions would be more helpful (maybe you?ve seen a recent python-dev subthread about that).  I don?t like seeing escapes for perfectly common characters like ? or ?, but OTOH escapes help disambiguating different characters that look the same.  Apart from these two points, this is good to go.

A doc addition for LookupError would be an independent changeset; it has nothing to do with adding shutil.chown.

----------

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

From report at bugs.python.org  Mon Aug  8 17:19:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:19:53 +0000
Subject: [issue12711] Explain tracker components in devguide
Message-ID: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Users reporting bugs don?t always know what components to set.  http://docs.python.org/devguide/triaging#components should explain them.

----------
components: Devguide
messages: 141785
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Explain tracker components in devguide
versions: 3rd party

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

From report at bugs.python.org  Mon Aug  8 17:20:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:20:59 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1312816859.44.0.753462152356.issue12604@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

_sre is a module written in C, not Python; we call that an extension module.  The Library component is used for Python modules, which are found in the Lib directory in a checkout of CPython.  See #12711.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Aug  8 17:22:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:22:01 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1311280694.44.0.358463373739.issue12604@psf.upfronthosting.co.za>
Message-ID: <1312816921.98.0.755936439381.issue12604@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Aug  8 17:49:37 2011
From: report at bugs.python.org (Chris Palmer)
Date: Mon, 08 Aug 2011 15:49:37 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1312818577.45.0.280790654348.issue670664@psf.upfronthosting.co.za>


Changes by Chris Palmer <chris at isecpartners.com>:


----------
nosy:  -cpalmer

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

From report at bugs.python.org  Mon Aug  8 17:49:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 15:49:42 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1312818582.18.0.54933674201.issue12711@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This are the current components in random order and a possible description:
"""
The following components should be selected if the issue apply to:
Build
  the build process
Demos and Tools
  the scripts in Tools/ and Tools/demo/
2to3 (2.x to 3.0 conversion tool)
  the 2to3 conversion tool and Lib/2to3/
Extension Modules
  C modules in Modules/
IDLE
  IDLE and Lib/idlelib/
Installation
  the installation process
Interpreter Core
  the interpreter core, built-in objects in Objects/, the Python/, Grammar/ and Parser/ dirs
Library (Lib)
  Python modules in Lib/
Regular Expressions
  regular expressions, and the Lib/re.py and Modules/_sre.c modules
Tests
  the tests in Lib/test/, the unittest and doctest frameworks in Lib/unittest/, Lib/doctest.py
Tkinter
  Tkinter an Lib/tkinter
Unicode
  Unicode, codecs, str vs bytes, Objects/unicodeobject.c
Windows
  the Windows operating system
XML
  XML and Lib/xml/
Macintosh
  the Macintosh operating system
Documentation
  the documentation in Doc/
Benchmarks
  ???
Distutils
  the distutil package in Lib/distutils/
Distutils2
  the packaging package in Lib/packaging/
Devguide
  the devguide at h.p.o/devguide
ctypes
  the ctypes package in Lib/ctypes/
"""

I'm not sure what the Benchmark component is supposed to be about (generic benchmarks? timeit/profile and friends? "performance" issues?).
If I got all the descriptions and files/dirs right I can prepare a patch for the devguide.  FWIW there was a somewhat similar issue in the meta-tracker too.

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
versions:  -3rd party

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

From report at bugs.python.org  Mon Aug  8 17:49:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:49:52 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1312818592.3.0.630029323465.issue12657@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, rhettinger

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

From report at bugs.python.org  Mon Aug  8 17:52:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:52:34 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312818754.02.0.945275985794.issue12672@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> it's unclear what [].append is.
It?s crystal clear to me: [].append is a method of a list object, just created here by a literal.  (Maybe you?re not aware that [].append is valid Python.)

> The C coding convention is unusual and non PEP-7 in 2.1.1
Running Tools/scripts/untabify.py on the C codebase reveals problems in Doc/include/*.c, Objects, Python, etc.

----------
nosy: +eric.araujo, pitrou

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

From report at bugs.python.org  Mon Aug  8 17:56:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:56:07 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312818967.74.0.873684537005.issue12682@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

When we?ve talked about that a few times these last months on the ML or on IRC, the outcome was that accepted means patch is accepted, not bug report is valid.  I?ve never seen accepted used to mean that a feature request is closed; I use fixed for solved bugs and added features alike and don?t see a problem with it.

----------
nosy: +eric.araujo, rhettinger

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

From report at bugs.python.org  Mon Aug  8 17:56:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:56:58 +0000
Subject: [issue12032] Tools/Scripts/crlf.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <1312819018.92.0.90636651851.issue12032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This needs porting to 3.2.

----------
nosy: +eric.araujo
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Mon Aug  8 18:00:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 16:00:38 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312819238.98.0.402166041518.issue12682@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

"patch accepted" can be marked with the "commit review" stage.
That should mean "the patch is ready to go in, after a last quick review by the committer that will apply it", even though I've seen it used as "I made the commit but I'm leaving this open until I'm sure everything still works".

----------

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

From report at bugs.python.org  Mon Aug  8 18:26:44 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 16:26:44 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1312820804.12.0.828956951756.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

after a review from Ezio (thanks!) we've come out with this updated patch; main changes are in the test suite, where now it's checked that chown() succeed. about !r/!a I've left !r; and changed the 2 ValueError in LookupError (the first, in case no arguments are passed, it's still there).

----------
Added file: http://bugs.python.org/file22864/shutil_chown-default-v6.patch

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

From report at bugs.python.org  Mon Aug  8 18:53:00 2011
From: report at bugs.python.org (Tim Holme)
Date: Mon, 08 Aug 2011 16:53:00 +0000
Subject: [issue12712] weave build_tools library identification
Message-ID: <1312822380.43.0.720864294913.issue12712@psf.upfronthosting.co.za>


New submission from Tim Holme <timholme at gmail.com>:

This may be a problem with scipy/weave, or it may be a problem with the site-library pythonequations, or it may be in python 2.7.2 itself.  

When running the program, it looks for an installed version of MinGW, which it finds.  It is possibly looking for C:\Python27\lib\distutils\core.py in the wrong location (the "Lib" should be capitalized?) It then throws the error report:

Found executable C:\MinGW\bin\g++.exe

Traceback (most recent call last):
  File "C:\Python27\Lib\site-packages\pythonequations\QuadFit3D.py", line 327, in <module>
    TkFileDialogExample(root).pack()
  File "C:\Python27\Lib\site-packages\pythonequations\QuadFit3D.py", line 315, in __init__
    run(fname,MAX_MSE)
  File "C:\Python27\Lib\site-packages\pythonequations\QuadFit3D.py", line 68, in run
    equation.SetGAParametersAndGuessInitialCoefficientsIfNeeded() # estimate initial parameters if needed
  File "C:\Python27\lib\site-packages\pythonequations\EquationBaseClasses.py", line 631, in SetGAParametersAndGuessInitialCoefficientsIfNeeded
    self.EstimateInitialCoefficientsUsingCPP()
  File "C:\Python27\lib\site-packages\pythonequations\EquationBaseClasses.py", line 1502, in EstimateInitialCoefficientsUsingCPP
    weave.inline(code, parameterNameList, support_code = supportCode, extra_compile_args = Equation.compiler_flags_for_weave_inline, compiler = Equation.compiler_name)
  File "C:\Python27\lib\site-packages\scipy\weave\inline_tools.py", line 355, in inline
    **kw)
  File "C:\Python27\lib\site-packages\scipy\weave\inline_tools.py", line 482, in compile_function
    verbose=verbose, **kw)
  File "C:\Python27\lib\site-packages\scipy\weave\ext_tools.py", line 367, in compile
    verbose = verbose, **kw)
  File "C:\Python27\lib\site-packages\scipy\weave\build_tools.py", line 272, in build_extension
    setup(name = module_name, ext_modules = [ext],verbose=verb)
  File "C:\Python27\lib\site-packages\numpy\distutils\core.py", line 186, in setup
    return old_setup(**new_attr)
  File "C:\Python27\lib\distutils\core.py", line 162, in setup
    raise SystemExit, error
CompileError: error: Bad file descriptor

----------
components: Library (Lib)
messages: 141793
nosy: Tim.Holme
priority: normal
severity: normal
status: open
title: weave build_tools library identification
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  8 19:40:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 08 Aug 2011 17:40:40 +0000
Subject: [issue12604] VTRACE macro in _sre.c should use do {} while (0)
In-Reply-To: <1312816859.44.0.753462152356.issue12604@psf.upfronthosting.co.za>
Message-ID: <20110808174036.GA1790@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> _sre is a module written in C, not Python; we call that an extension
> module. The Library component is used for Python modules, which are
> found in the Lib directory in a checkout of CPython. See #12711.

Ok, I wasn't aware of this. Thanks.

----------

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

From report at bugs.python.org  Mon Aug  8 19:51:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Aug 2011 17:51:31 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312825891.73.0.385610313567.issue12682@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Changing the dev guide, which I think is definitely needed, is an issue for this tracker. Changing the tracker is an issue for the meta-tracker. Discussing a change might be an issue for python-dev.

I was under the impression once that the tracker fields were going to be reviewed last summer, before the dev guide was written. This could still happen any time.

----------

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

From report at bugs.python.org  Mon Aug  8 20:09:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Aug 2011 18:09:45 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1312826985.62.0.9403709511.issue12301@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Changing ``x`` to :data:`x` adds 4 chars.
Changing ``x()`` to :func:`x` justs adds 2.
If I were to review, I would prefer that the additions not trigger cascading line rewraps.

----------

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

From report at bugs.python.org  Mon Aug  8 22:24:10 2011
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Aug 2011 20:24:10 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312835050.34.0.9820930736.issue12700@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

After changing NULL to (int *)1, all tests pass.

----------

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

From report at bugs.python.org  Mon Aug  8 22:26:03 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 08 Aug 2011 20:26:03 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1312835163.2.0.649067577867.issue12669@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Can't we create a dummy/temporary TTY for the curses tests using pty.openpty()?

I would have thought so, but it seems that savetty() and endwin() both fail when
running under '-j0':

    test test_curses crashed -- Traceback (most recent call last):
      File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 289, in test_main
        main(stdscr)
      File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 269, in main
        curses.savetty()
    _curses.error: savetty() returned ERR

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/home/nadeem/code/cpython/python/Lib/test/regrtest.py", line 1139, in runtest_inner
        indirect_test()
      File "/home/nadeem/code/cpython/python/Lib/test/test_curses.py", line 291, in test_main
        curses.endwin()
    _curses.error: endwin() returned ERR

It might be that you need to close stdout and stderr so that there's only one
TTY associated with the process, but I suspect that'll break other things.

----------

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

From report at bugs.python.org  Mon Aug  8 22:44:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Aug 2011 20:44:32 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <E1QqWgZ-0007hN-5p@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1777df2ce50d by Victor Stinner in branch 'default':
Issue #12700: fix test_faulthandler for Mac OS X Lion
http://hg.python.org/cpython/rev/1777df2ce50d

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

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

From report at bugs.python.org  Mon Aug  8 22:47:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 20:47:04 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312836424.06.0.173889887978.issue12700@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> After changing NULL to (int *)1, all tests pass.

Ok, so Lion has a special case for reading from NULL. I changed the tests to try to fix your bug. Can you tell me if it's now better?

----------

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

From report at bugs.python.org  Mon Aug  8 22:52:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 20:52:53 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1312836773.4.0.705694459864.issue12711@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a proper patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22865/issue12711.diff

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

From report at bugs.python.org  Mon Aug  8 23:12:56 2011
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Aug 2011 21:12:56 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312837976.4.0.142052600617.issue12700@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

All tests now pass.

----------

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

From report at bugs.python.org  Mon Aug  8 23:17:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Aug 2011 21:17:07 +0000
Subject: [issue12700] test_faulthandler fails on Mac OS X Lion
In-Reply-To: <1312586314.63.0.605115696867.issue12700@psf.upfronthosting.co.za>
Message-ID: <1312838227.9.0.380889111811.issue12700@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> All tests now pass.

Ok, thanks for your report and your feedback.

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

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

From report at bugs.python.org  Mon Aug  8 23:24:14 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 08 Aug 2011 21:24:14 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312599156.73.0.499187629172.issue12701@psf.upfronthosting.co.za>
Message-ID: <F7910A83-28AB-409F-810E-E87B848C7761@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile?

There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard.

----------
Added file: http://bugs.python.org/file22866/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12701>
_______________________________________
-------------- next part --------------
<html><body bgcolor="#FFFFFF"><blockquote type="cite"><div><br><font class="Apple-style-span" color="#000000"><br></font></div></blockquote>Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile?<div><br></div><div>There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard.&nbsp;</div><div><br></div></body></html>

From report at bugs.python.org  Mon Aug  8 23:25:06 2011
From: report at bugs.python.org (Simon Law)
Date: Mon, 08 Aug 2011 21:25:06 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1312838706.87.0.859867490361.issue444582@psf.upfronthosting.co.za>


Changes by Simon Law <sfllaw at sfllaw.ca>:


----------
nosy: +sfllaw

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

From report at bugs.python.org  Tue Aug  9 00:17:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Aug 2011 22:17:47 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1312841867.23.0.160292727491.issue12701@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Aug  9 03:55:57 2011
From: report at bugs.python.org (Peter Williams)
Date: Tue, 09 Aug 2011 01:55:57 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
Message-ID: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>


New submission from Peter Williams <pwil3058 at bigpond.net.au>:

Quite often the names of subcommands are quite long so that their meaning is clear.  However, the downside to this is the increased typing the user of the command must make.  A compromise between clarity and brevity can be realized if abbreviation of subcommands is allowed with the proviso that the abbreviation must be long enough to remove any ambiguity.

So that this feature is not foisted on every programmer that uses argparse it could be made an option to the ArgumentParser class with the (possible) additional refinement of specifying a minimum number of characters for the abbreviations.

----------
components: Library (Lib)
messages: 141805
nosy: pwil3058
priority: normal
severity: normal
status: open
title: argparse: allow abbreviation of sub commands by users
type: feature request

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

From report at bugs.python.org  Tue Aug  9 04:29:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Aug 2011 02:29:12 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312807747.18.0.124597539391.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110809022903.GB2190@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

RDM, yes, unfortunately the direction of the discussion changed from
documentation issue to a process one. Instead of diverting further
into catch all discussion about process/tracker, it would be good idea
to settle this one. Your points definitely counts as you raised
the issue and have experience in dealing with tracker states. What
would you suggest?

----------

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

From report at bugs.python.org  Tue Aug  9 04:40:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 09 Aug 2011 02:40:30 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312857630.36.0.242503919129.issue12672@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,
I know perfectly well that [].append is valid Python, but I don't think this is the clearest way to give an example of an object method. I think spelling [].append's meaning more explicitly would be better.

I'm also aware that there are tab problems all over the code base. I'm not suggesting a large cleanup. But I do think that in *example code* in the documentation, it wouldn't hurt to make the code idiomatically styled. After all, this is what people will copy-paste when writing new code.

----------

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

From report at bugs.python.org  Tue Aug  9 05:08:43 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 09 Aug 2011 03:08:43 +0000
Subject: [issue12463] Calling SocketServer.shutdown() when server_forever()
	was not called will hang
In-Reply-To: <1309517198.04.0.392098349691.issue12463@psf.upfronthosting.co.za>
Message-ID: <1312859323.82.0.218610556782.issue12463@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

> Why do you say it "hangs"? It doesn't hang, it just waits for you to
> call serve_forever(): it's not a bug, it's actually a feature.

Okay, for my case, How I should correctly terminate thread?

Conditions:
1. signal may appear at any time
2. thread may become non-alive in any time - either before server_forever (due to exception) or after.

So, after breaking main loop, I should correctly "terminate" thread. I can not say if thread is running. checking isAlive is racy. Even when thread is alive, this is unknown if server_forever was called. Even if serve_forever was not called, we should not rely on calling this ones, because thread may be interrupted by exception before calling serve_forever.

Once again: why not to add patch suggested by Petri Lehtinen ?

----------

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

From report at bugs.python.org  Tue Aug  9 05:29:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Aug 2011 03:29:33 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1312860573.77.0.15072571465.issue2771@psf.upfronthosting.co.za>


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


----------
hgrepos: +52

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

From report at bugs.python.org  Tue Aug  9 05:33:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Aug 2011 03:33:36 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1312860816.62.0.631748537683.issue2771@psf.upfronthosting.co.za>


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


----------
hgrepos:  -52

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

From report at bugs.python.org  Tue Aug  9 05:35:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Aug 2011 03:35:40 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1312860940.79.0.331627245835.issue2771@psf.upfronthosting.co.za>


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


----------
hgrepos: +53

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

From report at bugs.python.org  Tue Aug  9 05:37:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Aug 2011 03:37:02 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1312861022.82.0.330734423234.issue2771@psf.upfronthosting.co.za>


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


----------
hgrepos:  -53

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

From report at bugs.python.org  Tue Aug  9 06:35:10 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 09 Aug 2011 04:35:10 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1312864510.33.0.818451110634.issue12702@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Tue Aug  9 08:42:27 2011
From: report at bugs.python.org (deadshort)
Date: Tue, 09 Aug 2011 06:42:27 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1312872147.59.0.816304709401.issue12701@psf.upfronthosting.co.za>


deadshort <cploomis at gmail.com> added the comment:

Yup, that was it. Something new learnt. Thanks.

Not sure how to have configure spot that clang needs the flag. OK, the configure stanza for gcc is hardly general; maybe trying $(CC) -fwrapv and  keeping the flag if that does not blow up on the pad? But I guess that other ticket takes care of that.

----------

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

From report at bugs.python.org  Tue Aug  9 10:17:31 2011
From: report at bugs.python.org (Aneesh)
Date: Tue, 09 Aug 2011 08:17:31 +0000
Subject: [issue12540] "Restart Shell" command leaves pythonw.exe processes
	running
In-Reply-To: <1310462501.18.0.451373751981.issue12540@psf.upfronthosting.co.za>
Message-ID: <1312877851.35.0.435449958448.issue12540@psf.upfronthosting.co.za>


Aneesh <aneeshbaby at gmail.com> added the comment:

I too retested this on a Windows 7 32 and 64 bit machines and is working fine when the provided PyShell.py is used.

As Terry mentioned, IDLE seems be running better. The process in Task Manager disappears quickly after I close the IDLE.

----------

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

From report at bugs.python.org  Tue Aug  9 12:44:05 2011
From: report at bugs.python.org (Sagiv Malihi)
Date: Tue, 09 Aug 2011 10:44:05 +0000
Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe
	imports
In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za>
Message-ID: <1312886645.64.0.69980572658.issue12680@psf.upfronthosting.co.za>


Sagiv Malihi <sagivmalihi at gmail.com> added the comment:

As I said - it certainly happenes on 3.2 (tested).

@pitrou - what you suggested will not work since the actual import will block on the import lock.
The optimization there is not needed, it's already implemented in __import__.

----------

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

From report at bugs.python.org  Tue Aug  9 13:54:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 11:54:12 +0000
Subject: [issue12714] argparse.ArgumentParser.add_argument() documentation
	error
Message-ID: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The documentation of argparse.ArgumentParser.add_argument() says:

* required - Whether or not the command-line option may be omitted (optionals only).

I believe it should be "options only" instead of "optionals only".

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141812
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.add_argument() documentation error
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  9 14:06:22 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:06:22 +0000
Subject: [issue12715] Add symlink support to shutil functions
Message-ID: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The shutil.copytree() function aknowledges symlinks when given
the symlink=True argument. Other shutil functions should do this
too:

copymode(src, dst, symlinks=True)
   If both src and dst are symlinks, copy the source symlink mode
   to the destination symlink. If only one of them is a symlink,
   dereference it normally.

copystat(src, dst, symlinks=True)
   If both src and dst are symlinks, copy the statinfo of the
   source symlink to the destination symlink. If only one of them
   is a symlink, dereference it normally.

copy(src, dst, symlinks=True)
   If the src argument is a symlink, copy the source symlink
   instead of dereferencing it.

   Problem: What if dst is a symlink to a directory? Should it be
   replaced or should the symlink copied inside that directory?

copy2(src, dst, symlinks=True)
   Like copy(src, dst, symlinks=True), but copy the metadata too.
   The same problem applies.

----------
components: Library (Lib)
messages: 141813
nosy: hynek, petri.lehtinen, tarek
priority: normal
severity: normal
status: open
title: Add symlink support to shutil functions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  9 14:18:26 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:18:26 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1312892306.49.0.293187129414.issue12702@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
dependencies: +Add symlink support to shutil functions

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

From report at bugs.python.org  Tue Aug  9 14:19:06 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:19:06 +0000
Subject: [issue12702] shutil.copytree() should use os.lutimes() to copy the
	metadata of symlinks
In-Reply-To: <1312612968.3.0.232528111658.issue12702@psf.upfronthosting.co.za>
Message-ID: <1312892346.97.0.141100332665.issue12702@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Added issue 12715 as a dependency for this issue, as shutil.copy2(src, dst, symlinks=True) would be an obvious way to implement this.

----------

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

From report at bugs.python.org  Tue Aug  9 14:24:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Aug 2011 12:24:37 +0000
Subject: [issue12714] argparse.ArgumentParser.add_argument() documentation
	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312892677.46.0.266954006444.issue12714@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Nope, optionals is what argparse calls them.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Aug  9 14:35:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:35:09 +0000
Subject: [issue12714] argparse.ArgumentParser.add_argument() documentation
	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312893309.14.0.812915781754.issue12714@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Yes, but required=True/False makes an *option* required or optional. Setting required=False is not allowed with *positionals*:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', required=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/argparse.py", line 1262, in add_argument
    kwargs = self._get_positional_kwargs(*args, **kwargs)
  File "/usr/lib/python2.7/argparse.py", line 1367, in _get_positional_kwargs
    raise TypeError(msg)
TypeError: 'required' is an invalid argument for positionals

I assume that this is the case that is being documented here, so it should read "options only" meaning "not allowed for positionals". Am I correct?

----------

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

From report at bugs.python.org  Tue Aug  9 14:55:51 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:55:51 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1312894551.52.0.559389589704.issue12715@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

We could also have symlinks='require' to have copymode() and copystat() raise an error unless both src and dst are symlinks.

----------

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

From report at bugs.python.org  Tue Aug  9 16:21:32 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 09 Aug 2011 14:21:32 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1312899692.39.0.527082065974.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Additionally copyfile() might be fixed to understand symlinks=True too.

Currently working on a patch for all 5 of them.

----------

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

From report at bugs.python.org  Tue Aug  9 16:24:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 14:24:04 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1312899844.6.0.694904632371.issue12715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Problem: What if dst is a symlink to a directory? Should it be
> replaced or should the symlink copied inside that directory?

Doing what UNIX? cp program does would be best here.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Aug  9 16:41:45 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 14:41:45 +0000
Subject: [issue12716] Reorganize os docs for files/dirs/fds
Message-ID: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Right now many of the os function docs are split up into "Files and directories" and "file descriptor operations". This means, for example, that fchmod() and fchmodat() are in a different section than chmod(). It would make more sense to organize the docs such that functions that do the same thing are right next to each other.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141820
nosy: benjamin.peterson, docs at python
priority: low
severity: normal
status: open
title: Reorganize os docs for files/dirs/fds
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  9 16:50:40 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 14:50:40 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1312901440.45.0.0873680103604.issue12715@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> Doing what UNIX? cp program does would be best here.

$ cp --version
cp (GNU coreutils) 8.5

$ touch file
$ ln -s file link_to_file 
$ mkdir directory
$ ln -s directory link_to_directory
$ cp -a link_to_file link_to_directory
$ ls -l directory
lrwxrwxrwx 1 user user 4 2011-08-09 17:46 link_to_file -> file

So at least cp from GNU coreutils seems to copy the link into the directory, dereferencing the dst link.

----------

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

From report at bugs.python.org  Tue Aug  9 16:58:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 14:58:26 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1312901906.71.0.276677957688.issue1666318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The result should be uniform; either preserve permissions across the
> board, or leave it to the mercy of the caller.
I?m surprised by this report, as the code does a copystat(sourcedir, targetdir) since 2004 (#1048878).  Anyhow, I think the second option would be better.

>  I know there's an enhancement request already open to supply a
> 'func=' kw argument to copytree.
This is now implemented (copy_function argument), but does not help with directories, only with files.  Recently I needed to call copytree and change the permissions of the destination, so I wanted to use a two-line custom copy_function (one line to call shutil.copy, one line for os.chmod), but I hadn?t understood that the custom function was not used for directory creation.  I found out that shutil does a copystat on the created directories behind my back.  So, I think this problem can be solved in a nice and b/w-compatible way by adding a new keyword argument, makedirs_func.  I would like to fix this in stable versions too, but if another core developer argues that it should be considered a new feature, I won?t argue.

----------
nosy: +eric.araujo, georg.brandl, jlgijsbers
title: shutil.copytree doesn't preserve directory permissions -> shutil.copytree doesn't give control over directory permissions
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Tue Aug  9 17:07:33 2011
From: report at bugs.python.org (Mike Garabedian)
Date: Tue, 09 Aug 2011 15:07:33 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
Message-ID: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>


New submission from Mike Garabedian <mgarabed at gmail.com>:

Issue 11089 submitted a patch to 3.2 and 2.7 to address performance concerns with the latest updates to ConfigParser.  In the implementation for 2.7.2, this patch was misapplied in the keys() function on line 573:

  for mapping in self_maps:

should be:

  for mapping in self._maps:

As a result the following raises a NameError:

>>> import ConfigParser
>>> ConfigParser._Chainmap()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\UserDict.py", line 172, in __repr__
    return repr(dict(self.iteritems()))
  File "C:\Python27\lib\UserDict.py", line 110, in iteritems
    for k in self:
  File "C:\Python27\lib\UserDict.py", line 97, in __iter__
    for k in self.keys():
  File "C:\Python27\lib\ConfigParser.py", line 573, in keys
    for mapping in self_maps:
NameError: global name 'self_maps' is not defined

----------
components: Extension Modules
messages: 141823
nosy: georg.brandl, lukasz.langa, mgarabed, rhettinger, skip.montanaro, skrah, vlachoudis
priority: normal
severity: normal
status: open
title: ConfigParser._Chainmap error in 2.7.2
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  9 17:09:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 15:09:23 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
In-Reply-To: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>
Message-ID: <1312902563.88.0.159616932315.issue12717@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for catching this.  I?m baffled that the test suite did not catch that.

----------
assignee:  -> rhettinger
nosy: +eric.araujo
stage:  -> test needed
type: compile error -> behavior

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

From report at bugs.python.org  Tue Aug  9 17:10:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 15:10:39 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1312902639.59.0.292178090842.issue1492704@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have re-read PEP 3151 and think it has no bearing on this bug: the PEP is about adding exception classes that map to errno values, and this report is about a library function that returns a custom exception unrelated to errnos.

I?m willing to review a patch with tests and docs updates for this, or write one myself.

----------
assignee: tarek -> eric.araujo
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Tue Aug  9 17:34:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 15:34:44 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1312904084.82.0.1055364157.issue12711@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+2to3 (2.x to 3.0 conversion tool)
+    the 2to3 conversion tool and `Lib/lib2to3/`_
Hm, given that the tool (IOW the script) is only a few lines, I find the line a bit strange; 2to3 == Lib/lib2to3.  (See also below before you reply to that.)

Personal style thing: I don?t like putting os.sep at the end of directory paths.

+    the benchmarks in the `benchmarks`_ repo
reST protip: For sequences of characters without spaces, you can use just benchmarks_.

+Demos and Tools
+    the scripts in `Tools/`_ and `Tools/demo/`_
The files in* (they are not all scripts).  Sidenote: I think English typography would have us capitalize the definition lines.

+Devguide
+    the `devguide`_
The `Developer?s Guide`_

+Distutils
+    the distutil package in `Lib/distutils/`_
Typo: distutils*.

+Distutils2
+    the packaging package in `Lib/packaging/`_
I always call it ?the packaging module?, to avoid the weird-sounding, potentially confusing ?packaging package?.

+Documentation
+    the documentation in `Doc/`_
Maybe also mention that it?s the source for what?s published at docs.python.org

+Extension Modules
+    C modules in `Modules/`_
I believe some of them are under Lib.  I also don?t know whether imp for example should be Core or Extension Modules.

+IO
+    the IO, `Lib/io.py`_ and `Modules/_io/`_
Maybe ?the I/O system?

+Macintosh
+    the Macintosh operating system
That?s vague.  What about ?Used for bugs specific to Mac OS X??

+Regular Expressions
+    regular expressions, and the `Lib/re.py`_ and `Modules/_sre.c`_ modules
Here again, I?m a bit startled by ?and?: regular expressions == re.py and _sre.c

+Tests
+    the tests in `Lib/test/`_, the unittest and doctest frameworks in
+    `Lib/unittest/`_, `Lib/doctest.py`_

To make people able to answer ?Is this Library or Tests??, I think we could say something like this: Issues and improvements for tests and test frameworks (unittest, doctest, regrtest).

I?m not sure putting emphasis on the paths, like your patch does, is enough to explain for example the difference between Library and Extension Modules.  If I understand the components correctly, their main utility is to let people be auto-assigned/nosied, or to let people find things that interest them or that they can help with, so for example ?Mac-only bug? vs. ?universal bug? is a useful distinction, ?Documentation? lets people with reST skill find things to work on, ?written in Python? vs. ?written in C? is also useful, etc.

If the above analysis seems good, then I propose to update your patch, to be fair, as you put time to do this and now I?m basically saying that no line is good :)

----------

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

From report at bugs.python.org  Tue Aug  9 17:36:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 15:36:22 +0000
Subject: [issue1438480] shutil.move raises OSError when copystat fails
Message-ID: <1312904182.05.0.729749813074.issue1438480@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> In my opinion, anyone wanting to deal with low-level details like
> mtimes and modes is probably not using shutil

As a moderately experienced UNIX user, I would say that file permissions are not low-level details.  I see shutil functions as convenient wrappers to automate looping and calling a function, but I do care about file permissions.

If people are still interested in this modification, I think it would need a backward-compatible change, for example in the form of a new argument ignore_permission_errors, or a more generic onerror callback like rmtree has.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Aug  9 17:46:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Aug 2011 15:46:52 +0000
Subject: [issue12699] strange behaviour of locale.getlocale() -> None, None
In-Reply-To: <1312575791.54.0.599260921956.issue12699@psf.upfronthosting.co.za>
Message-ID: <1312904812.39.0.573915744734.issue12699@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It should be related to #6203.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Aug  9 17:49:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Aug 2011 15:49:13 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1312904953.93.0.65285471287.issue9552@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can this be backported, or just closed?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Aug  9 17:53:51 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 09 Aug 2011 15:53:51 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1312905231.78.0.45014920205.issue6203@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Maybe could it be useful to specify in the documentation that getlocale() is not intended to be used to get information about what is the locale of the system? 

It's not explained currently and thus it's a bit weird to have getlocale returning (None, None) even if you have your locales set.

----------
nosy: +alexis

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

From report at bugs.python.org  Tue Aug  9 18:11:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 16:11:15 +0000
Subject: [issue10745] setup.py install --user option undocumented
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <E1Qqotd-0006og-IM@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1b0b5f644090 by ?ric Araujo in branch '3.2':
Add documentation for PEP 370 features in distutils (#10745).
http://hg.python.org/cpython/rev/1b0b5f644090

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

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

From report at bugs.python.org  Tue Aug  9 18:11:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 16:11:15 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <E1Qqotd-0006og-Ho@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 74179a79d673 by ?ric Araujo in branch '3.2':
Improve documentation for PEP 370 support in site module (#8617).
http://hg.python.org/cpython/rev/74179a79d673

New changeset d354802a637d by ?ric Araujo in branch 'default':
Merge doc changes from 3.2 (#8617, #10745).
http://hg.python.org/cpython/rev/d354802a637d

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

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

From report at bugs.python.org  Tue Aug  9 18:42:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 16:42:52 +0000
Subject: [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1312908172.06.0.602420849607.issue12716@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Also, symbolic constants should be close to the functions they are used in. For example, open() flags shouldn't be in their own section.

----------

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

From report at bugs.python.org  Tue Aug  9 19:25:41 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGA?=)
Date: Tue, 09 Aug 2011 17:25:41 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
Message-ID: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>


New submission from ????????? <alexandr.s.rus at gmail.com>:

At line 377 __import__ function assing to class variable importer.

__import__ get module name as first argument, but when we use self.importer at line 391 (http://hg.python.org/cpython/file/10f20ad2fbb6/Lib/logging/config.py#l391) we give class instance(self) as the first argument. Not module name

As result raised ImportError with message: "__import__() argument 1 must be string, not DictConfigurator" or "__import__() argument 1 must be string, not BaseConfigurator"

----------
components: Library (Lib)
files: config_importer_patch.diff
keywords: patch
messages: 141834
nosy: Alexandr
priority: normal
severity: normal
status: open
title: Logical mistake of importer method in logging.config.BaseConfigurator
versions: Python 2.7
Added file: http://bugs.python.org/file22867/config_importer_patch.diff

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

From report at bugs.python.org  Tue Aug  9 19:42:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 17:42:50 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312911770.36.0.401395515597.issue12718@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> vinay.sajip
nosy: +vinay.sajip

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

From report at bugs.python.org  Tue Aug  9 20:20:51 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 18:20:51 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1312914051.1.0.308214102759.issue12613@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Tue Aug  9 20:33:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Aug 2011 18:33:08 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
In-Reply-To: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>
Message-ID: <1312914788.93.0.0804114030754.issue12717@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks, I'll fix that shortly.

----------
priority: normal -> high

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

From report at bugs.python.org  Tue Aug  9 20:44:21 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 18:44:21 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1312915461.74.0.221109702221.issue12613@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

A smaller snippet to reproduce:

    izip().next()

This gets converted to:

    next(izip())

It seems to me that the pattern of the itertools fixer doesn't match to izip().something(), and thus this is skipped.

----------

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

From report at bugs.python.org  Tue Aug  9 21:07:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 19:07:27 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
In-Reply-To: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>
Message-ID: <E1Qqre7-0006ek-Mt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7d5a37ce42d5 by Raymond Hettinger in branch '2.7':
Issue 12717: Fix-up an earlier backport in ConfigParser.
http://hg.python.org/cpython/rev/7d5a37ce42d5

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

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

From report at bugs.python.org  Tue Aug  9 21:10:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Aug 2011 19:10:05 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
In-Reply-To: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>
Message-ID: <1312917005.5.0.901922690544.issue12717@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Fixed.  Thanks for the report.

?ric, the test suite didn't catch this because the error wasn't user visible -- the chainmap is only used internally and only __getitem__ was needed.

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

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

From report at bugs.python.org  Tue Aug  9 21:17:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Aug 2011 19:17:00 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1312800380.17.0.493303569251.issue10087@psf.upfronthosting.co.za>
Message-ID: <20110809211805.012d6821@msiwind>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le Mon, 08 Aug 2011 10:46:20 +0000,
Senthil Kumaran <report at bugs.python.org> a ?crit :
> 
> Antoine - I was specifically interested to know if
> sys.stdout.buffer.write as in the patch was good(/proper) way to go
> forward writing the bytes?

Yes, it is.

----------

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

From report at bugs.python.org  Tue Aug  9 22:16:30 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Tue, 09 Aug 2011 20:16:30 +0000
Subject: [issue12719] Direct access to tp_dict can lead to stale attributes
Message-ID: <1312920990.32.0.154264120854.issue12719@psf.upfronthosting.co.za>


New submission from Martin von Gagern <Martin.vGagern at gmx.net>:

The attached C extension provides a way to manually set an element in the dict of an extension type. As the test case exposes, this can result in a discrepancy between cls.__dict__['key'] and cls.key.

Please tell me up front if my extension simply does something explixitely forbidden, and point me at the documentation saying so.
http://docs.python.org/py3k/c-api/typeobj.html#PyTypeObject.tp_dict at least doesn't appear to explicitely forbid my approach, even if it probably is not the preferred way.

If you consider what I'm doing to be really evil, you might want to ban that practice more clearly, by adding a suitable note to the documentation of the tp_dict member.

In case you cannot reproduce, running the attached testcase script with "test" as its sole command line argument, I get the following lines, among others:

Traceback (most recent call last):
  File ".../setDictTest.py", line 10, in test1
    self.assertEqual(setDictCls.__dict__['key'], setDictCls.key)
AssertionError: 'bar' != 'foo'

I assume that the attribute-style setDictCls.key access will somehow cache its result, thus missing the modification to the underlying dict. Just a guess, though.

I've had this issue involved in segmentation faults, where the stale object had already been finalized. But as the code involved there might have been broken in other ways as well, I'll not classify this as type "crash" but only as "behaviour".

----------
components: Extension Modules
files: setup.py
messages: 141840
nosy: gagern
priority: normal
severity: normal
status: open
title: Direct access to tp_dict can lead to stale attributes
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22868/setup.py

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

From report at bugs.python.org  Tue Aug  9 22:22:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 20:22:50 +0000
Subject: [issue12719] Direct access to tp_dict can lead to stale attributes
In-Reply-To: <1312920990.32.0.154264120854.issue12719@psf.upfronthosting.co.za>
Message-ID: <1312921370.67.0.0508422436594.issue12719@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is forbidden, and I agree there should be a doc note. See #1878.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +benjamin.peterson, docs at python

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

From report at bugs.python.org  Tue Aug  9 22:24:56 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 20:24:56 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
Message-ID: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

These allow extra metadata to be attached to files.

----------
components: Extension Modules
files: xattrs.patch
keywords: patch
messages: 141842
nosy: benjamin.peterson
priority: normal
severity: normal
stage: patch review
status: open
title: Expose linux extended filesystem attributes
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22869/xattrs.patch

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

From report at bugs.python.org  Tue Aug  9 23:04:21 2011
From: report at bugs.python.org (Mike Garabedian)
Date: Tue, 09 Aug 2011 21:04:21 +0000
Subject: [issue12717] ConfigParser._Chainmap error in 2.7.2
In-Reply-To: <1312902453.45.0.87676822882.issue12717@psf.upfronthosting.co.za>
Message-ID: <1312923861.54.0.363362835885.issue12717@psf.upfronthosting.co.za>


Mike Garabedian <mgarabed at gmail.com> added the comment:

Happy to help!

Raymond - I came across this issue while reviewing notes from your OSCON Advanced Python talk - thanks for the great tutorial!

----------

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

From report at bugs.python.org  Tue Aug  9 23:17:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 21:17:24 +0000
Subject: [issue12575] add a AST validator
In-Reply-To: <1310836208.56.0.617429580425.issue12575@psf.upfronthosting.co.za>
Message-ID: <E1Qqtfv-0001qo-CS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4090dfdf91a4 by Benjamin Peterson in branch 'default':
add a AST validator (closes #12575)
http://hg.python.org/cpython/rev/4090dfdf91a4

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

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

From report at bugs.python.org  Tue Aug  9 23:17:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 21:17:25 +0000
Subject: [issue12719] Direct access to tp_dict can lead to stale attributes
In-Reply-To: <1312920990.32.0.154264120854.issue12719@psf.upfronthosting.co.za>
Message-ID: <E1Qqtfv-0001qo-BW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6ef65516fd7a by Benjamin Peterson in branch '3.2':
note mutating tp_dict is bad (closes #12719)
http://hg.python.org/cpython/rev/6ef65516fd7a

New changeset 69df5a8d164e by Benjamin Peterson in branch 'default':
merge 3.2 (#12719)
http://hg.python.org/cpython/rev/69df5a8d164e

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

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

From report at bugs.python.org  Wed Aug 10 00:50:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 09 Aug 2011 22:50:23 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1312930223.79.0.743111063791.issue10588@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/issue10588>
_______________________________________

From report at bugs.python.org  Wed Aug 10 01:21:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Aug 2011 23:21:45 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1312932105.64.0.50656839359.issue12711@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a new patch.
I addressed most of your comments.
AFAICT there are no extension modules in Lib.  All the C modules are in Modules, and if they also have a Python "frontend", that's in Lib.  I think the point of having Extension Modules and Library is to distinguish between C modules and Python modules.

I split the "Tests" component in two different entries:
  1) about our tests, regrtest and test/support.py;
  2) unittest/doctest;
I think the "Tests" component applies to both, and for unittest/doctest it can be used together with "Library".

Listing the paths is both good for people that are submitting ("the error comes from this module"), and for people fixing it ("this component is selected, I should look in that module").

----------
Added file: http://bugs.python.org/file22870/issue12711-2.diff

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

From report at bugs.python.org  Wed Aug 10 01:52:34 2011
From: report at bugs.python.org (Alan Justino)
Date: Tue, 09 Aug 2011 23:52:34 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1312933954.88.0.656760862514.issue9528@psf.upfronthosting.co.za>


Changes by Alan Justino <alan.justino at yahoo.com.br>:


----------
nosy: +alanjds
versions: +Python 2.7

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

From report at bugs.python.org  Wed Aug 10 02:24:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Aug 2011 00:24:03 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1312935843.22.0.679411239708.issue6203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This issue is about the fact that it doesn't return (None, None).  We should probably decide what we are going to do about that before changing the docs if they need it.

----------

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

From report at bugs.python.org  Wed Aug 10 03:14:09 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Aug 2011 01:14:09 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1312938849.69.0.886398637957.issue12608@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Officially fixed by #12575.

----------

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

From report at bugs.python.org  Wed Aug 10 05:19:45 2011
From: report at bugs.python.org (Lenard Lindstrom)
Date: Wed, 10 Aug 2011 03:19:45 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1312946385.08.0.808125576327.issue10181@psf.upfronthosting.co.za>


Changes by Lenard Lindstrom <len-l at telus.net>:


----------
nosy:  -kermode

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

From report at bugs.python.org  Wed Aug 10 08:12:07 2011
From: report at bugs.python.org (Alex Leon)
Date: Wed, 10 Aug 2011 06:12:07 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312956727.3.0.724015016748.issue12541@psf.upfronthosting.co.za>


Alex Leon <aeleon at gmail.com> added the comment:

It could have a 2 phase regex match. We match the first one, and if it fails, match the second and produce a warning. 

I think producing a warning is a good idea, as it allows the programmer to know that the implementation of basic auth they are trying to connect to is broken, and might help with future connection attempts. Also there are currently no warnings produced by python if it fails to parse the auth header, and its hard for a developer to know why.

----------

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

From report at bugs.python.org  Wed Aug 10 09:49:01 2011
From: report at bugs.python.org (shevegen)
Date: Wed, 10 Aug 2011 07:49:01 +0000
Subject: [issue12541] Accepting Badly formed headers in urllib HTTPBasicAuth
In-Reply-To: <1310478499.65.0.178767259424.issue12541@psf.upfronthosting.co.za>
Message-ID: <1312962541.75.0.7170924335.issue12541@psf.upfronthosting.co.za>


shevegen <shevegen at linuxmail.org> added the comment:

I think a warning would be quite nice to have.

----------
nosy: +shevegen

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

From report at bugs.python.org  Wed Aug 10 10:22:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 08:22:17 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1312964537.08.0.840651588291.issue10744@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/issue10744>
_______________________________________

From report at bugs.python.org  Wed Aug 10 10:27:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 08:27:33 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312964853.42.0.238682164922.issue12718@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It works as expected for me:

vinay at eta-jaunty:~/projects/python/2.7$ python2.7
Python 2.7.2+ (2.7:7d5a37ce42d5, Aug 10 2011, 09:20:30) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.config
[62163 refs]
>>> c = logging.config.BaseConfigurator({})
[62173 refs]
>>> c.importer('pickle')
<module 'pickle' from '/home/vinay/projects/python/2.7/Lib/pickle.py'>
[65944 refs]
>>> c.importer
<built-in function __import__>
[65944 refs]
>>> c.__class__.importer
<built-in function __import__>
[65944 refs]
>>> c.__class__.importer('marshal')
<module 'marshal' (built-in)>
[65944 refs]
>>> 

Can you provide an example script which demonstrates failure? I'll mark this as invalid and pending, and close soon if no further information is forthcoming.

----------
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Wed Aug 10 12:09:11 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 10 Aug 2011 10:09:11 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
Message-ID: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

While working on #12715 I noticed that the tests of shutil aren't exactly consistent concerning reading and writing files.

There were no less than two function to read files (one of them not being used at all) and two methods to write them. Additionally lots of code 
simply reads/writes by hand.

I've unified the functionality in module functions read_file and write_file which can be told to open the file as binaries.

----------
components: Tests
files: cleanup-test_shutil.diff
keywords: patch
messages: 141856
nosy: hynek
priority: normal
severity: normal
status: open
title: Chaotic use of helper functions in test_shutil for reading and writing files
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22871/cleanup-test_shutil.diff

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

From report at bugs.python.org  Wed Aug 10 13:13:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 11:13:13 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312974793.37.0.0541457407249.issue12687@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
hgrepos: +58
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Wed Aug 10 13:13:46 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 11:13:46 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312974826.14.0.121643804671.issue12687@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22872/6394321ef4ec.diff

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

From report at bugs.python.org  Wed Aug 10 13:19:44 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGA?=)
Date: Wed, 10 Aug 2011 11:19:44 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312975184.42.0.183873797207.issue12718@psf.upfronthosting.co.za>


????????? <alexandr.s.rus at gmail.com> added the comment:

Install rpdb2 or winpdb for you python. And install django to you python path.
Create empty djnago-project:
django-admin createproject bbbtest 

Add line LOGGING_CONFIG = 'logging.config.dictConfig' to setting.py for use python logging.config for logging.

Execute rpdb2 ./manage.py help

And you get traceback:


Traceback (most recent call last):
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/rpdb2.py", line 14499, in <module>
    ret = rpdb2.main()
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/rpdb2.py", line 14470, in main
    StartServer(_rpdb2_args, fchdir, _rpdb2_pwd, fAllowUnencrypted, fAllowRemote, secret)
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/rpdb2.py", line 14220, in StartServer
    imp.load_source('__main__', _path)    
  File "/tmp/bbbtest/manage.py", line 11, in <module>
    execute_manager(settings)
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/core/management/__init__.py", line 368, in execute
    sys.stderr.write(self.main_help_text() + '\n')
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/core/management/__init__.py", line 239, in main_help_text
    commands = get_commands().keys()
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/core/management/__init__.py", line 101, in get_commands
    apps = settings.INSTALLED_APPS
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/utils/functional.py", line 276, in __getattr__
    self._setup()
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup
    self._wrapped = Settings(settings_module)
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/site-packages/django/conf/__init__.py", line 139, in __init__
    logging_config_func(self.LOGGING)
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/logging/config.py", line 782, in dictConfig
    dictConfigClass(config).configure()
  File "/home/alex/.pythonbrew/pythons/Python-2.7.1/lib/python2.7/logging/config.py", line 581, in configure
    '%r: %s' % (name, e))
ValueError: Unable to configure handler 'mail_admins': __import__() argument 1 must be string, not DictConfigurator

----------
status: pending -> open

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

From report at bugs.python.org  Wed Aug 10 13:43:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 11:43:36 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1312976616.46.0.124447686258.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22873/78fb1181787a.diff

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

From report at bugs.python.org  Wed Aug 10 13:46:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 11:46:43 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1312976803.02.0.732791234967.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I thought it might be productive to switch to documentation/test driven
development for PEP-3118 in general. So I updated the documentation,
trying to spell out the responsibilities of both exporter and consumer
as clearly as possible.

In order to have a PEP-3118 reference implementation, I wrote
Modules/_testbuffer.c and Lib/test/test_buffer.py. The test module
contains an ndarray object (independent from NumPy's ndarray) with
these features:

  o Full base object capabilities, including responding to flag
    specific requests.

  o Full re-exporter capability: The object obtains a buffer from
    another exporter and poses as a base object.

  o Optional capability to change layout while buffers are exported.

  o Full support for arbitrary format strings using the struct
    module.

  o Fortran style arrays.

  o Arbitrary multidimensional structures, including offsets and
    negative strides.

  o Support for converting arrays to suboffset representations.

  o Support for multidimensional indexing, slicing and tolist().

  o Optional support for testing against NumPy.


In memoryobject.c I only fixed the buffer release issues that came up.
Before proceeding with allocating private arrays for each memoryview,
it would be great to have agreement on the revised documentation and a
couple of other issues.

Documentation
-------------

I'll highlight some changes here:

  1) view->obj: Must be a new reference to the provider if the buffer
     is obtained via getbuffer(), otherwise NULL. In case of failure
     the field MUST be set to NULL (was: undefined).

     So, logically this should be seen the same way as returning
     a new reference from a standard Python function.

  2) view->buf: This can (and _does_ for Numpy arrays) point to
     any location in the underlying memory block. If a consumer
     doesn't request one of the simple or contiguous buffers,
     all bets are off.

  3) view->len: Make it clear that the PEP defines it as
     product(shape) * itemsize.

  4) Ownership for shape, strides, internal: read-only for the
     consumer.

  5) Flag explanations: The new section puts emphasis on which fields
     a consumer can expect in response to a buffer request, starting
     with the fields that will always be set.

  6) Rule for writable/read-only requests. Only raise if the
     buffer is read-only and the request is 'writable'. This
     seems to be the most practical solution.

  7) Add NumPy-style and PIL-style sections to make clear what
     a consumer must be able to handle if complicated structures
     are requested (thanks Pauli Virtanen for clarifying what
     valid NumPy arrays may look like).


What I would like to spell out clearly:

  8) A PEP-3118 compliant provider MUST always be able to respond
     to a PyBUF_FULL_RO request (i.e. fill in shape AND strides).
     ctypes doesn't currently do that, but could be fixed easily.

     This is easy to implement for the exporter (see how
     PyBuffer_FillInfo() does it in a few lines).


Memoryview
----------

  8) Add PyMemoryView_FromBytes(). This could potentially replace
     PyMemoryView_FromBuffer().

  9) I've come to think that memoryviews should only be created
     from PyBUF_FULL_RO requests (this also automatically succeeds
     if an object is writable, see above).

     One reason is that we don't constantly have to check for
     the presence of shape and strides and format (unless ndim = 0).

     Currently it is possible to create any kind of view via
     PyMemoryView_FromBuffer(). It would be possible to deprecate
     it or make it a rule that the buffer argument must have full
     information.

  10) NumPy has a limit of ndim = 64. It would be possible to
      use that limit as well and make shape, strides and
      suboffsets static arrays of size 64. Perhaps this is a bit
      wasteful, it depends on how many views are typically
      created.

  11) test_buffer.py contains an example (see: test_memoryview_release())
      that Antoine's test case will not work if a re-exporter is
      involved. Should we leave that or fix it, too?



My apologies for the long list, but it'll be easier to proceed if
some rules are written in stone. :)

----------

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

From report at bugs.python.org  Wed Aug 10 14:31:53 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 12:31:53 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1312979513.92.0.869363110126.issue9990@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This should be fixed with the ManagedBuffer implementation from #10181.

----------
dependencies: +Problems with Py_buffer management in memoryobject.c (and elsewhere?)
nosy: +skrah

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

From report at bugs.python.org  Wed Aug 10 14:39:22 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 12:39:22 +0000
Subject: [issue8305] memoview[0] creates an invalid view if ndim != 1
In-Reply-To: <1270308282.65.0.542260907353.issue8305@psf.upfronthosting.co.za>
Message-ID: <1312979962.78.0.384997605282.issue8305@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The crash is fixed in the features/pep-3118 repo:

>>> from numpy import array
>>> y=array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11])
>>> y.shape = 3,4
>>> view=memoryview(y)
>>> view2 = view[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: multi-dimensional sub-views are not implemented
[182251 refs]

----------
dependencies: +Problems with Py_buffer management in memoryobject.c (and elsewhere?)
nosy: +skrah

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

From report at bugs.python.org  Wed Aug 10 14:43:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 12:43:05 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1312980185.7.0.0515749045491.issue7433@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This should be fixed in features/pep-3118.

----------
dependencies: +Problems with Py_buffer management in memoryobject.c (and elsewhere?)
nosy: +skrah

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

From report at bugs.python.org  Wed Aug 10 14:43:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Aug 2011 12:43:43 +0000
Subject: [issue10746] ctypes c_long & c_bool have incorrect PEP-3118 type codes
In-Reply-To: <1292888248.06.0.197043159654.issue10746@psf.upfronthosting.co.za>
Message-ID: <1312980223.51.0.253606050198.issue10746@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/issue10746>
_______________________________________

From report at bugs.python.org  Wed Aug 10 15:53:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 10 Aug 2011 13:53:17 +0000
Subject: [issue12722] Link to heapq source from docs.python.org not working
Message-ID: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

http://mail.python.org/pipermail/docs/2011-August/005336.html

I see that it is a problem with viewvc software which is not handling
unicode text in HTML markup properly. Probably we can reference the
text version of that module till the viewvc bug is fixed.

----------
assignee: docs at python
components: Documentation
messages: 141862
nosy: docs at python, orsenthil
priority: normal
severity: normal
status: open
title: Link to heapq source from docs.python.org not working

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

From report at bugs.python.org  Wed Aug 10 15:55:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Aug 2011 13:55:22 +0000
Subject: [issue12722] Link to heapq source from docs.python.org not working
In-Reply-To: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>
Message-ID: <E1Qr9Fg-0002Rl-Ti@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9f482b957d77 by Senthil Kumaran in branch '2.7':
Fix closes Issue12722  - link heapq source in the text format in the documentation.
http://hg.python.org/cpython/rev/9f482b957d77

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

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

From report at bugs.python.org  Wed Aug 10 16:33:47 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 10 Aug 2011 14:33:47 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1312986827.01.0.858279070014.issue1492704@psf.upfronthosting.co.za>


Gennadiy Zlobin <gennad.zlobin at gmail.com> added the comment:

This patch should fix the issue

----------
nosy: +gennad
Added file: http://bugs.python.org/file22874/1492704.diff

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

From report at bugs.python.org  Wed Aug 10 16:38:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Aug 2011 14:38:41 +0000
Subject: [issue12714] argparse.ArgumentParser.add_argument() documentation
	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312987121.12.0.191284721112.issue12714@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"optionals only" means the same thing as "options only", but 'optionals' is what argparse calls them (as contrasted with positionals).

'optionals' is only used two places in the doc and isn't defined, but its meaning is implied by the section heading ("optional arguments").

----------

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

From report at bugs.python.org  Wed Aug 10 16:49:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Aug 2011 14:49:44 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312987784.79.0.621074084061.issue12718@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Vinay: you want to mark importer as a static method anyway, otherwise it won't work with pypy.  I don't know why this would show up on CPython, though.

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

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

From report at bugs.python.org  Wed Aug 10 17:23:10 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 10 Aug 2011 15:23:10 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1312989790.62.0.673360874929.issue12608@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I have verified that the code checked in for issue12575 keep the test case from this issue from crashing the interpreter:

[meadori at motherbrain cpython]$ ./python test.py 
Traceback (most recent call last):
  File "test.py", line 14, in <module>
    compiled = compile(exprAst, "<foo>", "single")
ValueError: empty body on FunctionDef

Do we have any intent on fixing this crasher for 3.2 and 2.7?

----------

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

From report at bugs.python.org  Wed Aug 10 17:23:11 2011
From: report at bugs.python.org (Matthew Hemke)
Date: Wed, 10 Aug 2011 15:23:11 +0000
Subject: [issue12723] tkSimpleDialog.askstring shouldn't allow empty string
	input
Message-ID: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>


New submission from Matthew Hemke <mghemke at gmail.com>:

tkSimpleDialog.askstring allows empty input. The attached patch adds validation to the input to ensure it is not empty.

----------
components: Tkinter
files: askstring.patch
keywords: patch
messages: 141868
nosy: rabbidous
priority: normal
severity: normal
status: open
title: tkSimpleDialog.askstring shouldn't allow empty string input
type: feature request
Added file: http://bugs.python.org/file22875/askstring.patch

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

From report at bugs.python.org  Wed Aug 10 17:23:26 2011
From: report at bugs.python.org (Matthew Hemke)
Date: Wed, 10 Aug 2011 15:23:26 +0000
Subject: [issue12723] tkSimpleDialog.askstring shouldn't allow empty string
	input
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1312989806.48.0.967149562694.issue12723@psf.upfronthosting.co.za>


Changes by Matthew Hemke <mghemke at gmail.com>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Wed Aug 10 17:30:07 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Aug 2011 15:30:07 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1312989790.62.0.673360874929.issue12608@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-FnDZeTTZbHG-taEL3rFUmBik8Ze=gESiBqPPJNbp2SQ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/8/10 Meador Inge <report at bugs.python.org>:
>
> Meador Inge <meadori at gmail.com> added the comment:
>
> I have verified that the code checked in for issue12575 keep the test case from this issue from crashing the interpreter:
>
> [meadori at motherbrain cpython]$ ./python test.py
> Traceback (most recent call last):
> ?File "test.py", line 14, in <module>
> ? ?compiled = compile(exprAst, "<foo>", "single")
> ValueError: empty body on FunctionDef
>
> Do we have any intent on fixing this crasher for 3.2 and 2.7?

Probably not. Everything is rather broken before 3.3 now.

----------

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

From report at bugs.python.org  Wed Aug 10 17:33:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 15:33:06 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312990386.53.0.395153470579.issue12718@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@?????????: It still works for me without winpdb/rpdb2, so you should probably report this there. Can you confirm that it works as expected when you do "python manage.py help"?

vinay at eta-natty:/tmp$ virtualenv -p python2.7 bbbenv
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in bbbenv/bin/python2.7
Also creating executable in bbbenv/bin/python
Installing setuptools............................done.
Installing pip...............done.
vinay at eta-natty:/tmp$ source bbbenv/bin/activate
(bbbenv)vinay at eta-natty:/tmp$ easy_install django
Searching for django
Reading http://pypi.python.org/simple/django/
Reading http://www.djangoproject.com/
Best match: Django 1.3
Downloading http://media.djangoproject.com/releases/1.3/Django-1.3.tar.gz
Processing Django-1.3.tar.gz

[output snipped]

Installed /tmp/bbbenv/lib/python2.7/site-packages/Django-1.3-py2.7.egg
Processing dependencies for django
Finished processing dependencies for django
(bbbenv)vinay at eta-natty:/tmp$ django-admin.py startproject bbbtest
(bbbenv)vinay at eta-natty:/tmp$ cd bbbtest
(bbbenv)vinay at eta-natty:/tmp/bbbtest$ python manage.py help
Usage: manage.py subcommand [options] [args]

[output snipped]

(bbbenv)vinay at eta-natty:/tmp/bbbtest$ grep LOGGING_CONFIG settings.py
LOGGING_CONFIG = 'logging.config.dictConfig'

@David: Marking as a static method simply ensures that the attribute is returned as a function, which is already happening:

>>> class C:
...     @staticmethod
...     def func(x): print x
...     def meth(self, x): print x
... 
>>> C.func, C.meth, C().func, C().meth
(<function func at 0xb783ddf4>, <unbound method C.meth>, <function func at 0xb783ddf4>, <bound method C.meth of <__main__.C instance at 0xb75cafcc>>)
>>> import logging.config
>>> DC = logging.config.DictConfigurator
>>> DC.importer, DC.configure, DC({}).importer, DC({}).configure
(<built-in function __import__>, <unbound method DictConfigurator.configure>, <built-in function __import__>, <bound method DictConfigurator.configure of <logging.config.DictConfigurator object at 0xb75b520c>>)

I have no objection to changing things to support PyPy, but what's the idiom? I don't believe importer = staticmethod(__import__) will work here, as it just creates a staticmethod object (which isn't callable).

----------
status: open -> pending

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

From report at bugs.python.org  Wed Aug 10 17:47:12 2011
From: report at bugs.python.org (deadshort)
Date: Wed, 10 Aug 2011 15:47:12 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1312991232.0.0.11640751093.issue1621@psf.upfronthosting.co.za>


deadshort <cploomis at gmail.com> added the comment:

Since this is still dribbling along I'll point out intobject.c:int_pow() and:

        prev = ix;              /* Save value for overflow check */
        if (iw & 1) {
            ix = ix*temp;
            if (temp == 0)
                break; /* Avoid ix / 0 */
            if (ix / temp != prev) {
                return PyLong_Type.tp_as_number->nb_power(
                    (PyObject *)v,
                    (PyObject *)w,
                    (PyObject *)z);
            }
        }

which I misclassified in http://bugs.python.org/issue12701

----------
nosy: +deadshort

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

From report at bugs.python.org  Wed Aug 10 18:05:49 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Wed, 10 Aug 2011 16:05:49 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1312935843.22.0.679411239708.issue6203@psf.upfronthosting.co.za>
Message-ID: <4E42AC1E.2060302@notmyidea.org>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

I see two different things here:

1) the fact that getlocale() doesn't return (None, None) on some python 
versions
2) the fact that having it returning (None, None) by default is a bit 
misleading as users may think that getlocale() is tied to environment 
variables. That's what was at the origin of #12699

My last remark is about the second bit. Maybe should I start a new issue 
for this?

----------
title: 3.x locale does not default to C,	contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior

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

From report at bugs.python.org  Wed Aug 10 18:09:02 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 16:09:02 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312992542.78.0.974012662683.issue12718@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

BTW I just tested on PyPy. The following program:

import logging.config
import sys

d = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'level': 'DEBUG',
            'class': 'logging.StreamHandler',
            'stream': 'ext://sys.stdout',
        }
    },
    'root': {
        'level': 'DEBUG',
    }
}

logging.config.dictConfig(d)
logging.debug('%s', sys.version)

prints:

vinay at eta-natty:~/projects/scratch$ python dctest.py
DEBUG:root:2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2]
vinay at eta-natty:~/projects/scratch$ ~/pypy-c-jit-43780-b590cf6de419-linux/bin/pypy dctest.py 
DEBUG:root:2.7.1 (b590cf6de419, Apr 30 2011, 02:00:38)
[PyPy 1.5.0-alpha0 with GCC 4.4.3]

----------
status: pending -> open

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

From report at bugs.python.org  Wed Aug 10 18:09:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 16:09:12 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312992552.2.0.287658960926.issue12718@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: open -> pending

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

From report at bugs.python.org  Wed Aug 10 18:11:34 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 16:11:34 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1312992694.59.0.0114856877784.issue12687@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file22876/fac0421cb7b2.diff

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

From report at bugs.python.org  Wed Aug 10 18:38:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Aug 2011 16:38:24 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1312994304.37.0.706527457656.issue9528@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@alanjds: Why do you add Python 2.7 version to this issue?

----------

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

From report at bugs.python.org  Wed Aug 10 19:18:35 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Aug 2011 17:18:35 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1312996715.75.0.811647110651.issue9528@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

@Victor it doesn't really matter why since it is an incorrect classification. This issue in no way involves Python 2.7 since we will not backport any modules to Python 2.7.

----------
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Aug 10 19:25:08 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 10 Aug 2011 17:25:08 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1312997108.4.0.452283251083.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

JFTR, my implementation is ready, but I can't/don't want to start writing tests, as long as #12721 is open.

----------

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

From report at bugs.python.org  Wed Aug 10 19:29:50 2011
From: report at bugs.python.org (Alan Justino)
Date: Wed, 10 Aug 2011 17:29:50 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1312997390.95.0.573390430663.issue9528@psf.upfronthosting.co.za>


Alan Justino <alan.justino at yahoo.com.br> added the comment:

@haypo: Because it affects version 2.7 too.

@Victor: Even since we will not backport any modules to Python 2.7, is not worth to sign that this affects it too? Even wontfix or rejected, it affects, does not?

Have I made something wrong? Sorry to be so newbie about this.

Long explanation:

Is not easy to change/extend datetime, as stated by several other before. Searching the bugs for 2.x only does not shows that someone else already care about this issue AND that it exists at 2.x too.

I am getting a hard time trying to do some BDD with c-based datetime because I cannot mock it easily to force datetime.datetime.now() to return a desired value, making almost impossible to test time-based code, like the accounting system that I am refactoring right now.

Another solution would be to "open" C-based classes to allow modification, that is not planned to be into near future Python versions AFAIK.

I came to fill a new bug with all this, but then found this one that is already mature enough, with even BDFL and python-dev opinion.

Then my (maybe pointless) plan was to gather more arguments favor to change into python-based datetime, but you replied first...

----------

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

From report at bugs.python.org  Wed Aug 10 19:31:44 2011
From: report at bugs.python.org (Alan Justino)
Date: Wed, 10 Aug 2011 17:31:44 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1312997504.87.0.392041364158.issue9528@psf.upfronthosting.co.za>


Alan Justino <alan.justino at yahoo.com.br> added the comment:

(noticed a typo at the start of my last msg: @Victor should be @brett.cannon)

----------

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

From report at bugs.python.org  Wed Aug 10 19:36:21 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGA?=)
Date: Wed, 10 Aug 2011 17:36:21 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1312997781.25.0.918814236691.issue12718@psf.upfronthosting.co.za>


????????? <alexandr.s.rus at gmail.com> added the comment:

As I understand, you created importer as a class attribute, so we can opportunity set import function to importer when inheritance new class from BaseConfigurator(# We might want to use a different one, e.g. importlib)? As example importer = import_module # from importlib.

>It still works for me without winpdb/rpdb2, so you should probably report this there. Can you confirm that it works as expected when you do "python manage.py help"?

You true. rpdb2 create wrapper for __import__ and self.importer not work such __builtin__ __import__

ps. Sorry for bad english, it is't primary language.

----------
status: pending -> open
Added file: http://bugs.python.org/file22877/test_logging.py

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

From report at bugs.python.org  Wed Aug 10 19:39:52 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 10 Aug 2011 17:39:52 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1312997390.95.0.573390430663.issue9528@psf.upfronthosting.co.za>
Message-ID: <4E42C262.5020608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alan Justino wrote:
> 
> I am getting a hard time trying to do some BDD with c-based datetime because I cannot mock it easily to force datetime.datetime.now() to return a desired value, making almost impossible to test time-based code, like the accounting system that I am refactoring right now.

It's usually better to use a central helper get_current_time() in
the application, than to use datetime.now() and others
directly.

----------

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

From report at bugs.python.org  Wed Aug 10 19:46:12 2011
From: report at bugs.python.org (Matt M)
Date: Wed, 10 Aug 2011 17:46:12 +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: <1312998372.26.0.636093254506.issue8713@psf.upfronthosting.co.za>


Changes by Matt M <numbernine.python at complexnumber.net>:


----------
nosy: +numbernine

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

From report at bugs.python.org  Wed Aug 10 20:59:31 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 10 Aug 2011 18:59:31 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1313002771.62.0.583550023881.issue10588@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

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

From report at bugs.python.org  Wed Aug 10 21:19:38 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 19:19:38 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1313003978.92.0.73449694031.issue12718@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Okay, the problem occurs because builtin functions and Python functions are handled differently. This is how you need to set a Python importer:

vinay at eta-natty:~$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.config
>>> BC = logging.config.BaseConfigurator
>>> from importlib import import_module
>>> class CC(BC):
...     importer = staticmethod(import_module)
... 
>>> CC.importer
<function import_module at 0xb746db54>
>>> CC.importer('pickle')
<module 'pickle' from '/usr/lib/python2.7/pickle.pyc'>
>>> CC({}).importer('pickle')
<module 'pickle' from '/usr/lib/python2.7/pickle.pyc'>

I will update the documentation to indicate this, but I don't think a change to logging.config is needed.

----------
status: open -> pending

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

From report at bugs.python.org  Wed Aug 10 21:59:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 10 Aug 2011 19:59:05 +0000
Subject: [issue12608] crash in PyAST_Compile when running Python code
In-Reply-To: <1311340407.01.0.0385021056908.issue12608@psf.upfronthosting.co.za>
Message-ID: <1313006345.71.0.250856154807.issue12608@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

OK, I am marking this as fixed then.  If someone decides to fix this in 3.2 or 3.7, then they can reopen the issue.

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

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

From report at bugs.python.org  Wed Aug 10 22:05:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 10 Aug 2011 20:05:23 +0000
Subject: [issue4841] io's close() not handling errors correctly
In-Reply-To: <1231151389.71.0.297079127324.issue4841@psf.upfronthosting.co.za>
Message-ID: <1313006723.38.0.916727379415.issue4841@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Aug 10 22:23:13 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 10 Aug 2011 20:23:13 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1313007793.85.0.615136935746.issue10588@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

The reason for this is that file_module tries to detect the encoding of the file to set the encoding for the opened file. IMO, it should just return a file in binary mode.

----------
nosy: +benjamin.peterson, haypo

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

From report at bugs.python.org  Wed Aug 10 22:29:18 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 10 Aug 2011 20:29:18 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1313008158.12.0.539022270429.issue12613@psf.upfronthosting.co.za>


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


----------
nosy: +meador.inge

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

From report at bugs.python.org  Wed Aug 10 22:32:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Aug 2011 20:32:43 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1313008363.61.0.390430685145.issue12687@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

First, the patch calls PyOS_strtol while a Py_ssize_t should be decodable. However, the dump phase (in memo_put) coerces the memo size to long as well, so this shouldn't be a problem in real life.

Second, the patch needs a test.

Also, please click on the "resolution" link for meaning of the various possible "values". "Accepted" is only to be used when something has been positively reviewed.

----------
resolution: accepted -> 

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

From report at bugs.python.org  Thu Aug 11 01:16:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 10 Aug 2011 23:16:19 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1313018179.65.0.772968342054.issue12687@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can add a test, using the data attached to the ticket, but like the marshal case we discussed before, it might be several KB of data, which I would incorporate into the tests using a similar approach to the one I used for marshal. (This data has been shrunk from a much larger data set, but I can't easily make it any smaller.)

I've no idea why I changed the resolution, I don't normally do this. Probably a case of brain-fade :-(

----------

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

From report at bugs.python.org  Thu Aug 11 02:40:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Aug 2011 00:40:37 +0000
Subject: [issue12724] Add Py_RETURN_NOTIMPLEMENTED
Message-ID: <1313023237.87.0.322234787973.issue12724@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Would anyone be opposed to adding the following simple macro, which would be the same as the one we have for Py_RETURN_NONE. I recently found myself doing the Py_INCREF/return dance several times and ended up leaving an incref out in a few spots, which the macro form nicely handles.

diff --git a/Include/object.h b/Include/object.h
--- a/Include/object.h
+++ b/Include/object.h
@@ -792,6 +792,10 @@
 PyAPI_DATA(PyObject) _Py_NotImplementedStruct; /* Don't use this directly */
 #define Py_NotImplemented (&_Py_NotImplementedStruct)

+/* Macro for returning Py_NotImplemented from a function */
+#define Py_RETURN_NOTIMPLEMENTED \
+    return Py_INCREF(Py_NotImplemented), Py_NotImplemented
+
 /* Rich comparison opcodes */
 #define Py_LT 0
 #define Py_LE 1


If this is fine, I can also take care of making the replacements, of which there are apparently 55.

----------
assignee: brian.curtin
components: None
keywords: needs review, patch
messages: 141886
nosy: brian.curtin
priority: normal
severity: normal
stage: patch review
status: open
title: Add Py_RETURN_NOTIMPLEMENTED
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 11 02:45:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Aug 2011 00:45:16 +0000
Subject: [issue12723] tkSimpleDialog.askstring shouldn't allow empty string
	input
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313023516.3.0.105126012415.issue12723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But what if the empty string is valid input?  This change would be backward incompatible.

I think this should instead be a feature request for exposing _QueryDialog so that you can subclass it and provide your own getresult function.

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

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

From report at bugs.python.org  Thu Aug 11 02:58:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 11 Aug 2011 00:58:15 +0000
Subject: [issue12724] Add Py_RETURN_NOTIMPLEMENTED
In-Reply-To: <1313023237.87.0.322234787973.issue12724@psf.upfronthosting.co.za>
Message-ID: <1313024295.64.0.949746628094.issue12724@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu Aug 11 03:25:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 01:25:33 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <E1QrK1b-0003Hf-Hh@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9fc7ef60ea06 by Senthil Kumaran in branch '3.2':
Fix closes Issue10087 -  fixing the output of calendar display in the html format. Patch by Chris Lambacher. Test Contributed by catherine.
http://hg.python.org/cpython/rev/9fc7ef60ea06

New changeset 23316468ed4f by Senthil Kumaran in branch '3.2':
News item for Issue10087.
http://hg.python.org/cpython/rev/23316468ed4f

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

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

From report at bugs.python.org  Thu Aug 11 03:25:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Aug 2011 01:25:34 +0000
Subject: [issue6203] 3.x locale does not default to C,
	contrary to the documentation and to 2.x behavior
In-Reply-To: <1244199398.44.0.399320307295.issue6203@psf.upfronthosting.co.za>
Message-ID: <1313025934.36.0.141959758367.issue6203@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes a new issue would be more appropriate.

----------

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

From report at bugs.python.org  Thu Aug 11 03:34:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 01:34:39 +0000
Subject: [issue12724] Add Py_RETURN_NOTIMPLEMENTED
In-Reply-To: <1313023237.87.0.322234787973.issue12724@psf.upfronthosting.co.za>
Message-ID: <E1QrKAP-0003jI-MF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 77a65b078852 by Brian Curtin in branch 'default':
Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
http://hg.python.org/cpython/rev/77a65b078852

New changeset d0b0fcbb40db by Brian Curtin in branch 'default':
Replace Py_NotImplemented returns with the macro form Py_RETURN_NOTIMPLEMENTED.
http://hg.python.org/cpython/rev/d0b0fcbb40db

New changeset 3a6782f2a4a8 by Brian Curtin in branch 'default':
News item for #12724
http://hg.python.org/cpython/rev/3a6782f2a4a8

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

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

From report at bugs.python.org  Thu Aug 11 03:35:25 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Aug 2011 01:35:25 +0000
Subject: [issue12724] Add Py_RETURN_NOTIMPLEMENTED
In-Reply-To: <1313023237.87.0.322234787973.issue12724@psf.upfronthosting.co.za>
Message-ID: <1313026525.29.0.239719981405.issue12724@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


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

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

From report at bugs.python.org  Thu Aug 11 04:47:55 2011
From: report at bugs.python.org (Cris Simpson)
Date: Thu, 11 Aug 2011 02:47:55 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
Message-ID: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>


New submission from Cris Simpson <crisor at gmail.com>:

In http://docs.python.org/library/socket.html, the description for socket.setdefaulttimeout(timeout) reads: 
    Set the default timeout in *floating seconds* for new socket objects.
[occurs two other times on that page]


"floating seconds" is a confusing construction. 

Suggestion: "float expressing seconds" as per socket.settimeout(value) or "seconds (float)".

----------
assignee: docs at python
components: Documentation
messages: 141892
nosy: Cris.Simpson, docs at python
priority: normal
severity: normal
status: open
title: Docs: Odd phrase "floating seconds" in socket.html
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Aug 11 06:13:21 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 11 Aug 2011 04:13:21 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1313036001.09.0.401114939768.issue12613@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I see two problems that cause the posted test cases to fail:

  1. The 'next' fixer runs before the 'itertools' fixer and strips
     out a 'power' node.  This keeps the 'itertools' fixer from
     matching.

  2. The 'itertools' fixer does not handle any 'trailer' nodes after
     the itertool function application it is transforming.

I have fixed both of these issues in the attached patch.  Full test suite run; no regressions.

----------
keywords: +patch
stage: needs patch -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file22878/issue12613.patch

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

From report at bugs.python.org  Thu Aug 11 08:39:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 11 Aug 2011 06:39:12 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313044752.37.0.965129060436.issue12721@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

I'd call os.path.join() in the test functions rather than in read_file() and write_file(). This makes it easier to understand what the test is doing without looking at the code of read_file() and write_file().

Otherwise, looks good to me, and I think this would be useful cleanup.

----------
keywords: +needs review
nosy: +eric.araujo, petri.lehtinen, tarek
stage:  -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Aug 11 08:59:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Aug 2011 06:59:58 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1313045998.43.0.378675723932.issue12687@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, the patch is not correct. The core issue is that _Unpickler_Readline should always return a \0-terminated string, but sometimes it doesn't; this issue should be fixed instead of working around it in some other function.

----------

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

From report at bugs.python.org  Thu Aug 11 09:39:02 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 11 Aug 2011 07:39:02 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313048342.78.0.433603848438.issue12721@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I tend to agree on public APIs, however in this case of a helper function the use case with a join is really really common so this extra function comes in very handy. I also kept it using lists, so it's more obvious than tuples.

JFTR it wasn't my idea, so I'm not defensive about my own idea here. :)  I just re-implemented it for read_file b/c it's really handy and saves a lot of typing.

----------

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

From report at bugs.python.org  Thu Aug 11 11:18:55 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 11 Aug 2011 09:18:55 +0000
Subject: [issue12726] explain why locale.getlocale() does not read system's
	locales
Message-ID: <1313054335.82.0.864365511342.issue12726@psf.upfronthosting.co.za>


New submission from Alexis Metaireau <alexis at notmyidea.org>:

The documentation about locale.getlocale() doesn't talk about the fact that the locale isn't read from the system locale. Thus, it seemed strange to have locale.getlocale() returning (None, None).

As it seems to be the expected behaviour, it seems useful to specify this in the documentation and make it explicit.

I'm okay to write a patch and apply it.

This issue is related to #6203, but does not supersede it (the two conversations are discussing two different things).

----------
assignee: alexis
components: Documentation
messages: 141897
nosy: alexis, feth
priority: normal
severity: normal
status: open
title: explain why locale.getlocale() does not read system's locales

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

From report at bugs.python.org  Thu Aug 11 11:40:24 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 11 Aug 2011 09:40:24 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1313055624.49.0.805200050048.issue12687@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I confess I'm not familiar enough with the pickle module internals to be sure of putting in the right fix quickly. I will take a look at _Unpickler_Readline when I get a chance, if someone doesn't beat me to it :-)

----------

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

From report at bugs.python.org  Thu Aug 11 12:45:04 2011
From: report at bugs.python.org (Leonid Vasilev)
Date: Thu, 11 Aug 2011 10:45:04 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1313059504.84.0.463202031989.issue12661@psf.upfronthosting.co.za>


Leonid Vasilev <vsleonid at gmail.com> added the comment:

yup, it's really to specific.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Aug 11 12:45:12 2011
From: report at bugs.python.org (Leonid Vasilev)
Date: Thu, 11 Aug 2011 10:45:12 +0000
Subject: [issue12661] Add a new shutil.cleartree function to shutil module
In-Reply-To: <1312048372.59.0.959522450911.issue12661@psf.upfronthosting.co.za>
Message-ID: <1313059512.68.0.923281937324.issue12661@psf.upfronthosting.co.za>


Changes by Leonid Vasilev <vsleonid at gmail.com>:


----------
resolution: invalid -> rejected

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

From report at bugs.python.org  Thu Aug 11 13:45:32 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Aug 2011 11:45:32 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1313063132.73.0.545654098966.issue12701@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

If there's dependence on undefined behaviour (from overflow of signed integer operations) in intobject.c, I'd call that a bug.  I've been trying to remove similar overflow checks from the Python source when I've encountered them, but there are still a good few left.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Aug 11 13:48:32 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 11 Aug 2011 11:48:32 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1313063312.96.0.929507745703.issue12701@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Removed file: http://bugs.python.org/file22866/unnamed

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

From report at bugs.python.org  Thu Aug 11 14:09:05 2011
From: report at bugs.python.org (Matthew Hemke)
Date: Thu, 11 Aug 2011 12:09:05 +0000
Subject: [issue12723] tkSimpleDialog.askstring shouldn't allow empty string
	input
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313064545.82.0.335875415592.issue12723@psf.upfronthosting.co.za>


Matthew Hemke <mghemke at gmail.com> added the comment:

What about adding a validatecommand option like on Tkinter.Entry?

For what I am trying to do it was sort of a kludge to validate the entry because an empty string was invalid, but in the interface design, it would have been "rude" to validate after the dialog closes and then keep popping up another tkSimpleDialog.askstring until the input is correct. It almost makes askstring useless because I can't validate on close.

That wouldn't break backwards compatibility would it?

----------

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

From report at bugs.python.org  Thu Aug 11 14:16:08 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Aug 2011 12:16:08 +0000
Subject: [issue12701] Apple's clang 2.1 (xcode 4.1,
	OSX 10.7) optimizer miscompiles intobject.c
In-Reply-To: <1312598819.22.0.165585430892.issue12701@psf.upfronthosting.co.za>
Message-ID: <1313064968.49.0.31855639657.issue12701@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Clang has an option "-fcatch-undefined-behavior" that might help in locating other locations where we use undefined behavior.

----------

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

From report at bugs.python.org  Thu Aug 11 14:24:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Aug 2011 12:24:59 +0000
Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom
	validation functions
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313065499.3.0.772668366235.issue12723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Adding an option would also be a reasonable feature request, but I think exposing _QueryDialog would be a more general solution, since it would apply to more than just strings.

While not backward incompatible, either of these is a new feature and so can only go into 3.3.

----------
stage:  -> needs patch
title: tkSimpleDialog.askstring shouldn't allow empty string input -> Provide an API in tkSimpleDialog for defining custom validation functions
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Thu Aug 11 14:47:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 12:47:08 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <E1QrUfD-0008Mr-C2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0fbd44e3f342 by Vinay Sajip in branch '2.7':
Issue #12718: Add documentation on using custom importers.
http://hg.python.org/cpython/rev/0fbd44e3f342

New changeset 1e96a4406565 by Vinay Sajip in branch '3.2':
Issue #12718: Add documentation on using custom importers.
http://hg.python.org/cpython/rev/1e96a4406565

New changeset 76964d70c81c by Vinay Sajip in branch 'default':
Closes #12718: Merge documentation fix from 3.2.
http://hg.python.org/cpython/rev/76964d70c81c

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

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

From report at bugs.python.org  Thu Aug 11 15:37:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Aug 2011 13:37:59 +0000
Subject: [issue12718] Logical mistake of importer method in
	logging.config.BaseConfigurator
In-Reply-To: <1312910741.64.0.384635164559.issue12718@psf.upfronthosting.co.za>
Message-ID: <1313069879.84.0.0273596671202.issue12718@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Aug 11 16:31:13 2011
From: report at bugs.python.org (Johannes Hoff)
Date: Thu, 11 Aug 2011 14:31:13 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1313073073.41.0.592754942392.issue3244@psf.upfronthosting.co.za>


Johannes Hoff <johshoff at gmail.com> added the comment:

Forest Bond: Thanks for this patch - I hope it will go in soon. In the meantime, could I get permission to use it as is? (I notice there is a copyright in the file) I would of course keep the attributions in the file.

----------
nosy: +Johannes.Hoff

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

From report at bugs.python.org  Thu Aug 11 16:35:21 2011
From: report at bugs.python.org (Forest Bond)
Date: Thu, 11 Aug 2011 14:35:21 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1313073321.08.0.934093061884.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hi, Johannes.  You can assume the Python license for this patch.

-Forest

----------

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

From report at bugs.python.org  Thu Aug 11 16:42:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 14:42:00 +0000
Subject: [issue12724] Add Py_RETURN_NOTIMPLEMENTED
In-Reply-To: <1313023237.87.0.322234787973.issue12724@psf.upfronthosting.co.za>
Message-ID: <E1QrWSH-0002jj-Kb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e88362fb4950 by Brian Curtin in branch 'default':
Add doc for Py_RETURN_NOTIMPLEMENTED, added in #12724.
http://hg.python.org/cpython/rev/e88362fb4950

----------

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

From report at bugs.python.org  Thu Aug 11 16:57:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 14:57:23 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313074643.2.0.819140414967.issue12721@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ll make one change before committing:

Lib/test/test_shutil.py:69: if isinstance(path, (list, tuple)):
Using a list for path components does not make sense.  I have changed a similar helper function in packaging to allow only tuples.

Petri: these helper functions are all about convenienve.  I would reject a patch for a function just doing open+read, but here I think that doing os.path.join+open+read is worth a function.  We use such helpers all the time in packaging tests and it helps reducing boilerplate, without being very hard to understand.

----------
assignee:  -> eric.araujo
resolution:  -> accepted
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Aug 11 17:19:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 15:19:43 +0000
Subject: [issue12722] Link to heapq source from docs.python.org not working
In-Reply-To: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>
Message-ID: <1313075983.73.0.814505485935.issue12722@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The fix committed will be superseded by a link to the Mercurial repo when I fix #11435 (probably tomorrow).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Thu Aug 11 18:02:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 16:02:45 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313078565.32.0.00276556211233.issue12672@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I know perfectly well that [].append is valid Python,
> but I don't think this is the clearest way to give an example of an
> object method. I think spelling [].append's meaning more explicitly
> would be better.
Would it be clearer if we replaced the literal with a name?

  These C functions are called ?type methods? to distinguish them from
- things like [].append (which we call ?object methods?).
+ methods bound to specific instances (things like sys.path.append),
+ which we call ?object methods?.

> I'm also aware that there are tab problems all over the code base.
> I'm not suggesting a large cleanup.
*I* was suggesting a large cleanup :), but we can do that in another commit.  If you want to clean the example code in Doc/extending or even just in newtypes.rst, I think you can just go ahead.

----------

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

From report at bugs.python.org  Thu Aug 11 18:08:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 16:08:09 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281069203.79.0.816772507809.issue9528@psf.upfronthosting.co.za>
Message-ID: <1313078889.92.0.0891128739971.issue9528@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Alan: the Versions field is used to mark versions that will get a patch, not all versions affected.

----------

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

From report at bugs.python.org  Thu Aug 11 18:47:10 2011
From: report at bugs.python.org (Dolf Andringa)
Date: Thu, 11 Aug 2011 16:47:10 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1313081230.46.0.23842060263.issue5639@psf.upfronthosting.co.za>


Dolf Andringa <dolfandringa at gmail.com> added the comment:

I see the patch has been applied python3 in r85793, but is there any chance there will also be patches for python 2.6 or 2.7? And if so, what release of python (any version) might this patch be included in?

----------
nosy: +Dolf.Andringa
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Aug 11 18:49:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Aug 2011 16:49:52 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1313081392.7.0.932097277379.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I see the patch has been applied python3 in r85793, but is there any
> chance there will also be patches for python 2.6 or 2.7

No, Python 2 only receives bug fixes.

----------

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

From report at bugs.python.org  Thu Aug 11 19:46:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 11 Aug 2011 17:46:33 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1313074643.2.0.819140414967.issue12721@psf.upfronthosting.co.za>
Message-ID: <20110811174631.GA1830@ihaa>


Petri Lehtinen <petri at digip.org> added the comment:

?ric Araujo wrote:
> Petri: these helper functions are all about convenienve. I would
> reject a patch for a function just doing open+read, but here I think
> that doing os.path.join+open+read is worth a function. We use such
> helpers all the time in packaging tests and it helps reducing
> boilerplate, without being very hard to understand.

Ok, sounds reasonable.

----------

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

From report at bugs.python.org  Thu Aug 11 20:30:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Aug 2011 18:30:30 +0000
Subject: [issue12727] "make" always reruns asdl_c.py
Message-ID: <1313087430.82.0.426991867547.issue12727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It's not really an issue, but I thought I would mention it. It is a bit misleading, since it makes you think that you changed something in the grammar that's triggering the rebuild.

$ make
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
running build
running build_ext

----------
assignee: benjamin.peterson
components: Build
messages: 141915
nosy: benjamin.peterson, pitrou
priority: low
severity: normal
status: open
title: "make" always reruns asdl_c.py
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 11 20:48:21 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 18:48:21 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
Message-ID: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

The Python re library is broken in its approach to case-insensitive matches. It erroneously attempts to compare lowercase mappings.  This is wrong. You must compare the Unicode casefolds, not the Unicode casemaps. Otherwise you get wrong answers.  I include a small test case that illustrates this bug.  The bug exists on both 2.7 and 3.2, and on both wide builds and narrow builds.  For comparison, I also show results using Matthew Barnett's regex library, which gets all 5 tests correct where re gets all 5 tests wrong.

A sample run is:

FAIL: re    pattern ? is    not the same as string ?
PASS: regex pattern ? is indeed the same as string ?
FAIL: re    pattern ? is    not the same as string ?
PASS: regex pattern ? is indeed the same as string ?
FAIL: re    pattern ? is    not the same as string s
PASS: regex pattern ? is indeed the same as string s
FAIL: re    pattern ??????? is    not the same as string ???????
PASS: regex pattern ??????? is indeed the same as string ???????
FAIL: re    pattern POST is    not the same as string po?t
PASS: regex pattern POST is indeed the same as string po?t

re    lib passed 0 of 5 tests
regex lib passed 5 of 5 tests

----------
components: Library (Lib)
files: sigmata.python
messages: 141916
nosy: tchrist
priority: normal
severity: normal
status: open
title: Python re lib fails case insensitive matches on Unicode data
versions: Python 2.7
Added file: http://bugs.python.org/file22879/sigmata.python

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

From report at bugs.python.org  Thu Aug 11 21:03:55 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:03:55 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
Message-ID: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Python is in flagrant violation of the very most basic premises of Unicode Technical Report #18 on Regular Expressions, which requires that a regex engine support Unicode characters as "basic logical units independent of serialization like UTF?*".  Because sometimes you must specify ".." to match a single Unicode character -- whenever those code points are above the BMP and you are on a narrow build -- Python regexes cannot be reliably used for Unicode text.

 % python3.2
 Python 3.2 (r32:88445, Jul 21 2011, 14:44:19)
 [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import re
 >>> g = "\N{GREEK SMALL LETTER ALPHA WITH VARIA AND YPOGEGRAMMENI}"
 >>> print(g)
?
 >>> print(re.search(r'\w', g))
 <_sre.SRE_Match object at 0x10051f988>
 >>> p = "\N{MATHEMATICAL SCRIPT CAPITAL P}"
 >>> print(p)
?
 >>> print(re.search(r'\w', p))
None
 >>> print(re.search(r'..', p))   # ? ???????????????????????????????? 
<_sre.SRE_Match object at 0x10051f988>
 >>> print(len(chr(0x1D4AB)))
2

That is illegal in Unicode regular expressions.

----------
components: Regular Expressions
messages: 141917
nosy: tchrist
priority: normal
severity: normal
status: open
title: Python lib re cannot handle Unicode properly due to narrow/wide bug
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 11 21:10:05 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:10:05 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
Message-ID: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

You cannot use Python's casemapping functions on Unicode data because they fail on narrow builds.  This makes it impossible to write portable code in Python that can cope with full Unicode.

I've tried several times to submit this bug, but the file selection widget blows up. I believe it was an Opera bug because I had a write lock on the file.  One more time.

----------
components: Unicode
files: casemaps.python
messages: 141918
nosy: tchrist
priority: normal
severity: normal
status: open
title: Python's casemapping functions are untrustworthy due to narrow/wide build issues
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22880/casemaps.python

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

From report at bugs.python.org  Thu Aug 11 21:17:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 19:17:56 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <E1QralO-0003RA-IN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c47bc1349e61 by Antoine Pitrou in branch '3.2':
Issue #12687: Fix a possible buffering bug when unpickling text mode (protocol 0, mostly) pickles.
http://hg.python.org/cpython/rev/c47bc1349e61

New changeset 6aa822071f4e by Antoine Pitrou in branch 'default':
Issue #12687: Fix a possible buffering bug when unpickling text mode (protocol 0, mostly) pickles.
http://hg.python.org/cpython/rev/6aa822071f4e

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

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

From report at bugs.python.org  Thu Aug 11 21:18:31 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:18:31 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
Message-ID: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

You cannot use Python's lib re for handling Unicode regular expressions because it violates the standard set out for the same in UTS#18 on Unicode Regular Expressions in RL1.2a on compatibility properties.  What \w is allowed to match is clearly explained there, but Python has its own idea. Because it is in clear violation of the standard, it is misleading and wrong for Python to claim that the re.UNICODE flag makes \w and friends match Unicode.  Here are the failed test cases when the attached file is run under v3.2; there are further failures when run under v2.7.

FAIL lib re    found non alphanumeric string cafe?
FAIL lib re    found non alphanumeric string ?
FAIL lib re    found non alphanumeric string ?
FAIL lib re    found non alphanumeric string ?
FAIL lib re    found non alphanumeric string ?
FAIL lib re    found non alphanumeric string ?
FAIL lib re    found non alphanumeric string ???????
FAIL lib re    found non alphanumeric string ???????
FAIL lib re    found non alphanumeric string connector?punctuation
FAIL lib re    found non alphanumeric string ??_???_??????
FAIL lib re    found non alphanumeric string ????????????????????????
FAIL lib re    found all alphanumeric string ???
FAIL lib re    found all alphanumeric string ???
FAIL lib re    found all alphanumeric string ???
FAIL lib re    found all alphanumeric string ?

Note that Matthew Barnett's regex lib for Python handles all of these cases in comformance with The Unicode Standard.

----------
components: Regular Expressions
files: alnum.python
messages: 141920
nosy: tchrist
priority: normal
severity: normal
status: open
title: python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22881/alnum.python

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

From report at bugs.python.org  Thu Aug 11 21:21:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Aug 2011 19:21:33 +0000
Subject: [issue12687] Python 3.2 fails to load protocol 0 pickle
In-Reply-To: <1312365315.8.0.593753926369.issue12687@psf.upfronthosting.co.za>
Message-ID: <1313090493.1.0.103012363003.issue12687@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed with a test.

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

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

From report at bugs.python.org  Thu Aug 11 21:46:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Aug 2011 19:46:59 +0000
Subject: [issue12727] "make" always reruns asdl_c.py
In-Reply-To: <1313087430.82.0.426991867547.issue12727@psf.upfronthosting.co.za>
Message-ID: <E1QrbDV-00067j-PD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5e005773feaa by Benjamin Peterson in branch 'default':
revert code which conditionally writes Python-ast.h (closes #12727)
http://hg.python.org/cpython/rev/5e005773feaa

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

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

From report at bugs.python.org  Thu Aug 11 21:49:35 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:49:35 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
Message-ID: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

You cannot reliably use Unicode in Python identifiers because of the narrow/wide build issue.  The enclosed file is fine on wide builds but gets compiler errors on narrow ones during compilation.

Go, Ruby, Java, and Perl all handle this situation without any problem; only Python has the bug.

----------
components: Interpreter Core
files: badidents.python
messages: 141923
nosy: tchrist
priority: normal
severity: normal
status: open
title: Can't portably use Unicode in Python identifiers
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22882/badidents.python

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

From report at bugs.python.org  Thu Aug 11 21:50:28 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:50:28 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1313092228.73.0.193258772807.issue12728@psf.upfronthosting.co.za>


Changes by Tom Christiansen <tchrist at perl.com>:


----------
components: +Regular Expressions -Library (Lib)
type:  -> behavior

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

From report at bugs.python.org  Thu Aug 11 21:59:53 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:59:53 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
Message-ID: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Without proper grapheme support in the regular expression library, it is impossible to correctly process Unicode.  And the very least, one needs the \X escape supported, which is an extended grapheme cluster per UTS#18. This escape is supported by many regex libraries, include Perl's own and of course PCRE (and thence PHP, the standard ICU library, and Matthew Barnett's replacement regex library for Python.

How do you process a string by graphemes if you cannot split on \X?  How can you avoid splitting a grapheme into silly pieces if you cannot match one?  How do I match the letter O no matter what diacritics have been applied to it otherwise?  A match of (?=O)\X against an NFD string is by far the simplest and best way.

This is necessary for a wide variety of reasons.  Adding \pM and \PM go a little ways, but not far enough, because that is not how grapheme clusters are defined.  You need a proper \X.

----------
components: Regular Expressions
messages: 141924
nosy: tchrist
priority: normal
severity: normal
status: open
title: Request for grapheme support in Python re lib
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug 11 22:14:14 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 20:14:14 +0000
Subject: [issue12734] Request for property support in Python re lib
Message-ID: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Python supports no Unicode properties in its re library, making it unsuitable for work with Unicode. This is therefore a formal request for the Python re library to support Unicode properties.

 The eleven properties required by Unicode Technical Report #18's RL1.2 are the bare minimum which must be added to make it possible to use Python reguyar expressions on Unicode. 

The proposed RL2.7 on Full Properties is even better.  That is found at

  http://unicode.org/reports/tr18/proposed.html#Full_Properties

Although by the time you read this, it will have been made an official part of tr18.

Matthew Barnett's replacement library for re, called regex, support 67 Unicode properties at last count, including the strongly recommended loose matching.  

The standard re library needs to be spiffed up to make it suitable for Unicode processing; it is not currently usable for that due to this missing functionality.  I quote from the Level 1 conformance requirement of tr18:
    
    "Level 1: This is a minimal level for useful Unicode support. It does not account for end-user expectations for character support, but does satisfy most low-level programmer requirements. The results of regular expression matching at this level are independent of country or language. At this level, the user of the regular expression engine would need to write more complicated regular expressions to do full Unicode processing."

pass RL1.1 Hex Notation
fail RL1.2 Properties
fail RL1.2a Compatibility Properties
fail RL1.3 Subtraction and Intersection
fail RL1.4 Simple Word Boundaries
fail RL1.5 Simple Loose Matches
fail RL1.6 Line Boundaries
fail RL1.7 Supplementary Code Points

(withdrawn) RL2.1 Canonical Equivalents
fail RL2.2 Extended Grapheme Clusters
fail RL2.3 Default Word Boundaries
fail RL2.4 Default Case Conversion
pass RL2.5 Name Properties
fail RL2.6 Wildcards in Property Values
fail RL2.7 Full Properties

I won?t even talk about Level 3.  

ICU, Perl, and Java7 all meet Level One conformance requirements with several Level 2 requirements also met.  It is important for Python to meet the Unicode Standard in this so that people can use Python for regex matching Unicode text.  They currently cannot usefully do so per the requirements of tr18.

----------
components: Regular Expressions
messages: 141925
nosy: tchrist
priority: normal
severity: normal
status: open
title: Request for property support in Python re lib
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug 11 22:18:17 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 20:18:17 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
Message-ID: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Python has no standard support for the Unicode Collation Library as explained in UTS #10.  This is request that UCA library be added to the standard Python distribution.

Collation underlies virtually everything we do with text, not just sorting but any sort of comparison. Furthermore, the UCA is tailorable for locales in a portable way that does not require dodgy vendor support. It is a very important step in making Python suitable for full Unicode text processing.

----------
components: Library (Lib)
messages: 141926
nosy: tchrist
priority: normal
severity: normal
status: open
title: request full Unicode collation support in std python library
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug 11 22:30:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 11 Aug 2011 20:30:22 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313094622.71.0.456449551093.issue12730@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

A sign!
A sign!

Someone with a name-name-name!!

(Not a useful comment, i'm afraid.)

----------
nosy: +sdaoden

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

From report at bugs.python.org  Thu Aug 11 22:30:47 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 11 Aug 2011 20:30:47 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313094647.68.0.893779610772.issue12730@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
nosy:  -sdaoden

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

From report at bugs.python.org  Thu Aug 11 22:34:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 11 Aug 2011 20:34:37 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313094877.56.0.789696152531.issue12730@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From report at bugs.python.org  Thu Aug 11 23:39:45 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 21:39:45 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
Message-ID: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Python's casemapping functions only use what Unicode calls simple casemaps. These are only appropriate for functions that operate on single characters alone, not for those that operate on strings. The reason for this is that you get much better results with full casemapping. Java, Ruby, and Perl all do full casemapping for their equivalent functions that do string mapping, and Python should, too.

I include a program that has a much of mappings and foldings both simple and full.  Yes, it was machine-generated.

----------
components: Library (Lib)
files: mux.python
messages: 141928
nosy: tchrist
priority: normal
severity: normal
status: open
title: Request for python casemapping functions to use full not simple casemaps per Unicode's recommendation
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file22883/mux.python

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

From report at bugs.python.org  Fri Aug 12 00:16:35 2011
From: report at bugs.python.org (Aaron Robson)
Date: Thu, 11 Aug 2011 22:16:35 +0000
Subject: [issue3561] Windows installer should add Python and Scripts
	directories to the PATH environment variable
In-Reply-To: <1218820643.64.0.47446345444.issue3561@psf.upfronthosting.co.za>
Message-ID: <1313100995.68.0.792790162286.issue3561@psf.upfronthosting.co.za>


Changes by Aaron Robson <shiny.magnum at googlemail.com>:


----------
nosy: +AaronR

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

From report at bugs.python.org  Fri Aug 12 00:17:17 2011
From: report at bugs.python.org (Aaron Robson)
Date: Thu, 11 Aug 2011 22:17:17 +0000
Subject: [issue12006] strptime should implement %V or %u directive from libc
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1313101037.77.0.915494216414.issue12006@psf.upfronthosting.co.za>


Changes by Aaron Robson <shiny.magnum at googlemail.com>:


----------
nosy: +AaronR

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

From report at bugs.python.org  Fri Aug 12 00:37:34 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 22:37:34 +0000
Subject: [issue12737] string.title() is overzealous by upcasing combining
	marks inappropriately
Message-ID: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Python's string.title() function claims it titlecases the first letter in each word and lowercases the rest.  However, this is not true.  It is not using either of the two word detection algorithms that Unicode provides.  One allows you to use a legacy \w+, where \w means any Alphabetic, Mark, Decimal Number, or Connector Punctuation (see UTS#18 Annex C: Compatibility Properties), and the other uses the more sophisticated word-break provided by the Word_Break properties such as Word_Break=MidNumLet

Python is using neither of these, so gets the wrong answer.

titlecase of d?me un caf? should be D?me Un Caf? not D?Me Un Caf?
titlecase of i?stanbul should be ?stanbul not ?Stanbul
titlecase of ? ??? ?????? should be ?? ??? ?????? not ?? ??? ??????

Because those are in NFD form, you get different answers than if they are in NFC.  That is not right. You should get the same answer. The bug is you aren't using the right definition for \w, and so get screwed up.  This is likely related to issue 12731.

In the enclosed tester file, which fails 4 out of its 6 tests, there is also a bug shown with this failed result:

  titlecase of ??????? should be ??????? not ???????

That one is related to issue 12730. 

See the attached tester, which was run under Python 3.2.  As far as I can tell, these bugs exist in all python versions.

----------
files: titletest.python
messages: 141929
nosy: tchrist
priority: normal
severity: normal
status: open
title: string.title()  is overzealous by upcasing combining marks inappropriately
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22884/titletest.python

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

From report at bugs.python.org  Fri Aug 12 00:53:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 11 Aug 2011 22:53:10 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313103190.08.0.149962203787.issue12730@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/issue12730>
_______________________________________

From report at bugs.python.org  Fri Aug 12 00:53:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 11 Aug 2011 22:53:23 +0000
Subject: [issue12737] string.title() is overzealous by upcasing combining
	marks inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313103203.96.0.832523162688.issue12737@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/issue12737>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:09:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Aug 2011 00:09:19 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313107759.67.0.907482396906.issue12729@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is an acknowledged problem with Python narrow builds, and applies to much more than just regex processing.

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

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

From report at bugs.python.org  Fri Aug 12 02:15:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Aug 2011 00:15:58 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313108158.34.0.854410219624.issue12734@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the only way re is going to get "spiffed up" is by replacing it with Matthew's library.  This is a goal, but I'm not sure where exactly we are in the process.  The more Matthew's code gets tested (especially for compatibility with the current re API), the closer we will be to that goal.

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

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

From report at bugs.python.org  Fri Aug 12 02:17:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:17:23 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1313108243.49.0.606620814483.issue12736@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, ezio.melotti

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

From report at bugs.python.org  Fri Aug 12 02:18:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:18:00 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1313108280.09.0.821560350205.issue12735@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, ezio.melotti

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

From report at bugs.python.org  Fri Aug 12 02:18:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:18:12 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313108292.85.0.0237015011618.issue12734@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/issue12734>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:18:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:18:31 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1313108311.56.0.416218115989.issue12733@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/issue12733>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:19:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:19:09 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <1313108349.8.0.948598959385.issue12732@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/issue12732>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:20:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:20:02 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313108402.01.0.744204323492.issue12731@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/issue12731>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:20:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 00:20:11 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1313108411.5.0.60995138872.issue12728@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/issue12728>
_______________________________________

From report at bugs.python.org  Fri Aug 12 02:25:42 2011
From: report at bugs.python.org (Michael Hall)
Date: Fri, 12 Aug 2011 00:25:42 +0000
Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on
	Ubuntu 11.04
Message-ID: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za>


New submission from Michael Hall <michaelhall1k at gmail.com>:

I recently switched to Ubuntu 11.04 from OpenSUSE 11.4, and when I go to run a project I coded a couple days ago under OpenSUSE using the multiprocessing library, it hangs when it did not under OpenSUSE.

Specifically, I am using two queues, work_queue from which the children get jobs, and results_queue where they place their results before calling JoinableQueue.task_done() and grabbing the next result. I use the "poison pill" technique to terminate the children, where a None object is placed at the end of the queue for each child, and when they get one of the terminating objects they call task_done() again (to account for the None object) and exit.

In the main process, after spawning all of the children (one per physical CPU), it joins with the work_queue in order to wait for all of its children to finish.

This is pretty much a cookie-cutter multiprocessing implementation that I've used successfully for years under OpenSUSE, but for some odd reason the exact same code does not work under Ubuntu.

I would try porting to python 3.x, but the rest of my research team is still using 2.7, so that's not really an option right now.

----------
components: Library (Lib)
messages: 141932
nosy: Michael.Hall
priority: normal
severity: normal
status: open
title: Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 12 02:30:42 2011
From: report at bugs.python.org (Michael Hall)
Date: Fri, 12 Aug 2011 00:30:42 +0000
Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on
	Ubuntu 11.04
In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za>
Message-ID: <1313109042.09.0.0713011032928.issue12738@psf.upfronthosting.co.za>


Michael Hall <michaelhall1k at gmail.com> added the comment:

Edit: Sorry, I should have been more clear. The hang occurs after the first child process exits, at which point all four children become zombies (none of the others exit, they just zombify immediately), and the main process sits there waiting forever for the rest of the children to clear out the queue, which of course never happens.

----------
type:  -> behavior

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

From report at bugs.python.org  Fri Aug 12 03:46:35 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 01:46:35 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313113595.16.0.319234263354.issue12734@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

I've been a lot of testing of Matthew's regex library against UTS#18 issues, but only somewhat incidentally testing re. To use regex, one has to accept that certain things will work differently than they work in re, because he is following Unicode definitions for things like casefolding. 

But I doubt that is the sort of difference you are talking about. One of the things that Java, Go, and Perl all do is run regression tests against the whole Unicode Character Database to make sure nothing gets hosed, missed, or otherwise out of sync. That might a sort of regression test you might like to add.

----------

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

From report at bugs.python.org  Fri Aug 12 04:09:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Aug 2011 02:09:12 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1313114952.03.0.538874576463.issue12708@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+def starmapstar(args):
+    return list(itertools.starmap(args[0], args[1]))

Is your new function restricted to 2 arguments?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Fri Aug 12 04:28:02 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 02:28:02 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1313116082.92.0.238212663948.issue12568@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

I can attest that being able to get the columns of a grapheme cluster is very important for printing, because you need this to do correct linebreaking.  There might be something you can steal from 

   http://search.cpan.org/perldoc?Unicode::GCString
   http://search.cpan.org/perldoc?Unicode::LineBreak

which implements UAX#14 on linebreaking and UAX#11 on East Asian widths.  

I use this in my own code to help format Unicode strings my columns or lines.  The right way would be to build this sort of knowledge into string.format(), but that is much harder, so an intermediary library module seems good enough for now.

----------
nosy: +tchrist

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

From report at bugs.python.org  Fri Aug 12 04:36:31 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 02:36:31 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313116591.64.0.0484807939011.issue11230@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

How does this work for modules that have filesystem names different from the one used for import? The issue I'm thinking about is that the Mac HSF+ filesystem keeps its Unicode filenames in (close to) NFD form. That means that a module named "caf\N{LATIN SMALL LETTER E WITH ACUTE}" with 4 graphemes and 4 code points in its name winds up in the filesystem as "cafe\N{COMBINING ACUTE ACCENT}" still with 4 graphemes but now with 5 code points.

I believe (well, suspect; I have empirical evidence not proof) Python stores its own identifiers in NFD, so this may not be quite as much of a problem as it might otherwise be.  Nonetheless, I have had users complain about what HFS+ does with such filenames, although I am not quite sure why. I think it?s because they access a file with 4 chars but they need a 5-char fileglob to wildcard it, so touch "caf\N{LATIN SMALL LETTER E WITH ACUTE}" and then you need a wildcard of "?????" with an extra ? to find it. Kinda weird.

----------
nosy: +tchrist

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

From report at bugs.python.org  Fri Aug 12 04:41:16 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 02:41:16 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1313116876.94.0.050147310014.issue2857@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Please do not call this "utf-8-java". It is called "cesu-8" per UTS#18 at:

  http://unicode.org/reports/tr26/

CESU-8 is *not* a a valid Unicode Transform Format and should not be called UTF-8. It is a real pain in the butt, caused by people who misunderand Unicode mis-encoding UCS-2 into UTF-8, screwing it up. I understand the need to be able to read it, but call it what it is, please.

Despite the talk about Lucene, I note that the Perl port of Lucene uses real UTF-8, not CESU-8.

----------
nosy: +tchrist

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

From report at bugs.python.org  Fri Aug 12 05:20:24 2011
From: report at bugs.python.org (Joe Hu)
Date: Fri, 12 Aug 2011 03:20:24 +0000
Subject: [issue12739] read stuck with multithreading and simultaneous
	subprocess.Popen
Message-ID: <1313119224.46.0.971895609334.issue12739@psf.upfronthosting.co.za>


New submission from Joe Hu <sapikachu at gmail.com>:

When multiple threads create child processes simultaneously and redirect their stdout using subprocess.Popen, at least one thread will stuck on reading the stdout after its child process exited, until all other processes are also exited.

The test case reproduces the problem. It's always reproducible on my system (Python 3.1 on Windows 7 x64 / Python 3.2 on Windows 7 x86).

Here is my suspicion: 
When Popen is called by two threads simultaneously, the latter child processes may be started before pipe handles for the former process are closed, causing the handles be incorrectly inherited by the latter process. So these handles can only be closed after all the two processes exit, and only after that, p.stdout.read* can detect EOF and return.

----------
components: Library (Lib), Windows
files: python-subprocess-bug-test-case.py
messages: 141939
nosy: SAPikachu
priority: normal
severity: normal
status: open
title: read stuck with multithreading and simultaneous subprocess.Popen
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22885/python-subprocess-bug-test-case.py

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

From report at bugs.python.org  Fri Aug 12 06:29:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Aug 2011 04:29:27 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1313123367.66.0.727577520886.issue11105@psf.upfronthosting.co.za>


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


----------
nosy: +meador.inge

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

From report at bugs.python.org  Fri Aug 12 07:37:33 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Aug 2011 05:37:33 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1313127453.68.0.429984506529.issue2857@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 for calling it by the correct name (the docs can of course state that this is equivalent to "Java Modified UTF-8" or however they like to call it).

----------

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

From report at bugs.python.org  Fri Aug 12 09:34:42 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 12 Aug 2011 07:34:42 +0000
Subject: [issue12708] multiprocessing.Pool is missing a starmap[_async]()
	method.
In-Reply-To: <1312791706.56.0.0564445111867.issue12708@psf.upfronthosting.co.za>
Message-ID: <1313134482.28.0.163010228802.issue12708@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

No, that's just a helper function like the `mapstar` directly above. args[1] is the iterable with tuples that get unpacked as arguments.

----------

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

From report at bugs.python.org  Fri Aug 12 10:35:03 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 12 Aug 2011 08:35:03 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313138103.68.0.508969979643.issue12721@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Eric, just to be clear: Are you making this list->tuple change or should I fix the patch?

----------

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

From report at bugs.python.org  Fri Aug 12 10:41:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Aug 2011 08:41:01 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QrnIZ-0001P3-Kp@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 683202530137 by Eli Bendersky in branch 'default':
Issue #12672: fix code samples in extending/newtypes.html for PEP-7 compliance
http://hg.python.org/cpython/rev/683202530137

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

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

From report at bugs.python.org  Fri Aug 12 10:41:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:41:36 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313138496.68.0.0543207712155.issue12672@psf.upfronthosting.co.za>


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


----------
keywords:  -easy
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Aug 12 10:43:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:43:43 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313138623.38.0.455349240903.issue12672@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

> Would it be clearer if we replaced the literal with a name?
>
>  These C functions are called ?type methods? to distinguish them from
> - things like [].append (which we call ?object methods?).
> + methods bound to specific instances (things like sys.path.append),
> + which we call ?object methods?.

No, I don't think this is the intention (bound vs. unbound). I think the distinction is between special methods recognized by Python, and "plain object methods" defined by the user. Not sure how to express this clearly in the docs though.

Re PEP-7 cleanup: done some for extending/newtypes.html - not sure everything is fixed but it's a bit better now.

----------

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

From report at bugs.python.org  Fri Aug 12 10:54:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:54:30 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313139270.82.0.442008358841.issue12672@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Maybe it should say:

"... to distinguish them from custom class methods such as list's append"

I think this is more correct, because it clearly refers to the methods placed in the 'tp_methods' field of a type.


... and also drop the (which we call "object methods") since this terminology isn't actually being used in the rest of the article.

----------

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

From report at bugs.python.org  Fri Aug 12 11:00:56 2011
From: report at bugs.python.org (Dolf Andringa)
Date: Fri, 12 Aug 2011 09:00:56 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1313081392.7.0.932097277379.issue5639@psf.upfronthosting.co.za>
Message-ID: <CABkWtfhhDJTi8PShKq4AmNG8ZcGO2c+oseY1XXLoTs6vXxgY_w@mail.gmail.com>


Dolf Andringa <dolfandringa at gmail.com> added the comment:

And python3? Any idea which version the patch will be included there?
This might be a good reason to finally take action on migrating my code from
python 2.7 to python 3.

On 11 August 2011 18:49, Antoine Pitrou <report at bugs.python.org> wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > I see the patch has been applied python3 in r85793, but is there any
> > chance there will also be patches for python 2.6 or 2.7
>
> No, Python 2 only receives bug fixes.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5639>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file22886/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________
-------------- next part --------------
And python3? Any idea which version the patch will be included there?<br>This might be a good reason to finally take action on migrating my code from python 2.7 to python 3.<br><br><br><br><div class="gmail_quote">On 11 August 2011 18:49, Antoine Pitrou <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; I see the patch has been applied python3 in r85793, but is there any<br>
&gt; chance there will also be patches for python 2.6 or 2.7<br>
<br>
</div>No, Python 2 only receives bug fixes.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue5639" target="_blank">http://bugs.python.org/issue5639</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Aug 12 11:52:26 2011
From: report at bugs.python.org (xavierd)
Date: Fri, 12 Aug 2011 09:52:26 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313142746.12.0.801737572233.issue12515@psf.upfronthosting.co.za>


xavierd <xdelannoy at cloudmark.com> added the comment:

This patch does: 
 - when a close boundary isn't found then the error 
'email.errors.CloseBoundaryNotFoundDefect' is added to the defects list.
 - it doesn't modify the current behaviour of the feedparser 
(eg: the function email.message_from_file still modifies the message 
structure)

----------
keywords: +patch
Added file: http://bugs.python.org/file22887/email.patch

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

From report at bugs.python.org  Fri Aug 12 11:53:18 2011
From: report at bugs.python.org (xavierd)
Date: Fri, 12 Aug 2011 09:53:18 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313142798.54.0.438990175741.issue12515@psf.upfronthosting.co.za>


Changes by xavierd <xdelannoy at cloudmark.com>:


Added file: http://bugs.python.org/file22888/orig.eml

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

From report at bugs.python.org  Fri Aug 12 11:54:11 2011
From: report at bugs.python.org (xavierd)
Date: Fri, 12 Aug 2011 09:54:11 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313142851.47.0.553705294099.issue12515@psf.upfronthosting.co.za>


xavierd <xdelannoy at cloudmark.com> added the comment:

with the patch applied: 

{{{
$ ./test.py
PARSER INVALID EMAIL
defects found !
[<email.errors.CloseBoundaryNotFoundDefect instance at 0x7f41421c0488>]
}}}

----------
Added file: http://bugs.python.org/file22889/test.py

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

From report at bugs.python.org  Fri Aug 12 12:26:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Aug 2011 10:26:32 +0000
Subject: [issue2857] add codec for java modified utf-8
In-Reply-To: <1313116876.94.0.050147310014.issue2857@psf.upfronthosting.co.za>
Message-ID: <4E44FFD0.2020303@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tom Christiansen wrote:
> 
> Tom Christiansen <tchrist at perl.com> added the comment:
> 
> Please do not call this "utf-8-java". It is called "cesu-8" per UTS#18 at:
> 
>   http://unicode.org/reports/tr26/
> 
> CESU-8 is *not* a a valid Unicode Transform Format and should not be called UTF-8. It is a real pain in the butt, caused by people who misunderand Unicode mis-encoding UCS-2 into UTF-8, screwing it up. I understand the need to be able to read it, but call it what it is, please.
> 
> Despite the talk about Lucene, I note that the Perl port of Lucene uses real UTF-8, not CESU-8.

CESU-8 is a different encoding than the one we are talking about.

The only difference between UTF-8 and the modified one is the different
encoding for the U+0000 code point to have the output not contain
any NUL bytes.

----------

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

From report at bugs.python.org  Fri Aug 12 12:50:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 10:50:13 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1313146213.86.0.95275429159.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> And python3? Any idea which version the patch will be included there?

It was included in Python 3.2.

----------
versions:  -Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Aug 12 13:33:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 12 Aug 2011 11:33:27 +0000
Subject: [issue12740] Add struct.Struct.nmemb
Message-ID: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

It is somewhat complicated to calculate the number of members in
a Struct, so I propose to add Struct.nmemb (in 3.3, 3.2 and 2.7):

>>> import struct
>>> s = struct.Struct("Pxx3Lxxxx3s")
>>> s.size
47
>>> s.nmemb
5


I chose 'nmemb' because it is a standard name in Unix man pages.
Another option would be to spell it out ('nmembers').

----------
components: Library (Lib)
files: struct_nmemb.diff
keywords: needs review, patch
messages: 141951
nosy: mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Add struct.Struct.nmemb
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22890/struct_nmemb.diff

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

From report at bugs.python.org  Fri Aug 12 14:41:05 2011
From: report at bugs.python.org (David Townshend)
Date: Fri, 12 Aug 2011 12:41:05 +0000
Subject: [issue12741] Implementation of shutil.move
Message-ID: <1313152865.62.0.69696851164.issue12741@psf.upfronthosting.co.za>


New submission from David Townshend <aquavitae69 at gmail.com>:

The shutil.move function uses os.rename to move files on the same file system. On unix, this function will overwrite an existing destination, so the obvious approach is

if not os.path.exists(dst):
    shutil.move(src, dst)

But this could result in race conditions if dst is created after os.path.exists and before shutil.move.  From my research, it seems that this is a limitation in the unix c library, but it should be possible to avoid it through a workaround (pieced together from http://bytes.com/topic/python/answers/555794-safely-renaming-file-without-overwriting ).  This involves some fairly low-level work, so I propose adding a new move2 function to shutil, which raises an error if dst exists and locking it if it doesn't:

def move2(src, dst):
    try:
        fd = os.open(dst, os.O_EXCL | os.O_CREAT)
    except OSError:
        raise Error('Destination exists')
    try:
        move(src, dst)
    finally:
        os.close(fd)

This could be optimised by using shutil.move code rather than just calling it, but the idea is that an attempt is made to create dst with exclusive access. If this fails, then it means that the file exists, but if it passes, then dst is locked so no other process can create it.

As suggested on the mailing list (http://mail.python.org/pipermail/python-ideas/2011-August/011132.html), an alternative is to add this behaviour as an argument to shutil.move, which may be a neater solution.  

I will work on a patch for this and try to submit it in the next few days.

----------
components: Library (Lib)
messages: 141952
nosy: David.Townshend
priority: normal
severity: normal
status: open
title: Implementation of shutil.move
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Aug 12 15:13:09 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 13:13:09 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313154789.8.0.706204250393.issue11230@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Whoops, I meant that it appears that Python runs its identifiers through NFC.  How that gets along with a filesystem that has quasi-NFD filenames I'm not sure, but it seems like it might be a variant of the case-insensitivity issue in filenames.

----------

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

From report at bugs.python.org  Fri Aug 12 15:14:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Aug 2011 13:14:43 +0000
Subject: [issue2857] Add CESU-8 codec ("java modified utf-8")
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1313154883.6.0.782480454215.issue2857@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: add codec for java modified utf-8 -> Add CESU-8 codec ("java modified utf-8")

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

From report at bugs.python.org  Fri Aug 12 15:18:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Aug 2011 13:18:18 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313155098.08.0.592683077737.issue11230@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The issue I'm thinking about is that the Mac HSF+ filesystem

There is no issue with HFS+ normalization. The kernel "normalizes" filenames to its own variant, Python doesn't have to care about this.

When you write "import h<? normalized to NFC>" or "import h<? normalized to NFD>", Python tries to open "h<? normalized to NFC>.py": then the HFS+ filename does its own normalization (=> "h<? normalized to its variant of NFD>.py").

----------

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

From report at bugs.python.org  Fri Aug 12 15:35:03 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Aug 2011 13:35:03 +0000
Subject: [issue2857] Add "java modified utf-8" codec
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1313156103.52.0.26337669865.issue2857@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Corrected the title again. See my comment.

----------
title: Add CESU-8 codec ("java modified utf-8") -> Add "java modified utf-8" codec
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 12 15:44:07 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Aug 2011 13:44:07 +0000
Subject: [issue2857] Add "java modified utf-8" codec
In-Reply-To: <1313156103.52.0.26337669865.issue2857@psf.upfronthosting.co.za>
Message-ID: <4E452E1F.4010309@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Corrected the title again. See my comment.

Please open a new ticket, if you want to add a CESU-8 codec.

Looking at the relevant use cases, I'm at most +0 on adding the
modified UTF-8 codec. I think such codecs can well live outside
the stdlib on PyPI.

----------

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

From report at bugs.python.org  Fri Aug 12 15:57:58 2011
From: report at bugs.python.org (Adal Chiriliuc)
Date: Fri, 12 Aug 2011 13:57:58 +0000
Subject: [issue2857] Add "java modified utf-8" codec
In-Reply-To: <1210820919.45.0.733381289954.issue2857@psf.upfronthosting.co.za>
Message-ID: <1313157478.61.0.748220418159.issue2857@psf.upfronthosting.co.za>


Adal Chiriliuc <adal.chiriliuc at gmail.com> added the comment:

Python does have other "weird" encodings like bz2 or rot13.

Beside, batteries included :)

----------

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

From report at bugs.python.org  Fri Aug 12 16:01:39 2011
From: report at bugs.python.org (Adal Chiriliuc)
Date: Fri, 12 Aug 2011 14:01:39 +0000
Subject: [issue12742] Add support for CESU-8 encoding
Message-ID: <1313157699.02.0.414540020258.issue12742@psf.upfronthosting.co.za>


New submission from Adal Chiriliuc <adal.chiriliuc at gmail.com>:

CESU-8 is identical with UTF-8 except that it has a different encoding format for surrogate characters.

http://en.wikipedia.org/wiki/CESU-8

It is used by some web APIs.

----------
components: Unicode
messages: 141958
nosy: adalx
priority: normal
severity: normal
status: open
title: Add support for CESU-8 encoding
type: feature request
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 12 16:43:03 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 12 Aug 2011 14:43:03 +0000
Subject: [issue12743] C API marshalling doc contains XXX
Message-ID: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>


New submission from JJeffries <jamesjeffries1 at gmail.com>:

The Python C API manual page for data marshaling contains the following paragraph.

XXX What about error detection? It appears that reading past the end of the file will always result in a negative numeric value (where that?s relevant), but it?s not clear that negative values won?t be handled properly when there?s no error. What?s the right way to tell? Should only non-negative values be written using these routines?

I suggest that the XXX should be removed as it is unclear why it's there.

Patch to follow in the next couple of days if others agree.

----------
assignee: docs at python
components: Documentation
messages: 141959
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: C API marshalling doc contains XXX

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

From report at bugs.python.org  Fri Aug 12 16:47:44 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 12 Aug 2011 14:47:44 +0000
Subject: [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1313160464.74.0.302486380395.issue12195@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

While I understand the reluctance to unintentionally push people along a particular path, but I think there is being open on how to use it and not mentioning it. I think that currently the current documentation is the latter and some simple examples showing the syntax would go a long way.

Most of my understanding of annotations has come from the PEP for it and mailing lists.

----------

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

From report at bugs.python.org  Fri Aug 12 17:25:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 15:25:24 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313162724.8.0.409535859832.issue12672@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think the distinction is between special methods recognized by
> Python, and "plain object methods" defined by the user.

Do you mean __special__ methods?  Re-reading the whole paragraph, I can?t tell :(

----------

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

From report at bugs.python.org  Fri Aug 12 17:25:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 15:25:52 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313162752.06.0.565509347415.issue12721@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?I?ll make one change before committing? :)

----------

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

From report at bugs.python.org  Fri Aug 12 17:38:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 15:38:33 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313163513.15.0.42319874451.issue12672@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug 12 18:03:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Aug 2011 16:03:55 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <E1QruDB-00087V-QW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8032ea4c3619 by ?ric Araujo in branch '3.2':
Test pipes.quote with a few non-ASCII characters (see #9723).
http://hg.python.org/cpython/rev/8032ea4c3619

New changeset 6ae0345a7e29 by ?ric Araujo in branch 'default':
Avoid unwanted behavior change in shlex.quote (see #9723).
http://hg.python.org/cpython/rev/6ae0345a7e29

----------

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

From report at bugs.python.org  Fri Aug 12 18:05:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:05:03 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1313165103.51.0.823935411073.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have restored compatibility (see commit messages).

----------
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Aug 12 18:08:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:08:20 +0000
Subject: [issue9999] test_shutil cross-file-system tests are fragile (may not
	test what they purport to test)
In-Reply-To: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>
Message-ID: <1313165300.42.0.455868267961.issue9999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Unfortunately I don't currently have a suggestion for how to reliably
> create a cross-file-system link for testing purposes.

We could try walking a list of common mount points (/run, /dev, /tmp, /home, etc.), compiled from as many OSes as possible, and filter it with os.path.ismount to see if we have more than one partition.

----------

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

From report at bugs.python.org  Fri Aug 12 18:08:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:08:39 +0000
Subject: [issue9773] test_tarfile fails because of inaccurate mtime on AMD64
	debian parallel buildbot
In-Reply-To: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>
Message-ID: <1313165319.49.0.850347267093.issue9773@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/issue9773>
_______________________________________

From report at bugs.python.org  Fri Aug 12 18:09:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:09:55 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1313165395.84.0.138215667599.issue12715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Other reports related to shutil and symlinks: #9993, #4489, #12461.

----------

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

From report at bugs.python.org  Fri Aug 12 18:17:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:17:16 +0000
Subject: [issue12712] weave build_tools library identification
In-Reply-To: <1312822380.43.0.720864294913.issue12712@psf.upfronthosting.co.za>
Message-ID: <1313165836.8.0.359566872832.issue12712@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> When running the program,
Which program? :)  To see if this is a bug in Python (i.e. in distutils), it would be helpful if you could provide the simplest possible code that triggers the error.

> it looks for an installed version of MinGW, which it finds.  It is
> possibly looking for C:\Python27\lib\distutils\core.py in the wrong
> location (the "Lib" should be capitalized?)
I think there is another report about that.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug 12 18:20:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:20:09 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313166009.04.0.240711140558.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Interesting idea.  I know that with Mercurial for example, I use abbreviations and aliases all the time.  Note that argparse already has aliases (or there is an open feature request about it).

Steven: What do you think of this request?

----------
nosy: +bethard, eric.araujo
versions: +Python 3.3

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

From report at bugs.python.org  Fri Aug 12 18:20:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:20:30 +0000
Subject: [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1313166030.16.0.677381263816.issue12716@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug 12 18:22:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:22:22 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313166142.78.0.275424430363.issue12725@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.3 -Python 2.6

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

From report at bugs.python.org  Fri Aug 12 18:25:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:25:45 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1313166345.85.0.209234362792.issue11233@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If no-one else has started on this, I?m interested in making a patch to introduce an availability directive.

----------
nosy: +eric.araujo
resolution: works for me -> 
stage:  -> needs patch

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

From report at bugs.python.org  Fri Aug 12 18:26:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 16:26:24 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
Message-ID: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On a 64-bit Linux machine (where C `long` is 64 bits):

>>> len(pickle.dumps(2**30))
8
>>> len(pickle.dumps(2**31))
16
>>> len(pickle.dumps(2**62))
25
>>> len(pickle.dumps(2**63))
14

This is because the old text protocol is used when the integer can fit in a C long but not in 4 bytes:

>>> pickletools.dis(pickle.dumps(2**62))
    0: \x80 PROTO      3
    2: L    LONG       4611686018427387904
   24: .    STOP
highest protocol among opcodes = 2
>>> pickletools.dis(pickle.dumps(2**63))
    0: \x80 PROTO      3
    2: \x8a LONG1      9223372036854775808
   13: .    STOP
highest protocol among opcodes = 2

----------
components: Library (Lib)
messages: 141971
nosy: pitrou
priority: normal
severity: normal
status: open
title: inefficient pickling of long integers on 64-bit builds
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug 12 18:28:48 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Aug 2011 16:28:48 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <1313166528.11.0.612265161452.issue12744@psf.upfronthosting.co.za>


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


----------
nosy: +meador.inge

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

From report at bugs.python.org  Fri Aug 12 18:39:08 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Aug 2011 16:39:08 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <1313167148.89.0.942963627918.issue12744@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch

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

From report at bugs.python.org  Fri Aug 12 18:43:11 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 12 Aug 2011 16:43:11 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1313167391.94.0.893817447673.issue12735@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Fri Aug 12 18:43:18 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 12 Aug 2011 16:43:18 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <1313167398.51.0.0179231112049.issue12732@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Fri Aug 12 18:50:28 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Aug 2011 16:50:28 +0000
Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on
	Ubuntu 11.04
In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za>
Message-ID: <1313167828.12.0.666020599989.issue12738@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Michael,

It is hard to tell from your description alone where the bug is.  Could you provide more detailed reproduction steps with a test case that exhibits the issue?

----------
nosy: +jnoller, meador.inge
stage:  -> test needed

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

From report at bugs.python.org  Fri Aug 12 18:55:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:55:23 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1313168123.69.0.38830809068.issue10087@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There were comments by Ezio and me on Rietveld.

Also, the commit adds a period after the help text for --encoding, but all other help text aren?t capitalized and don?t use periods, as is usual in help messages.

----------

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

From report at bugs.python.org  Fri Aug 12 19:30:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:30:15 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1313170215.77.0.613454723883.issue12736@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Interpreter Core, Unicode -Library (Lib)
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Aug 12 19:31:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:31:33 +0000
Subject: [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1313170293.74.0.0405794255528.issue12743@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It should be removed if someone is confident that it?s a obsolete comment, or if tests get added to answer the questions in the note.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug 12 19:32:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:32:14 +0000
Subject: [issue12742] Add support for CESU-8 encoding
In-Reply-To: <1313157699.02.0.414540020258.issue12742@psf.upfronthosting.co.za>
Message-ID: <1313170334.26.0.669284700818.issue12742@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib)
nosy: +lemburg
versions: +Python 3.3 -Python 3.4

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

From report at bugs.python.org  Fri Aug 12 19:37:48 2011
From: report at bugs.python.org (Philip Douglass)
Date: Fri, 12 Aug 2011 17:37:48 +0000
Subject: [issue9176] module termios doesn't build on HP-UX
In-Reply-To: <1278409886.91.0.742762759895.issue9176@psf.upfronthosting.co.za>
Message-ID: <1313170668.62.0.627785661225.issue9176@psf.upfronthosting.co.za>


Philip Douglass <philip at philipdouglass.com> added the comment:

Workaround for this issue: Add -D_TERMIOS_INCLUDED to your CFLAGS/CPPFLAGS environment variables to successfully compile termios.

----------
nosy: +philipsd6

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

From report at bugs.python.org  Fri Aug 12 19:39:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:39:32 +0000
Subject: [issue12741] Add function similar to shutil.move that does not
	overwrite
In-Reply-To: <1313152865.62.0.69696851164.issue12741@psf.upfronthosting.co.za>
Message-ID: <1313170772.45.0.47993307646.issue12741@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

About new function vs. new argument: this could be asked on python-dev (or on the core-mentorship list if you prefer an environment guaranteed friendly).  If you look at copy and copy2, you?ll see that adding a function was chosen, but the names are not helpful at all.  In more recent shutil development, arguments like copy_function and ignore (on copytree) were added to let people customize behavior without rewriting all the function logic.  Guido van Rossum has a rule about not adding an argument when the value is always a constant, preferring another function instead, but I?m not sure I remember it clearly, so asking for other developers? thoughts would be good.

----------
nosy: +eric.araujo
stage:  -> needs patch
title: Implementation of shutil.move -> Add function similar to shutil.move that does not overwrite
type: behavior -> feature request
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Aug 12 19:46:23 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 17:46:23 +0000
Subject: [issue12705] Make compile('1\n2\n', '',
	'single') raise an exception instead of silently truncating?
In-Reply-To: <1312681191.75.0.586407900237.issue12705@psf.upfronthosting.co.za>
Message-ID: <1313171183.08.0.347425684804.issue12705@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Pending an argument against, I agree with the change.
I think SyntaxError would be best. ValueError (etc) is for runtime (though this is compile during runtime).

What would you have for the error message? My first idea is
"Cannot compile multiple statements as a single statement."
This should be clear enough when calling compile(...'single').
It should at least give a hint in the doctest case.

----------
nosy: +terry.reedy
stage:  -> test needed
type:  -> feature request

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

From report at bugs.python.org  Fri Aug 12 19:47:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 17:47:28 +0000
Subject: [issue12706] timeout sentinel in ftplib and poplib documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1313171248.68.0.0109037885939.issue12706@psf.upfronthosting.co.za>


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


----------
components: +Documentation

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

From report at bugs.python.org  Fri Aug 12 19:56:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Aug 2011 17:56:03 +0000
Subject: [issue12032] Tools/Scripts/crlf.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <E1Qrvxh-0001Mr-DU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47ffb957921d by ?ric Araujo in branch '3.2':
Update crlf and lfcr scripts for 3.x bytes semantics (#12032).
http://hg.python.org/cpython/rev/47ffb957921d

----------

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

From report at bugs.python.org  Fri Aug 12 19:56:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Aug 2011 17:56:03 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <E1Qrvxh-0001Mr-Dd@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d52a1199d3f0 by ?ric Araujo in branch 'default':
Clean up test_shutil, to facilitate upcoming improvements (#12721).
http://hg.python.org/cpython/rev/d52a1199d3f0

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

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

From report at bugs.python.org  Fri Aug 12 19:56:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:56:16 +0000
Subject: [issue12726] explain why locale.getlocale() does not read system's
	locales
In-Reply-To: <1313054335.82.0.864365511342.issue12726@psf.upfronthosting.co.za>
Message-ID: <1313171776.46.0.652049459892.issue12726@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python, eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 12 19:57:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:57:45 +0000
Subject: [issue12032] Tools/Scripts/crlf.py needs updating for python 3+
In-Reply-To: <1304873731.64.0.0794547908346.issue12032@psf.upfronthosting.co.za>
Message-ID: <1313171865.64.0.469110860592.issue12032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Aug 12 20:01:36 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:01:36 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1313172096.47.0.0639551788661.issue12728@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/issue12728>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:02:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 18:02:07 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313172127.45.0.850077937766.issue12721@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made more changes (see the changeset) and committed only to 3.3, as we try to refrain from cleanup/cosmetic changes in stable branches (you never know what will cause a bug), and as you wanted this cleanup prior to work on a 3.3-only patch.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 12 20:02:37 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:02:37 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313172157.0.0.375424165763.issue12729@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/issue12729>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:02:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:02:56 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313172176.89.0.685218536011.issue12730@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/issue12730>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:03:10 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:03:10 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313172190.12.0.417744432717.issue12731@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/issue12731>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:03:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 18:03:17 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313172197.24.0.168690906889.issue11564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch contains assorted improvements for 64-bit compatibility of the pickle module. The protocol still doesn't support >4GB bytes or str objects, but at least its behaviour shouldn't be misleading anymore.

----------
keywords: +patch
stage:  -> patch review
versions:  -Python 3.1
Added file: http://bugs.python.org/file22891/pickle64.patch

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

From report at bugs.python.org  Fri Aug 12 20:03:32 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:03:32 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <1313172212.3.0.530068370212.issue12732@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/issue12732>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:03:52 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:03:52 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1313172232.12.0.810782083231.issue12733@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/issue12733>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:04:58 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:04:58 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313172298.39.0.790600532809.issue12734@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/issue12734>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:05:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:05:23 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1313172323.09.0.800268268928.issue12735@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/issue12735>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:05:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 18:05:36 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1313172336.07.0.100649925601.issue12733@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Aug 12 20:05:57 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:05:57 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1313172357.48.0.391119883356.issue12736@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/issue12736>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:06:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 18:06:11 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313172371.84.0.0413077272843.issue12734@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Aug 12 20:06:18 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 12 Aug 2011 18:06:18 +0000
Subject: [issue12737] string.title() is overzealous by upcasing combining
	marks inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313172378.86.0.672083184039.issue12737@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/issue12737>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:06:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 18:06:31 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1313172391.19.0.492612261288.issue12735@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Aug 12 20:11:40 2011
From: report at bugs.python.org (Michael Hall)
Date: Fri, 12 Aug 2011 18:11:40 +0000
Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on
	Ubuntu 11.04
In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za>
Message-ID: <1313172700.02.0.233501561832.issue12738@psf.upfronthosting.co.za>


Michael Hall <michaelhall1k at gmail.com> added the comment:

Okay, I have attached the code I've been using. Don't worry about what it does (it's a biology thing), but just follow these steps:

1. Make sure you have numpy and scipy installed.
2. Extract the zip file.
3. Run it with ./svm_main.py test_obligate.dat test_transient.dat

The method svm_main.grid_search and the module grid_search_process are probably the only things you need pay attention to, everything else is problem-specific.

----------
Added file: http://bugs.python.org/file22892/test_case.zip

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

From report at bugs.python.org  Fri Aug 12 20:12:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:12:07 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1313172727.51.0.697095413318.issue12711@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While I could question the current list of components, documenting it as it is is a good idea. Patch 2 looks pretty good to me with the following change.

Tests
    The generic unittest and doctest frameworks in `Lib/unittest`_ and
    `Lib/doctest.py`_.
    The Python interpreter tests in `Lib/test`_, the test runner in
    `Lib/test/regrtest.py`_, and the `Lib/test/support.py`_ module.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Aug 12 20:13:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:13:20 +0000
Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom
	validation functions
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313172800.69.0.945388787792.issue12723@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/issue12723>
_______________________________________

From report at bugs.python.org  Fri Aug 12 20:22:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:22:29 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313173349.06.0.882343515406.issue12725@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree 'floating seconds' is bad. I think I prefer your second alternative, but settimeout() and setdefaulttimeout should be consistent.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Aug 12 20:26:57 2011
From: report at bugs.python.org (Matthew Hemke)
Date: Fri, 12 Aug 2011 18:26:57 +0000
Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom
	validation functions
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313173617.61.0.404517969073.issue12723@psf.upfronthosting.co.za>


Matthew Hemke <mghemke at gmail.com> added the comment:

I'm not sure if I misunderstood you, or you misunderstood me, but adding an option to the askstring dialog that would take a function handle would also allow you to use it for things other than strings (ints,etc.)

Tkinter Entry does this: you set the validatecommand option to a function handle that returns true or false to determine whether the input was valid.

I will try and code an example over the weekend.

----------

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

From report at bugs.python.org  Fri Aug 12 20:58:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:58:25 +0000
Subject: [issue12726] explain that locale.getlocale() does not read system's
	locales
In-Reply-To: <1313054335.82.0.864365511342.issue12726@psf.upfronthosting.co.za>
Message-ID: <1313175505.38.0.302325792409.issue12726@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Our docs explain behavior without, generally, explaining why. Hence the title change.

'Returns the current setting for the given locale category' seems pretty clear that it returns the current program setting rather than the default system setting. However, 'program' could be added to be clearer.

The previous discussion for locale.getdefaultlocale makes it clear that the starting program locale is (should be) the "portable 'C' locale". I presume you are saying that in this locale, the setting for the default LC_CTYPE category is (None,None). However, this appears to currently only be true for 2.7. So I suppose we could add for 2.7 "In the starting 'C' locale, the LC_CTYPE setting is (None,None)." (Given the next paragraph describing 'C' as a non-standard language code, I would have expected ('C',None), but it is as it is.)

Reading #6203, something different is needed for 3.2 and something else again might be needed for 3.3 depending on what is or is not done.

----------
nosy: +terry.reedy
title: explain why locale.getlocale() does not read system's locales -> explain that locale.getlocale() does not read system's locales

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

From report at bugs.python.org  Fri Aug 12 21:28:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 19:28:49 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1313177329.06.0.777738734656.issue12728@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not sure that everyone will agree that this is a bug, rather than a feature request, or that if a bug, that it should be changed in existing releases and possibly break running code. The doc just says, somewhat vaguely, that IGNORECASE "works for Unicode characters as expected". I have added others as nosy for their opinions.

The test file should have omitted the gratuitous and distracting warnings, especially the one that effectively scolds Windows users for running Windows. With those omitted, the test cases given would form the basis for an added TestCase.

----------
nosy: +lemburg, loewis, pitrou, terry.reedy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 12 22:09:32 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 20:09:32 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313177329.06.0.777738734656.issue12728@psf.upfronthosting.co.za>
Message-ID: <25262.1313179759@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

> Terry J. Reedy <tjreedy at udel.edu> added the comment:

> I am not sure that everyone will agree that this is a bug, rather than a fe=
> ature request, or that if a bug, that it should be changed in existing rele=
> ases and possibly break running code. The doc just says, somewhat vaguely, =
> that IGNORECASE "works for Unicode characters as expected". I have added ot=
> hers as nosy for their opinions.

Working as expected for Unicode characters means it must the Unicode's
rules for casefolding.  Otherwise you don't have Unicode at all; you just 
have ISO 10646.  Unicode is not merely a larger character repertoire; again,
that is merely ISO 10646.  Unicode is all about the rules for processing this
larger repertoire.  This is a very common mistake, so common that it is in the 
Unicode FAQ:

    Q: What is the relation between ISO/IEC 10646 and Unicode?

    A: In 1991, the ISO Working Group responsible for ISO/IEC 10646 (JTC
       1/SC 2/WG 2) and the Unicode Consortium decided to create one
       universal standard for coding multilingual text. Since then, the
       ISO 10646 Working Group (SC 2/WG 2) and the Unicode Consortium
       have worked together very closely to extend the standard and to
       keep their respective versions synchronized. [EH]

    Q: So are they the same thing?

    A: No. Although the character codes and encoding forms are
       synchronized between Unicode and ISO/IEC 10646, the Unicode
       Standard imposes additional constraints on implementations to
       ensure that they treat characters uniformly across platforms and
       applications. To this end, it supplies an extensive set of
       functional character specifications, character data, algorithms
       and substantial background material that is *not* in ISO/IEC 10646.

    http://unicode.org/faq/unicode_iso.html

Part of those functional character specifications can be found in the three
casefolding fields of the file UnicodeData.txt and also in two auxiliary
files of the Unicode distribution, CaseFolding.txt and SpecialCasing.txt.
The Unicode Character Database is not optional.  If you do not use it, you
do not have Unicode; instead you merely have ISO 10646, which is of zero
practical use to anyone compared with Unicode.  I'm sure that Python would
not want to be stuck having something of no use to anyone when everyone
else actually supports Unicode.

One is not allowed to make up one's own rules that run counter to Unicode's
and still make the claim that one is working on Unicode, since that is in
fact not what one is doing.  Based on all that, Python does not do case
insensitive matching on Unicode, a condition contrary to its documented
claims.  That clearly makes it a bug that needs fixing rather than a 
feature request to be summarily ignored.

> The test file should have omitted the gratuitous and distracting warnings, =
> especially the one that effectively scolds Windows users for running Window=
> s. With those omitted, the test cases given would form the basis for an add=
> ed TestCase.

I have absolutely no idea what on earth you could possibly be referring to.
Honestly.  I ran my tests on both releases (2.7 and 3.2), on both builds
(wide and narrow), and on both platforms (Unix and Mac).  The warnings are
in there so I can make sure I have everything set up correctly to run the 
tests, and will understand why I get more failures than expected in the event 
that things are not set up appropriately.

Let me make perfectly clear that I have never in my life come anywhere near a
Microsoft system, let alone touched one, and that I furthermore never shall.  
I have not the foggiest notion what in the world you are complaining about.
If the problem is that you are for some reason unable to create a Python with
full Unicode support under Microsoft, that is hardly my fault.   Render unto
Caesar that which is Caesar's: complain to Microsoft about Microsoft's bugs,
not to me, as I am wholly blameless of their problems.

If you don't like my test cases, you know where to find vi.  

I supposed I could always send you the program that writes these programs
for me, but as I knew you won't like it, I withheld it.  You already have
all that you need to see exactly where the bugs are and how to fix them.

--tom

----------

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

From report at bugs.python.org  Fri Aug 12 22:23:06 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Aug 2011 20:23:06 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1313180586.51.0.855322514897.issue11241@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Amaury, how about this patch?  I got rid of querying the type dictionary and hoisted the creation of the type instance earlier.  Then 'PyObject_GetAttrString' can be used to lookup '_length_' and '_type_' by the regular Python attribute lookup rules.  I extended the test cases to cover more error paths as well.

----------
Added file: http://bugs.python.org/file22893/issue11241.patch

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

From report at bugs.python.org  Fri Aug 12 23:00:24 2011
From: report at bugs.python.org (Peter Saveliev)
Date: Fri, 12 Aug 2011 21:00:24 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1313182824.6.0.616220767263.issue11866@psf.upfronthosting.co.za>


Peter Saveliev <svinota.saveliev at gmail.com> added the comment:

Any news? I hope, the change is trivial enough?

----------

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

From report at bugs.python.org  Sat Aug 13 00:07:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 22:07:32 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313186852.77.0.72626635903.issue12730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that better masking of narrow-wide build difference would be good as long as it does not severely impact normal performance. Revision of the test file (see below) shows that the 'bug' is that the .upper, .lower, and .title methods leaves the tested non-BMP chars unchanged on narrow builds.

I am not sure if this is true of all upper-plane chars and whether this is by design or simply a matter of not catching up to an ever-expanding database. Hence, I am also not sure whether this is a bug report or feature request.

I made several changes in casemap.python so I could run it and get better information:
* Rename to casemap.py. Many of us use software that recognizes and special-cases the standard .py extension. All python code files uploaded should use this.
* Remove the unused 3-rd party regex import which stops the test for most people.
* Remove the unnecessary PYTHONIOENCODING exit which stop the test on Windows and possibly elsewhere. The file seems to run fine without it.
* Rewrite the test data using \Uxxxxxxxx (8 hex chars) escapes for the non-BMP chars. That will be required for new tests for test_unicode.py. (I believe the test suite avoid literal non-ascii chars unless really necessary.) Besides which, all I see (on Windowsj) in Firefox is things like
"????????????????????????????". IDLE just has empty boxes.
* Factor the tests so the output is easier to rewrite.
* Rewrite the test output to make comparisons easier. Writing the 'wrong' answer first, directly under the original, made it easy to see that the 'wrong' answer *is* the original, unchanged.

The revised version (to be uploaded separately) has the same 6 failures.

----------
nosy: +haypo, lemburg, loewis, terry.reedy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 13 00:09:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 22:09:52 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313186992.3.0.169141073979.issue12730@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file22894/casemaps.py

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

From report at bugs.python.org  Sat Aug 13 00:21:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 22:21:59 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313187719.71.0.775803768006.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Does the regex module handle these particular issues better?

----------
nosy: +terry.reedy
type: behavior -> feature request
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Sat Aug 13 00:46:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 22:46:49 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313189209.05.0.770306685789.issue12731@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

However desireable it would be, I do not believe there is any claim in the manual that the re module follows the evolving Unicode consortium r.e. standard. If I understand, you are saying that this statement in the doc, "Matches Unicode word characters;" is not now correct and should be revised. Was it once correct? Could we add "by an older definition of 'word' character"?

There has been some discussion of adding regex to the stdlib, possibly as a replacement for re. You posts indicate that regex is more improved then some realized, and hence has more incompatibilities that we realized, and hence is less suitable as a strictly backwards-compatible replacement. So I think it needs to be looked at as a parallel addition. I do not know Mathew's current position on the subject.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou, terry.reedy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 13 00:52:14 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Aug 2011 22:52:14 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1313189534.64.0.0883877325493.issue11866@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Are you sure that counter.next() cannot release the GIL?  Remember that any DECREF can trigger the garbage collector and execute arbitrary code...

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sat Aug 13 01:04:54 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 23:04:54 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313187719.71.0.775803768006.issue12729@psf.upfronthosting.co.za>
Message-ID: <3138.1313190285@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

"Terry J. Reedy" <report at bugs.python.org> wrote
   on Fri, 12 Aug 2011 22:21:59 -0000: 

> Does the regex module handle these particular issues better?

No, it currently does not.  One would have to ask Matthew directly, but I
believe it was because he was trying to stay compatible with re, sometimes
apparently even if that means being bug compatible.  I have brought it 
to his attention though, and at last report he was pondering the matter.

In contrast to how Python behaves on narrow builds, even though Java uses
UTF-16 for its internal representation of strings, its Java Pattern is
quite adamant about treating with logical code points alone.  Besides
running afoul of tr18, it is senseless to do otherwise.  A dot is one
Unicode code point, no matter whether you have 8-bit code units, 16-bit
code units, or 32-bit code units.  Similarly, character classes and their
negations only match entire code points, never pieces of the same.

ICU's regexes work the same way the normal Java Pattern library does.  
So too do Perl, Ruby, and Go.  Python is really the odd man out here.  

Almost.

One interesting counterexample is the vim editor.  It has dot match a
complete grapheme no matter how many code points that requires, because
we're dealing with user-visible characters now, not programmer-visible one.

It is an unreasonable burden to make the programmer deal with the
fine-grained details of low-level serialization schemes instead of at
least(*) the code point level of operations, which is the minimum for
getting real work done.  (*Note that tr18 admits that accessing text at the
code point level meets only programmer expectations, not those of the user,
and therefore to meet user expectations much more elaborate patterns must
necessarily be constructed than if logical groups of coarser granularity
than code points alone are supported.)

Python should not be subject to changing its behavior from one build to the
next.  This astonishing narrow-vs-wide build behavior makes it virtually
impossible to write portable code to work on arbitrary Unicode text. You
cannot even know whether you need to match one dot or two to get a single
code point, and similarly for character indexing, etc. Even identifiers
come into play.  Surrogates should be utterly nonexistent/invisible at
this, the normal level of operation.  

An API that minimally but uniformly deals with logical code points and
nothing finer in granularity is the only way to go here.  Please trust me
on this one.  Graphemes (tr18 Level 2) and collation elements (Level 3)
will someday build on that, but one must first support code points
properly. That's why it's a Level 1 requirement.

--tom

----------

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

From report at bugs.python.org  Sat Aug 13 01:05:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 23:05:27 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <1313190327.69.0.0023174222472.issue12732@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ouch!
Do the rejected characters qualify as identifier characters as defined in Reference 2.3 Identifiers and keywords?
http://docs.python.org/py3k/reference/lexical_analysis.html#identifiers
If some interpreter version accepts extra characters, beyond the definition (as happened in 2.x), it is not a bug for for another version to only accept what is defined.

Side question: That section has "A non-normative HTML file listing all valid identifier characters for Unicode 4.1 can be found at http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html." Is the set of identifier characters now larger, and if so, has the table been enlarged?

----------
nosy: +haypo, lemburg, loewis, terry.reedy
stage:  -> needs patch

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

From report at bugs.python.org  Sat Aug 13 01:21:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Aug 2011 23:21:02 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1313191262.35.0.881232463275.issue9723@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

-_find_unsafe = re.compile(r'[^\w\d@%_\-\+=:,\./]').search
+_find_unsafe = re.compile(r'[^\w@%\-\+=:,\./]', re.ASCII).search

FWIW there are still unnecessary escapes before '+' and '.', and possibly '-' ('-' doesn't need escaping only when it's at the end (or beginning) of the regex).

----------

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

From report at bugs.python.org  Sat Aug 13 01:30:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 23:30:41 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313191841.88.0.741117305061.issue12737@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I changed the title because 'string' is a module that once contained the functions that are now attached to the str class as methods. So 'string.title' is an obsolete attribute reference.

----------
nosy: +terry.reedy
title: string.title()  is overzealous by upcasing combining marks inappropriately -> str.title()  is overzealous by upcasing combining marks inappropriately

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

From report at bugs.python.org  Sat Aug 13 01:47:35 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 12 Aug 2011 23:47:35 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313192855.73.0.64918411163.issue12672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Eli, I interpreted it the same way you did.  In the doc, "type methods" are those that map directly to PyTypeObject.  Any custom type methods go in tp_methods.  You could almost call the former "PyTypeObject methods" rather than "type methods".  And both are distinct from functions/methods in a type's __dict__...

Also I agree that the "object methods" statement is unnecessary.

----------
nosy: +ericsnow

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

From report at bugs.python.org  Sat Aug 13 01:48:49 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 12 Aug 2011 23:48:49 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313192929.69.0.13321920708.issue12672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

http://docs.python.org/dev/extending/newtypes.html

----------

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

From report at bugs.python.org  Sat Aug 13 02:18:23 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 13 Aug 2011 00:18:23 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313189209.05.0.770306685789.issue12731@psf.upfronthosting.co.za>
Message-ID: <27372.1313194678@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

> Terry J. Reedy <tjreedy at udel.edu> added the comment:

> However desireable it would be, I do not believe there is any claim in the =
> manual that the re module follows the evolving Unicode consortium r.e. stan=

My from the hip thought is that if re cannot be fixed to follow
the Unicode Standard, it should be deprecated in favor of code
that can if such is available, because you cannot process Unicode
text with regular expressions otherwise.

> dard. If I understand, you are saying that this statement in the doc, "Matc=
> hes Unicode word characters;" is not now correct and should be revised. Was=
>  it once correct? Could we add "by an older definition of 'word' character"=
> ?

Yes, your hunch is exactly correct.  They once had a lesser definition that
they have now.  It is very very old.  I had to track this down for Java
once.  There is some discussion of a "word_character class" at least 
as far back as tr18v3 from back in 1998.

    http://www.unicode.org/reports/tr18/tr18-3.html

By the time tr18v5 rolled around just a year later in 1999, the overall
document has changed substantially, and you can clearly see its current
shape there.  Word characters are supposed to include all code points with
the Alphabetic property, for example.  

    http://www.unicode.org/reports/tr18/tr18-5.html

However, the word "alphabetic" has *never* been synonymous in 
Unicode with 

    \p{gc=Lu}
    \p{gc=Ll}
    \p{gc=Lt}
    \p{gc=Lm}
    \p{gc=Lo}

as many people incorrectly assume, nor certainly to 

    \p{gc=Lu}
    \p{gc=Ll}
    \p{gc=Lt}

let alone to 

    \p{gc=Lu}
    \p{gc=Ll}

Rather, it has since its creation included code points that are not
letters, such as all GC=Nl and also certain GC=So code points.  And,
notoriously, U+0345. Indeed it is here I first noticed that that Python had
already broken with the Standard, because U+0345 COMBINING GREEK
YPOGEGRAMMENI is GC=Mn, but Alphabetic=True, yet I have shown that 
Python's title method is messing up there.  

I wouldn't spend too much in archaeological digs, though, because lots of
stuff has changed since the less millennium.  It was in tr18v7 from 2003-05
that we hit paydirt, because this is when the famous Annex C of RL1.2a 
fame first appeared:

    http://www.unicode.org/reports/tr18/tr18-7.html#Compatibility_Properties

Notice how it defines \w to be nothing more than \p{alpha}, \p{digit}, and
\p{gc=Pc}.  It does not yet contain the requirement that all Marks be
counted as part of the word, just the few that are alphas -- which the
U+0345 counts for, since it has an uppercase map of a capital iota!

That particular change did not occur until tr18v8 in 2003-08, barely
a scant three months later.

    http://www.unicode.org/reports/tr18/tr18-8.html#Compatibility_Properties

Now at last we see word characters defined in the modern way that we 
have become used to.  They must match any of:

    \p{alpha}
    \p{gc=Mark}
    \p{digit}
    \p{gc=Connector_Punctuation}

BTW, Python is matching  all of 

    \p{GC=N}

meaning

    \p{GC=Nd}
    \p{GC=Nl}
    \p{GC=No}

instead of the required 

    \p{GC=Nd}

which is a synonym for \p{digit}.

I don't know had that happened, because \w has never included
all number code points in Unicode, only the decimal number ones.

That all goes to show why, when citing conformance to some aspect of 
The Unicode Standard, one must be exceedingly careful just how one 
does so!
The Unicode Consortium recognizes this is an issue, and I am pretty
sure I can hear it in your own subtext as well.  

Kindly bear with and forgive me for momentarily sounding like a standard
lawyer.  I do this because to show not just why it is important to get
references to the Unicode Standard correct, but indeed, how to do so.

After I have given the formal requirements, I will then produce
illustrations of various purported claims, some of which meet the
citation requirements, and others which do not.

=======================================================================

To begin with, there is an entire technical report on conformance.
It includes:

    http://unicode.org/reports/tr33/

    The Unicode Standard [Unicode] is a very large and complex standard.
    Because of this complexity, and because of the nature and role of the
    standard, it is often rather difficult to determine, in any particular
    case, just exactly what conformance to the Unicode Standard means.

...

    Conformance claims must be specific to versions of the Unicode
    Standard, but the level of specificity needed for a claim may vary
    according to the nature of the particular conformance claim. Some
    standards developed by the Unicode Consortium require separate
    conformance to a specific version (or later), of the Unicode Standard.
    This version is sometimes called the  base version. In such cases, the
    version of the standard and the version of the Unicode Standard to
    which the conformance claim refers must be compatible.

However, you don't need to read tr33, really, because *the* most important
thing bits about conformance are to be found on pp. 57-58 of Chapter 3 of
the published Unicode Standard:

    http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf

    References to the Unicode Standard

    The documents associated with the major, minor, and update versions are called the major
    reference, minor reference, and update reference, respectively. For example, consider Uni-
    code Version 3.1.1. The major reference for that version is The Unicode Standard, Version
    3.0 (ISBN 0-201-61633-5). The minor reference is Unicode Standard Annex #27, "The Uni-
    code Standard, Version 3.1." The update reference is Unicode Version 3.1.1. The exact list of
    contributory files, Unicode Standard Annexes, and Unicode Character Database files can
    be found at Enumerated Version 3.1.1.

    The reference for this version, Version 6.0.0, of the Unicode Standard, is

         The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined
         by: The Unicode Standard, Version 6.0 (Mountain View, CA: The Uni-
         code Consortium, 2011. ISBN 978-1-936213-01-6)

    References to an update (or minor version prior to Version 5.2.0) include a reference to
    both the major version and the documents modifying it. For the standard citation format
    for other versions of the Unicode Standard, see "Versions" in Section B.6, Other Unicode
    Online Resources.

    Precision in Version Citation

    Because Unicode has an open repertoire with relatively frequent updates, it is important
    not to over-specify the version number. Wherever the precise behavior of all Unicode char-
    acters needs to be cited, the full three-field version number should be used, as in the first
    example below. However, trailing zeros are often omitted, as in the second example. In such
    a case, writing 3.1 is in all respects equivalent to writing 3.1.0.

       1. The Unicode Standard, Version 3.1.1
       2. The Unicode Standard, Version 3.1
       3. The Unicode Standard, Version 3.0 or later
       4. The Unicode Standard

    Where some basic level of content is all that is important, phrasing such as in the third
    example can be used. Where the important information is simply the overall architecture
    and semantics of the Unicode Standard, the version can be omitted entirely, as in example 4.

    References to Unicode Character Properties

    Properties and property values have defined names and abbreviations, such as

	  Property:           General_Category (gc)
	  Property Value: Uppercase_Letter (Lu)

    To reference a given property and property value, these aliases are used, as in this example:

	  The property value Uppercase_Letter from the General_Category prop-
	  erty, as specified in Version 6.0.0 of the Unicode Standard.

    Then cite that version of the standard, using the standard citation format that is provided
    for each version of the Unicode Standard.

    When referencing multi-word properties or property values, it is permissible to omit the
    underscores in these aliases or to replace them by spaces.

    When referencing a Unicode character property, it is customary to prepend the word "Uni-
    code" to the name of the property, unless it is clear from context that the Unicode Standard
    is the source of the specification.

    References to Unicode Algorithms

    A reference to a Unicode algorithm must specify the name of the algorithm or its abbrevia-
    tion, followed by the version of the Unicode Standard, as in this example:

      The Unicode Bidirectional Algorithm, as specified in Version
      6.0.0 of the Unicode Standard.

      See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm,"
      (http://www.unicode.org/reports/tr9/tr9-23.html)

=======================================================================

Now for some concrete citation examples, both correct and dubious.

In the JDK7 documentation for on the Character class we find:

    Character information is based on the Unicode Standard, version 6.0.0.

That one is a perfectly good conformance citation, even if there seems 
a bit of wiggle in "is based on", but no matter.  It is short and does
everything it needs to.

However, in the JDK7 documentation for the Pattern class we
somewhat problematically find:

     Unicode support 

     This class is in conformance with Level 1 of Unicode Technical
     Standard #18: Unicode Regular Expression, plus RL2.1 Canonical
     Equivalents.

And similarly, in the JDK7 documentation for the Normalizer class we find:

    This class provides the method normalize which transforms Unicode
    text into an equivalent composed or decomposed form, allowing for
    easier sorting and searching of text. The normalize method supports
    the standard normalization forms described in  Unicode Standard
    Annex #15 ? Unicode Normalization Forms.

The problem with those second two Java refs is that they to my reading
appear to be in technical violation, for they give neither a full
version number nor a date of publication.  

You *have* to give one or the other, or both.  

Java got themselves into a heap of trouble (so to speak) over
this once before because it turned out that the version of the
document they were actually in conformance with was quite
literally from the previous millennium!!

That's why you need to give versions and publication dates.

Here are some other citations.

First, from the perldelta manpage that the Perl 5.14 release ships with:

       Perl comes with the Unicode 6.0 data base updated with Corrigendum
       #8 <http://www.unicode.org/versions/corrigendum8.html>, with one
       exception noted below.  See <http://unicode.org/versions/Unicode6.0.0/> 
       for details on the new release.  Perl does not support any Unicode 
       provisional properties, including the new ones for this release.

That is quite complete, as it even includes the specific which
corrigenda we follow and explains the matter of properties.

Or this from the perlunicode manpage of that same release:

   Unicode Regular Expression Support Level
       The following list of Unicode supported features for
       regular expressions describes all features currently
       directly supported by core Perl.  The references to "Level
       N" and the section numbers refer to the Unicode Technical
       Standard #18, "Unicode Regular Expressions", version 13,
       from August 2008.

See all that?  Notice how it gives the name of the document, its revision
number, and its publication date.  You don't have to do all that for the
main Unicode release, but you really ought to when referring to individual
technical reports BECAUSE THESE GET UPDATED ASYNCRONOUSLY.

I would suggest you pick a version of tr18 that you conform to,
and state which of its requirements you do and do not meet.

However, I cannot find any version of tr18 that has existed during the
present millennium that Python comes even close to meeting more than one
or two requirements for.  Given that, it may be better to no longer make
any claims regarding Unicode at all.  That seems like back-peddaling to
me, not future-thinking.

Matthew's regex module, however, does *almost* everything right that re
does wrong.  It may be that as with Java's io vs nio classes (and now
heaven forbid nio2!), you actually can't fix the only module and must
create a wholly new namespace.  I cannot answer that.

For RL1.2 proper, the first properties requirement, Java was only missing a
few, so they went and added the missing properties.  I strongly urge you to
do so because you cannot handle Unicode without properties.  Rl1.2 requires
only 11 of them, so it isn't too hard.  Matthew supports many many more.

However, because the \w&c issues are bigger, Java addressed the tr18 RL1.2a
issues differently, this time by creating a new compilation flag called
UNICODE_CHARACTER_CLASSES (with corresponding embedded "(?U)" regex flag.)

Truth be told, even Perl has secret pattern compilation flags to govern
this sort of thing (ascii, locale, unicode), but we (well, I) hope you
never have to use or even notice them.  

That too might be a route forward for Python, although I am not quite sure
how much flexibility and control of your lexical scope you have.  However,
the "from __future_" imports suggest you may have enough to do something
slick so that only people who ask for it get it, and also importantly that
they get it all over the place so don't have to add an extra flag or u'...'
or whatever every single time.  

This isn't something I've looked much into, however.

Hope this clarifies things.

--tom

----------

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

From senthil at uthcode.com  Sat Aug 13 02:36:46 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sat, 13 Aug 2011 08:36:46 +0800
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1313168123.69.0.38830809068.issue10087@psf.upfronthosting.co.za>
References: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
	<1313168123.69.0.38830809068.issue10087@psf.upfronthosting.co.za>
Message-ID: <20110813003645.GA2219@mathmagic>

Hello ?ric,

I might have ignored some minor stylistic comments. The '.' in the help text
and , after the last TestName, I am not sure if it is of concern.

I think, to update the stylistic comments, if the submitters (if they
care) could have updated the patch, or a separate commit on style
changes can be done (if they are worth it).

And yeah, it is bad to ignore substantiative comments. I hope, I did
not overlook any. Ezio's main point was he was worried about using
sys.stdout.buffer (as I was too) and we got that clarified. 

Thanks,
Senthil

From report at bugs.python.org  Sat Aug 13 02:36:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Aug 2011 00:36:55 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1313168123.69.0.38830809068.issue10087@psf.upfronthosting.co.za>
Message-ID: <20110813003645.GA2219@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hello ?ric,

I might have ignored some minor stylistic comments. The '.' in the help text
and , after the last TestName, I am not sure if it is of concern.

I think, to update the stylistic comments, if the submitters (if they
care) could have updated the patch, or a separate commit on style
changes can be done (if they are worth it).

And yeah, it is bad to ignore substantiative comments. I hope, I did
not overlook any. Ezio's main point was he was worried about using
sys.stdout.buffer (as I was too) and we got that clarified. 

Thanks,
Senthil

----------

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

From report at bugs.python.org  Sat Aug 13 02:56:17 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:56:17 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1313196977.6.0.913124738112.issue12728@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:56:39 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:56:39 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313196999.45.0.305956050326.issue12729@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:57:12 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:12 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313197032.32.0.644459918738.issue12730@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:57:20 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:20 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313197040.41.0.962224884449.issue12731@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:57:26 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:26 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <1313197046.77.0.820455304522.issue12732@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:57:51 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:51 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1313197071.97.0.727667161098.issue12733@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:57:58 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:58 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313197078.83.0.636277070338.issue12734@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:58:04 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:58:04 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1313197084.26.0.0460550114198.issue12735@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 02:58:12 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:58:12 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1313197092.34.0.987513458278.issue12736@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Sat Aug 13 03:13:25 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 13 Aug 2011 01:13:25 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313190327.69.0.0023174222472.issue12732@psf.upfronthosting.co.za>
Message-ID: <6716.1313197969@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

"Terry J. Reedy" <report at bugs.python.org> wrote
   on Fri, 12 Aug 2011 23:05:27 -0000: 

> Ouch!

> Do the rejected characters qualify as identifier characters as defined
> in Reference 2.3 Identifiers and keywords?

> http://docs.python.org/py3k/reference/lexical_analysis.html#identifiers

Yes, that's right, they do.  You're using the standard IDS and IDC, and
XIDS and XIDC, definitions.  Here were the three identifiers that were
a problem:

    ???????     = "super"
    ???????     = "Deseret"
    ??????????  = "Gothic our father"

If you cannot read those, then when piped through `uniquote -v` they are:

    \N{MATHEMATICAL FRAKTUR CAPITAL U}\N{MATHEMATICAL FRAKTUR SMALL N}\N{MATHEMATICAL FRAKTUR SMALL I}\N{MATHEMATICAL FRAKTUR SMALL C}\N{MATHEMATICAL FRAKTUR SMALL O}\N{MATHEMATICAL FRAKTUR SMALL D}\N{MATHEMATICAL FRAKTUR SMALL E}     = "super"
    \N{DESERET CAPITAL LETTER DEE}\N{DESERET SMALL LETTER SHORT E}\N{DESERET SMALL LETTER ES}\N{DESERET SMALL LETTER LONG I}\N{DESERET SMALL LETTER ER}\N{DESERET SMALL LETTER SHORT E}\N{DESERET SMALL LETTER TEE}     = "Deseret"
    \N{GOTHIC LETTER AHSA}\N{GOTHIC LETTER TEIWS}\N{GOTHIC LETTER TEIWS}\N{GOTHIC LETTER AHSA}\N{UNDERTIE}\N{GOTHIC LETTER URUS}\N{GOTHIC LETTER NAUTHS}\N{GOTHIC LETTER SAUIL}\N{GOTHIC LETTER AHSA}\N{GOTHIC LETTER RAIDA}  = "Gothic our father"

I'm not sure whether you recognize the scripts they belong to, but they're
all in the astral planes.  Using `uniquote -x` on them shows:

    \x{1D518}\x{1D52B}\x{1D526}\x{1D520}\x{1D52C}\x{1D521}\x{1D522}     = "super"
    \x{10414}\x{1042F}\x{10445}\x{10428}\x{10449}\x{1042F}\x{1043B}     = "Deseret"
    \x{10330}\x{10344}\x{10344}\x{10330}\x{203F}\x{1033F}\x{1033D}\x{10343}\x{10330}\x{10342}  = "Gothic our father"

As to whether they're proper identifiers per your reference above, I
will take the first letter from each of ???????, ???????, and ??????????, 
which are repsectively ?, ?, and ?, or

    MATHEMATICAL FRAKTUR CAPITAL U
    DESERET CAPITAL LETTER DEE
    GOTHIC LETTER AHSA

or 

    1D518
    10414
    10330

and show you their full Unicode properties of these reject code points.
This requires the uniprops command, given which, these three commands 
are then completely identical:

    % uniprops -ga "?" "?" "?"
    % uniprops -ga 1D518 10414 10330
    % uniprops -ga "MATHEMATICAL FRAKTUR CAPITAL U" "DESERET CAPITAL LETTER DEE" "GOTHIC LETTER AHSA"

and produce this output:

U+1D518 ??? \N{MATHEMATICAL FRAKTUR CAPITAL U}
    \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
    All Any Alnum Alpha Alphabetic Assigned InMathematicalAlphanumericSymbols Cased Cased_Letter LC Changes_When_NFKC_Casefolded
       CWKCF Common Zyyy Lu L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Uppercase_Letter Math
       Mathematical_Alphanumeric_Symbols Print Upper Uppercase Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha
       X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word
    Age=3.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Mathematical_Alphanumeric_Symbols Canonical_Combining_Class=0
       Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR General_Category=Cased_Letter Script=Common
       Decomposition_Type=Font DT=Font Decomposition_Type=Non_Canon Decomposition_Type=Non_Canonical DT=NonCanon
       East_Asian_Width=Neutral GC=LC General_Category=L General_Category=Letter General_Category=L_ General_Category=LC GC=L
       General_Category=Lu General_Category=Uppercase_Letter GC=Lu Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
       Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
       Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None
       Numeric_Value=NaN NV=NaN Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1
       Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 SC=Zyyy Script=Zyyy
       Sentence_Break=UP Sentence_Break=Upper SB=UP Word_Break=ALetter WB=LE Word_Break=LE _X_Begin
U+10414 ??? \N{DESERET CAPITAL LETTER DEE}
    \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
    All Any Alnum Alpha Alphabetic Assigned InDeseret Cased Cased_Letter LC Changes_When_Casefolded CWCF Changes_When_Casemapped
       CWCM Changes_When_Lowercased CWL Changes_When_NFKC_Casefolded CWKCF Deseret Dsrt Lu L Gr_Base Grapheme_Base Graph GrBase
       ID_Continue IDC ID_Start IDS Letter L_ Uppercase_Letter Print Upper Uppercase Word XID_Continue XIDC XID_Start XIDS
       X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word
    Age=3.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Deseret Canonical_Combining_Class=0
       Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR General_Category=Cased_Letter
       Decomposition_Type=None DT=None Script=Deseret East_Asian_Width=Neutral GC=LC General_Category=L General_Category=Letter
       General_Category=L_ General_Category=LC GC=L General_Category=Lu General_Category=Uppercase_Letter GC=Lu
       Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable
       HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL
       Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None Numeric_Value=NaN NV=NaN Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2
       Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1 Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2
       Present_In=6.0 IN=6.0 SC=Dsrt Script=Dsrt Sentence_Break=UP Sentence_Break=Upper SB=UP Word_Break=ALetter WB=LE
       Word_Break=LE _X_Begin
U+10330 ??? \N{GOTHIC LETTER AHSA}
    \w \pL \p{L_} \p{Lo}
    All Any Alnum Alpha Alphabetic Assigned InGothic Gothic Is_Gothic L Lo Goth Gr_Base Grapheme_Base Graph GrBase ID_Continue
       IDC ID_Start IDS Letter L_ Other_Letter Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha
       X_POSIX_Graph X_POSIX_Print X_POSIX_Word
    Age=3.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Gothic Canonical_Combining_Class=0
       Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Decomposition_Type=None DT=None
       East_Asian_Width=Neutral General_Category=L General_Category=Letter General_Category=L_ GC=L General_Category=Lo
       General_Category=Other_Letter GC=Lo Script=Gothic Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
       Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
       Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None
       Numeric_Value=NaN NV=NaN Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1
       Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 Script=Goth SC=Goth
       Sentence_Break=LE Sentence_Break=OLetter SB=LE Word_Break=ALetter WB=LE Word_Break=LE _X_Begin

As you see, all three are all of IDS, IDC, XIDS, and XIDC.

The reason they're failing in because on a narrow build, Python bizarrely 
splits the code points into two surrogates, and then rejects them because
surrogates aren't IDanything.

This strikes me as super crazy because you are reading from a UTF-8 source,
which therefore can handle all of Unicode.  And you actually split the things
into two UTF-16 code units, too; you don't blow up just because there is
something that UCS-2 can't cope with.  Indeed, I can switch things
around into literals and there is no choking:

    % cat astral-literals.python
    #!/usr/bin/env python3.2
    # -*- coding: UTF-8 -*-
    super = "???????" 
    Deseret = "???????"     
    Gothic_our_father = "??????????"
    print(super)
    print(Deseret)
    print(Gothic_our_father)

because watch what happens when I run that: mirabile visu, it behaves
completely correctly despite having code points in the narrow-build-
forbidden astral planes:

    % python3.2 astral-literals.python
    ???????
    ???????
    ??????????

Again, I uniquote those for you (in case you can't read them because you
haven't gotten George Douros's free Symbola font for Unicode 6.0.0 yet from
http://users.teilar.gr/~g1951d/ . BTW, I also recommend his Alfios font for
general text, and he has several others that may be of interest):

    % python3.2 astral-literals.python | uniquote -x
    \x{1D518}\x{1D52B}\x{1D526}\x{1D520}\x{1D52C}\x{1D521}\x{1D522}
    \x{10414}\x{1042F}\x{10445}\x{10428}\x{10449}\x{1042F}\x{1043B}
    \x{10330}\x{10344}\x{10344}\x{10330}\x{203F}\x{1033F}\x{1033D}\x{10343}\x{10330}\x{10342}

    % python3.2 astral-literals.python | uniquote -v
    \N{MATHEMATICAL FRAKTUR CAPITAL U}\N{MATHEMATICAL FRAKTUR SMALL N}\N{MATHEMATICAL FRAKTUR SMALL I}\N{MATHEMATICAL FRAKTUR SMALL C}\N{MATHEMATICAL FRAKTUR SMALL O}\N{MATHEMATICAL FRAKTUR SMALL D}\N{MATHEMATICAL FRAKTUR SMALL E}
    \N{DESERET CAPITAL LETTER DEE}\N{DESERET SMALL LETTER SHORT E}\N{DESERET SMALL LETTER ES}\N{DESERET SMALL LETTER LONG I}\N{DESERET SMALL LETTER ER}\N{DESERET SMALL LETTER SHORT E}\N{DESERET SMALL LETTER TEE}
    \N{GOTHIC LETTER AHSA}\N{GOTHIC LETTER TEIWS}\N{GOTHIC LETTER TEIWS}\N{GOTHIC LETTER AHSA}\N{UNDERTIE}\N{GOTHIC LETTER URUS}\N{GOTHIC LETTER NAUTHS}\N{GOTHIC LETTER SAUIL}\N{GOTHIC LETTER AHSA}\N{GOTHIC LETTER RAIDA}

Isn't that the weirest thing?  You're acting like a perfectly fine
full-unicode language even on a narrow build, and yet you reject
as identifiers those same strings that you have just faithfully
reproduced above.  

I really do not understand this.  It must be a bug.  Because they are
find on a wide build.  And because the literals are fine even on a
narrow one.

> If some interpreter version accepts extra characters, beyond the
> definition (as happened in 2.x), it is not a bug for for another version
> to only accept what is defined.

> Side question: That section has 

>	"A non-normative HTML file listing all valid identifier characters 
>        for Unicode 4.1 can be found 
>        at http://www.dcl.hpi.uni-potsdam.de/home/loewis/table-3131.html ." 

Gosh that's old.  Unicode *4.1*, really?  I sure hope you don't rely 
on something like that to know what's what!!

> Is the set of identifier characters now larger, and if so, has the table been enlarged?

Certainly!  I know this for certain science because I know that more
letters have been added.  But here is the proof:

    % unichars -ua '\p{ID_Start}' | wc -l
    100747

    % unichars -ua '\p{ID_Continue}' | wc -l
    102675

Notice how Unicode has been a bit oopsy with making sure that there 
all IDS/ISC code points also have the word property:

    % unichars -ua '\w' | wc -l
    102724

I'm pretty sure a few of those are slated for "fixing", because
I've seen proposals to that effect.  Here's one "letter" they 
even left out:

    % unichars -gs '\w' '\pL' '\P{IDC}'
    ?  U+02E2F GC=Lm SC=Common       VERTICAL TILDE

That says to show me the code points which are

    word chars
    letters
    *not* IDC

Before I started poking at them, nobody ran these sort of analyses
so things could slip through.  Even more annoyingly, here are non-word
characters that are indeed IDC characters:

    % unichars -gs '\W' '\p{IDC}'
    ?  U+000B7 GC=Po SC=Common       MIDDLE DOT
    ?  U+00387 GC=Po SC=Common       GREEK ANO TELEIA
    ?  U+01369 GC=No SC=Ethiopic     ETHIOPIC DIGIT ONE
    ?  U+0136A GC=No SC=Ethiopic     ETHIOPIC DIGIT TWO
    ?  U+0136B GC=No SC=Ethiopic     ETHIOPIC DIGIT THREE
    ?  U+0136C GC=No SC=Ethiopic     ETHIOPIC DIGIT FOUR
    ?  U+0136D GC=No SC=Ethiopic     ETHIOPIC DIGIT FIVE
    ?  U+0136E GC=No SC=Ethiopic     ETHIOPIC DIGIT SIX
    ?  U+0136F GC=No SC=Ethiopic     ETHIOPIC DIGIT SEVEN
    ?  U+01370 GC=No SC=Ethiopic     ETHIOPIC DIGIT EIGHT
    ?  U+01371 GC=No SC=Ethiopic     ETHIOPIC DIGIT NINE
    ?  U+019DA GC=No SC=New_Tai_Lue  NEW TAI LUE THAM DIGIT ONE
    ?  U+02118 GC=Sm SC=Common       SCRIPT CAPITAL P
    ?  U+0212E GC=So SC=Common       ESTIMATED SYMBOL
    ? U+0309B GC=Sk SC=Common       KATAKANA-HIRAGANA VOICED SOUND MARK
    ? U+0309C GC=Sk SC=Common       KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK

Digits are supposed to be GC=Nd not GC=No, so I don't know what the story 
is there. Maybe they don't have a zero?

    % uniprops 'ETHIOPIC DIGIT ZERO'
    uniprops: no character named ?ETHIOPIC DIGIT ZERO?

    % uniprops 'ETHIOPIC DIGIT ONE'
    U+1369 ??? \N{ETHIOPIC DIGIT ONE}
        \pN \p{No}
        All Any Assigned InEthiopic Ethiopic Is_Ethiopic Ethi N No Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC Number
           Other_Number Print XID_Continue XIDC X_POSIX_Graph X_POSIX_Print

I guess that's it then: you can't assemble bigendian base-10 integers 
out of digits whose set lacks a zero, which is the key criterion for GC=Nd
and for NT=De (Numeric_Type=Decimal), as in regular digits:

    % uniprops -ga 1
U+0031 ?1? \N{DIGIT ONE}
    \w \d \pN \p{Nd}
    AHex ASCII_Hex_Digit All Any Alnum ASCII Assigned Basic_Latin Common Zyyy Decimal_Number Digit Nd N Gr_Base Grapheme_Base
       Graph GrBase Hex XDigit Hex_Digit ID_Continue IDC Number PerlWord POSIX_Alnum POSIX_Digit POSIX_Graph POSIX_Print
       POSIX_Word POSIX_XDigit Print Word XID_Continue XIDC X_POSIX_Alnum X_POSIX_Digit X_POSIX_Graph X_POSIX_Print X_POSIX_Word
       X_POSIX_XDigit
    Age=1.1 Block=Basic_Latin Bidi_Class=EN Bidi_Class=European_Number BC=EN Block=ASCII BLK=ASCII Canonical_Combining_Class=0
       Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Script=Common General_Category=Decimal_Number
       Decomposition_Type=None DT=None East_Asian_Width=Na East_Asian_Width=Narrow EA=Na GC=Nd General_Category=Digit
       General_Category=Number General_Category=Nd Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
       Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
       Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=NU Line_Break=Numeric LB=NU Numeric_Type=De Numeric_Type=Decimal
       NT=De Numeric_Value=1 NV=1 Present_In=1.1 IN=1.1 Present_In=2.0 IN=2.0 Present_In=2.1 IN=2.1 Present_In=3.0 IN=3.0
       Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1 Present_In=5.0 IN=5.0
       Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 SC=Zyyy Script=Zyyy Sentence_Break=NU
       Sentence_Break=Numeric SB=NU Word_Break=NU Word_Break=Numeric WB=NU _X_Begin

But back to the mismatch between \w and IDC. Isn't that really annoying?

The first two occur in NFD, which is a pain.  So you start with
something that is all \w, then you decompose it, and whammo.

This brings up a whole nother issue.  Insofar as they may differ, should
one track \w or should one track IDS/IDC?  It is extremely vexing,
because whatever you do, you will change the lexical texture of your
language.  We recently swapped around from one to the other, and there
was one person whose module had to change.  He had no idea he was even
using one of these things in an ident, and was happy to change it.  But
we lucked out that time.  It is terribly bothersome situation, and I do
not know what the best strategy actually is, or the safest one, nor
whether those differ.  It troubles us, too, I do promise you.

One thing I might do to trouble you less...

If you don't have the uniquote, uniprops, or unichars commands yet,
and would like them, then well *those* I can tell you where to find. :)

--tom

----------

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

From report at bugs.python.org  Sat Aug 13 04:35:56 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 13 Aug 2011 02:35:56 +0000
Subject: [issue12745] Python2 or Python3 page
Message-ID: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

Since 2008 (as far as can remember) the Python Download page has a link to that web page:
http://wiki.python.org/moin/Python2orPython3

I know it's been updated but it keeps saying the same thing since Python 3.0 was launched.

Basically it says that Python 3 is awesome but please don't use it because not everything became compatible. (That's how a newcomer reads it).

I've been using Python 3 as replacement of Python 2 since the launch of 3.1... And now I can't even write a Python 2 code without feeling a little sick.

I pretty much think it's time to tell people to skip learning all that junk the dev team had to remove and start with something much nicer.

Think about it. You'll not have to worry if list comprehensions/generator expressions are available, the conditional operator, the boolean type (and True and False as keywords), decorators, the ability of having `non local` variables, extended tuple unpacking etc etc etc.

If nobody uses the next generation of the language, the developers won't port their code. If they don't port the code, no one can use it...


tl;dr

So I vote for a new page saying something like "Python 3 is the way you should go and, if you can't run something, try asking the developer to port it or choose another tool"

BTW, Those PyPI modules that haven't made any effort to port should be marked as `deprecated`, but that doesn't have anything to do with the change of the aforementioned web page.


-------
Sorry if that doesn't belong to a bug report and erase it if you want.

----------
assignee: docs at python
components: Documentation
messages: 142004
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: Python2 or Python3 page
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 13 04:59:33 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 02:59:33 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313204373.22.0.540910538039.issue12729@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

In a narrow build, a codepoint in the astral plane is encoded as surrogate pair.

I could implement a workaround for it in the regex module, but I think that the proper place to fix it is in the language as a whole, perhaps by implementing PEP 393 ("Flexible String Representation").

----------

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

From report at bugs.python.org  Sat Aug 13 05:00:37 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 13 Aug 2011 03:00:37 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1313204437.57.0.742628365408.issue9723@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Why can't pipes.quote can't be moved to shlex.quote verbatim as I originally proposed?

Is there justification to also change it as part of the relocation? I think any changes to its behaviour should be a separate issue.

----------

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

From report at bugs.python.org  Sat Aug 13 05:18:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 03:18:32 +0000
Subject: [issue12732] Can't portably use Unicode in Python identifiers
In-Reply-To: <1313092175.71.0.665967703883.issue12732@psf.upfronthosting.co.za>
Message-ID: <E1Qs4k2-0008P3-IG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 787ed1a7aba8 by Benjamin Peterson in branch '3.2':
in narrow builds, make sure to test codepoints as identifier characters (closes #12732)
http://hg.python.org/cpython/rev/787ed1a7aba8

New changeset 5af15f018e20 by Benjamin Peterson in branch 'default':
merge 3.2 (#12732)
http://hg.python.org/cpython/rev/5af15f018e20

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

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

From report at bugs.python.org  Sat Aug 13 06:12:01 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Aug 2011 04:12:01 +0000
Subject: [issue12746] normalization is affected by unicode width
Message-ID: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Narrow build:
unicodedata.normalize("NFKC", "???????")
'???????'

Wide build:
>>> unicodedata.normalize("NFKC", "???????")
'Unicode'

Normalization needs to properly decode characters in the supplementary plane.

----------
components: Extension Modules
messages: 142008
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: normalization is affected by unicode width
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 13 07:51:32 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 13 Aug 2011 05:51:32 +0000
Subject: [issue12747] Move devguide into /Docs of cpython repo
Message-ID: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The idea of moving the devguide into the cpython repo, presumably under Doc/, was mentioned in a thread on python-dev[1] (related to issue 12652).  Does anyone have any objections?

I'm guessing that Brett made a separate repo (A) for simplicity and (B) because the mercurial cutover hadn't happened yet.

As a bonus, if the devguide were in the cpython repo then most of the objections to moving the test.support docs under the devguide go away.

[1] http://mail.python.org/pipermail/python-dev/2011-July/112656.html

----------
messages: 142009
nosy: barry, brett.cannon, eli.bendersky, ericsnow, ncoghlan
priority: normal
severity: normal
status: open
title: Move devguide into /Docs of cpython repo

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

From report at bugs.python.org  Sat Aug 13 07:58:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Aug 2011 05:58:35 +0000
Subject: [issue12747] Move devguide into /Docs of cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313215115.47.0.647695466861.issue12747@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm +0 about it.

See also #12409.

----------
components: +Devguide
nosy: +ezio.melotti, sandro.tosi

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

From report at bugs.python.org  Sat Aug 13 08:18:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Aug 2011 06:18:49 +0000
Subject: [issue12747] Move devguide into /Docs of cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313216329.04.0.465762986992.issue12747@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Actually if we move the devguide to Doc/ we will have to maintain a copy for each branch -- that's the real reason why it's in a separate repo.

So I think it's better to leave the devguide in a separate repo, and keep using it to document things that are not strictly dependent on specific Python releases.

----------

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

From report at bugs.python.org  Sat Aug 13 08:23:06 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 13 Aug 2011 06:23:06 +0000
Subject: [issue12747] Move devguide into cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313216586.12.0.0756238154555.issue12747@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I suppose it doesn't have to be in Doc/.

----------
title: Move devguide into /Docs of cpython repo -> Move devguide into cpython repo

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

From report at bugs.python.org  Sat Aug 13 08:31:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Aug 2011 06:31:36 +0000
Subject: [issue12747] Move devguide into cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313217096.04.0.824158125628.issue12747@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The possible options I see are:
  1) move it in Doc/ or some other dir -- but we will have
     to maintain it in all the branches;
  2) keep it only in the default branch -- but we will have
     to remove it from the old branch when we cut a release;
  3) make a separate branch for the devguide -- I'm not sure
     this makes even sense and/or if it solves anything;

Also if it's not in Doc/, where would the test.support doc go?

----------

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

From report at bugs.python.org  Sat Aug 13 09:00:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 13 Aug 2011 07:00:39 +0000
Subject: [issue12747] Move devguide into cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313218839.8.0.829722943749.issue12747@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd say the main reason the dev guide is in a separate repo is the historical one (i.e. Brett was working on it as a separate repo prior to the hg migration and we never merged it).

However, the version independent nature of the material is the main argument against merging it into the Docs tree - it's a document about the development community around CPython, not a document about CPython itself.

Personally, I'm happy with the resolution in the python-dev thread - tagging the test.support docs to keep them out of indices and search results, while leaving the dev guide in a separate version independent repo.

----------

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

From report at bugs.python.org  Sat Aug 13 09:01:37 2011
From: report at bugs.python.org (Peter Saveliev)
Date: Sat, 13 Aug 2011 07:01:37 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1313218897.13.0.11139577833.issue11866@psf.upfronthosting.co.za>


Peter Saveliev <svinota.saveliev at gmail.com> added the comment:

counter.next() is a C routine and it is atomic from Python's point of view?? if I understand right.

The test shows that original threading.py leads to a (rare) race here, while with counter object there is no race condition.

----------

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

From report at bugs.python.org  Sat Aug 13 09:52:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Aug 2011 07:52:10 +0000
Subject: [issue11866] race condition in threading._newname()
In-Reply-To: <1303126142.97.0.491583907596.issue11866@psf.upfronthosting.co.za>
Message-ID: <1313221930.15.0.44981926948.issue11866@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think the patch is correct.

FWIW, my style is to prebind the next method, making the counter completely self-contained (like a closure):

+_counter = itertools.count().next
 def _newname(template="Thread-%d"):
     global _counter
-    _counter = _counter + 1
-    return template % _counter
+    return template % _counter()

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> accepted

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

From report at bugs.python.org  Sat Aug 13 10:02:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Aug 2011 08:02:13 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1313222533.9.0.448307400781.issue12746@psf.upfronthosting.co.za>


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


----------
components: +Unicode
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Aug 13 10:15:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 13 Aug 2011 08:15:10 +0000
Subject: [issue2857] Add "java modified utf-8" codec
In-Reply-To: <1313157478.61.0.748220418159.issue2857@psf.upfronthosting.co.za>
Message-ID: <4E463287.5080708@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Python does have other "weird" encodings like bz2 or rot13.

No, it has no more such weird encodings.

----------

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

From report at bugs.python.org  Sat Aug 13 11:40:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 09:40:58 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313228458.16.0.629066550578.issue12731@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/issue12731>
_______________________________________

From report at bugs.python.org  Sat Aug 13 11:48:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 09:48:46 +0000
Subject: [issue11513] chained exception/incorrect exception from tarfile.open
	on a non-existent file
In-Reply-To: <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
Message-ID: <E1QsApg-0005Vo-Dg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 843cd43206b4 by Georg Brandl in branch '3.2':
Fix #11513: wrong exception handling for the case that GzipFile itself raises an IOError.
http://hg.python.org/cpython/rev/843cd43206b4

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

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

From report at bugs.python.org  Sat Aug 13 11:51:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Aug 2011 09:51:22 +0000
Subject: [issue11513] chained exception/incorrect exception from tarfile.open
	on a non-existent file
In-Reply-To: <1300146032.78.0.080952835314.issue11513@psf.upfronthosting.co.za>
Message-ID: <1313229082.61.0.197032814972.issue11513@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in 3.2/default.

2.7 has even more primitive error handling; should the gzopen() be adapted to the 3.x case?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Aug 13 11:58:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Aug 2011 09:58:06 +0000
Subject: [issue10799] Improve webbrowser (.open) doc and behavior
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1313229486.23.0.168041543556.issue10799@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/issue10799>
_______________________________________

From report at bugs.python.org  Sat Aug 13 13:53:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 11:53:44 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313236424.53.0.5791582501.issue12737@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, loewis
stage:  -> needs patch
versions: +Python 3.3

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

From report at bugs.python.org  Sat Aug 13 13:55:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 11:55:39 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1313236539.18.0.516984670183.issue12746@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, lemburg

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

From report at bugs.python.org  Sat Aug 13 15:28:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 13:28:43 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <E1QsEGX-0001R0-JV@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bb6c2d5c811d by Nadeem Vawda in branch 'default':
Issue #12646: Add an 'eof' attribute to zlib.Decompress.
http://hg.python.org/cpython/rev/bb6c2d5c811d

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

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

From report at bugs.python.org  Sat Aug 13 15:45:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 13:45:46 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <E1QsEX3-0002SO-9I@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4358909ee221 by Nadeem Vawda in branch 'default':
Issue #12669: Fix test_curses so that it can run on the buildbots.
http://hg.python.org/cpython/rev/4358909ee221

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

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

From report at bugs.python.org  Sat Aug 13 15:45:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 13:45:46 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <E1QsEX3-0002SO-9A@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 65d61ed991d9 by Nadeem Vawda in branch 'default':
Fix incorrect comment in zlib.Decompress.flush().
http://hg.python.org/cpython/rev/65d61ed991d9

----------

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

From report at bugs.python.org  Sat Aug 13 17:44:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Aug 2011 15:44:03 +0000
Subject: [issue12723] Provide an API in tkSimpleDialog for defining custom
	validation functions
In-Reply-To: <1312989791.6.0.177522419712.issue12723@psf.upfronthosting.co.za>
Message-ID: <1313250243.7.0.532702360625.issue12723@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A bit of both, I think.  The current function is actually 'getvalue' and is responsible for retrieving the value, validating its type, and converting to that type (the current ones do both in the same operation).  It feels to me like a cleaner interface to decouple retrieval and validation/conversion, so that the validation function gets passed a string and returns the desired type.  But in that case, having the string dialog take the validation/coercion function makes the name of the askstring function just wrong.

So, I still think the cleaner API is to expose the class and let the application subclass to provide the validation function.

----------

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

From report at bugs.python.org  Sat Aug 13 17:47:38 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 13 Aug 2011 15:47:38 +0000
Subject: [issue12646] zlib.Decompress.decompress/flush do not raise any
	exceptions when given truncated input streams
In-Reply-To: <1311791362.59.0.0211250402323.issue12646@psf.upfronthosting.co.za>
Message-ID: <1313250458.69.0.727106732903.issue12646@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> feature request

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

From report at bugs.python.org  Sat Aug 13 17:57:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Aug 2011 15:57:59 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313251079.37.0.960221381055.issue12729@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Tom, note that nobody is arguing that what you are requesting is a bad thing :)

As far as I know, Matthew is the only one currently working on the regex support in Python.  (Other developers will commit small fixes if someone proposes a patch, but no one that I've seen other than Matthew is working on the deeper issues.)  If you want to help out that would be great.

And as far as this particular issue goes, yes the difference between the narrow and wide build has been a known issue for a long time, but has become less and less ignorable as unicode adoption has grown. Martin's PEP that Matthew references is the only proposed fix that I know of.  There is a GSoc project working on it, but I have no idea what the status is.

----------

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

From report at bugs.python.org  Sat Aug 13 18:12:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Aug 2011 16:12:09 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313251929.0.0.244348100036.issue12740@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As a new feature, this could only go into 3.3.

----------
nosy: +r.david.murray
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 18:31:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 16:31:31 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313253091.81.0.493694733985.issue12740@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I had never heard of "nmemb". "nmembers" would be less cryptic.
The patch needs a "versionadded" directive in the docs.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 18:40:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 16:40:51 +0000
Subject: [issue12745] Python2 or Python3 page
In-Reply-To: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>
Message-ID: <1313253651.11.0.447497522063.issue12745@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It is a wiki page, so you can edit it yourself (you probably need to register, though).
If you think your modifications would be too drastic, perhaps you want to launch a discussion on the python-dev mailing-list about that page and its current contents.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12745>
_______________________________________

From report at bugs.python.org  Sat Aug 13 18:41:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Aug 2011 16:41:00 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313253660.8.0.66197322886.issue12740@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

While we're at it, let's add str.pbrk() ;)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 18:41:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 16:41:58 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <1313253718.05.0.101986528764.issue12744@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12744>
_______________________________________

From report at bugs.python.org  Sat Aug 13 18:44:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 16:44:09 +0000
Subject: [issue9552] ssl build under Windows always rebuilds OpenSSL
In-Reply-To: <1281395092.02.0.0478122711499.issue9552@psf.upfronthosting.co.za>
Message-ID: <1313253849.85.0.631623564752.issue9552@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/issue9552>
_______________________________________

From report at bugs.python.org  Sat Aug 13 19:26:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Aug 2011 17:26:26 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313256386.75.0.653079646095.issue12740@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

How about __len__()?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 19:36:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 17:36:37 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <27372.1313194678@chthon>
Message-ID: <1313256874.3553.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, because the \w&c issues are bigger, Java addressed the tr18 RL1.2a
> issues differently, this time by creating a new compilation flag called
> UNICODE_CHARACTER_CLASSES (with corresponding embedded "(?U)" regex flag.)
> 
> Truth be told, even Perl has secret pattern compilation flags to govern
> this sort of thing (ascii, locale, unicode), but we (well, I) hope you
> never have to use or even notice them.  
> 
> That too might be a route forward for Python, although I am not quite sure
> how much flexibility and control of your lexical scope you have.  However,
> the "from __future_" imports suggest you may have enough to do something
> slick so that only people who ask for it get it, and also importantly that
> they get it all over the place so don't have to add an extra flag or u'...'
> or whatever every single time.  

If the current behaviour is buggy or sub-optimal, I think we should
simply fix it (which might be done by replacing "re" with "regex" if
someone wants to shepherd its inclusion in the stdlib).

By the way, thanks for the detailed explanations, Tom.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Sat Aug 13 19:52:01 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 13 Aug 2011 17:52:01 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313257921.44.0.817708336363.issue12740@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The functionality part of the patch looks reasonable.  However, the pseudo-randomization in the unit tests seems like a bad idea.  Say someone is adding a new feature X.  Runs the unit tests to find one of them failing.  Then runs them again to investigate and they are now passing.  Unit tests should be repeatable.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 20:19:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Aug 2011 18:19:41 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <E1QsIo8-0002uw-6e@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8e824e09924a by Antoine Pitrou in branch 'default':
Issue #12744: Fix inefficient representation of integers
http://hg.python.org/cpython/rev/8e824e09924a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12744>
_______________________________________

From report at bugs.python.org  Sat Aug 13 20:19:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 18:19:54 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <1313259594.37.0.200544900737.issue12744@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12744>
_______________________________________

From report at bugs.python.org  Sat Aug 13 20:53:47 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Aug 2011 18:53:47 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1313261627.88.0.423317928486.issue11241@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, the patch looks good!

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Sat Aug 13 21:38:12 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sat, 13 Aug 2011 19:38:12 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1313264292.47.0.256538421246.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? <francismb at email.de> added the comment:

I've started with test for ?fake_dec? and ?TempdirManager?. Please let me know if that in the line you want.

Thanks in advance

Francis

----------
keywords: +patch
nosy: +francismb
Added file: http://bugs.python.org/file22895/issue12659_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Sat Aug 13 21:48:50 2011
From: report at bugs.python.org (Eric Snow)
Date: Sat, 13 Aug 2011 19:48:50 +0000
Subject: [issue12747] Move devguide into cpython repo
In-Reply-To: <1313214692.21.0.724978511702.issue12747@psf.upfronthosting.co.za>
Message-ID: <1313264930.49.0.202434037975.issue12747@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

That's fine.  The discussion had moved away from the devguide, so I figured it would be worth following up.  You guys have made some good points.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12747>
_______________________________________

From report at bugs.python.org  Sat Aug 13 22:04:27 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 13 Aug 2011 20:04:27 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313251079.37.0.960221381055.issue12729@psf.upfronthosting.co.za>
Message-ID: <29759.1313265836@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

David Murray <report at bugs.python.org> wrote:

> Tom, note that nobody is arguing that what you are requesting is a bad
> thing :)

There looked to be minor some resistance, based on absolute backwards
compatibility even if wrong, regarding changing anything *at all* in re,
even things that to my jaded seem like actual bugs.

There are bugs, and then there are bugs.

In my survey of Unicode support across 7 programming languages for OSCON

    http://training.perl.com/OSCON/index.html

I came across a lot of weirdnesses, especially as first when the learning
curve was high.  Sure, I found it odd that unlike Java, Perl, and Ruby,
Python didn't offer regular casemapping on strings, only the simple
character-based mapping.  But that doesn't make it a bug, which is why
I filed it as an feature/enhancement request/wish, not as a bug.

I always count as bugs not handling Unicode text the way Unicode says
it must be handled.  Such things would be:

    Emitting CESU-8 when told to emit UTF-8.

    Violating the rule that UTF-8 must be in the shortest possible encoding.

    Not treating a code point as a letter when the supported version of the
    UCD says it is.  (This can happen if internal rules get out of sync
    with the current UCD.)

    Claiming one does "the expected thing on Unicode" for case-insensitive
    matches when not doing what Unicode says you must minimally do: use at
    least the simple casefolds, if not in fact the full ones.

    Saying \w matches Unicode word characters when one's definition of
    word characters differs from that of the supported version of the UCD.

Supporting Unicode vX.Y.Z is more than adding more characters.  All the
behaviors specified in the UCD have to be updated too, or else you are just
ISO 10646.  I believe some of Python's Unicode bugs happened because folks
weren't aware which things in Python were defined by the UCD or by various
UTS reports yet were not being directly tracked that way.  That's why its
important to always fully state which version of these things you follow.

Other bugs, many actually, are a result of the narrow/wide-build untransparency.

There is wiggle room in some of these.  For example, which is the one that
applies to re, in that you could -- in a sense -- remove the bug by no longer
claiming to do case-insensitive matches on Unicode.  I do not find that very
useful. Javascript works this way: it doesn't do Unicode casefolding.  Java you
have to ask nicely with the extra UNICODE_CASE flag, aka "(?u)", used with the
CASE_INSENSITIVE, aka "(?i)".

Sometimes languages provide different but equivalent interfaces to the same
functionality.  For example, you may not support the Unicode property
\p{NAME=foobar} in patterns but instead support \N{foobar} in patterns and
hopefully also in strings.  That's just fine.  On slightly shakier ground but
still I think defensible is how one approaches support for the standard UCD
properties:

          Case_Folding    Simple_Case_Folding
     Titlecase_Mapping    Simple_Titlecase_Mapping
     Uppercase_Mapping    Simple_Uppercase_Mapping
     Lowercase_Mapping    Simple_Lowercase_Mapping

One can support folding, for example, via (?i) and not have to
directly supporting a Case_Folding property like \p{Case_Folding=s},
since "(?i)s" should be the same thing as "\p{Case_Folding=s}".

> As far as I know, Matthew is the only one currently working on the
> regex support in Python.  (Other developers will commit small fixes if
> someone proposes a patch, but no one that I've seen other than Matthew
> is working on the deeper issues.)  If you want to help out that would
> be great.

Yes, I actually would.  At least as I find time for it.  I'm a competent C
programmer and Matthew's C code is very well documented, but that's very
time consuming.  For bang-for-buck, I do best on test and doc work, making
sure things are actually working the way they say do.

I was pretty surprised and disappointed by how much trouble I had with
Unicode work in Python.  A bit of that is learning curve, a bit of it is
suboptimal defaults, but quite a bit of it is that things either don't work
the way Unicode says, or because something is altogether missing.  I'd like
to help at least make the Python documentation clearer about what it is
or is not doing in this regard.

But be warned: one reason that Java 1.7 handles Unicode more according to
the published Unicode Standard in its Character, String, and Pattern
classes is because when they said they'd be supporting Unicode 6.0.0,
I went through those classes and every time I found something in violation
of that Standard, I filed a bug report that included a documentation patch
explaining what they weren't doing right.  Rather than apply my rather
embarrassing doc patches, they instead fixed the code. :)

> And as far as this particular issue goes, yes the difference between
> the narrow and wide build has been a known issue for a long time, but
> has become less and less ignorable as unicode adoption has grown.

Little would make me happier than for Python to move to a logical character
model the way Go and Perl treat them.  I find getting bogged down by code
units to be abhorrently low level, and it doesn't matter whether these are
8-bit code units like in PHP or 16-bit code units like in Java.  The Nth
character of a string should always be its Nth logical code point not
its Nth physical code units.

In regular expressions, this is a clearly stated requirement in the Unicode
Standard (see tr18 RL1.1 and RL1.7).  However, it is more than that.  The
entire character processing model really really should be logical not
physical. That's because you need to have whole code points not broken-up
code units before you can build on the still higher-level components needed
to meet user expectations. These include user-visible graphemes (like an E
with both a combining acute and a combining up tack below) and linguistic
collating elements (like the letter <ch> in Spanish, <dzs> in Hungarian, or
<dd> in Welsh).

> Martin's PEP that Matthew references is the only proposed fix that I
> know of.  There is a GSoc project working on it, but I have no idea
> what the status is.

Other possible fixes are using UTF-8 or UTF-32.

One reason I don't like that PEP is because if you are really that
concerned wiht storage space, it is too prone to spoilers.  Neither UTF-8
nor UTF-32 have any spoilers, but that PEP does.  What I mean is that just
one lone code point in a huge string is enough to change the representation
of everything in that string.  I think of these as spoilers; strings that
are mostly non-spoilers with just a bit of spoiler in them are super super
common.  Often it's all ASCII plus just a few ISO-8859-1 or other non-ASCII
Latin characters.  Or it's all Latin with a couple of non-BMP mathematical
alphanumerics thrown in.  That kind of thing.

Consider this mail message. It contains exactly six non-ASCII code points.

    % uniwc `mhpath cur +drafts`
    Paras    Lines    Words   Graphs    Chars    Bytes File
       79      345     2796    16899    16899    16920 /home/tchrist/Mail/drafts/1183

Because it is in UTF-8, its memory profile in bytes grows only very
slightly over its character count.  However, if you adopt the PEP, then you
pay and pay and pay, very nearly quadrupling the memory profile for six
particular characters.  Now it takes 67596 bytes intead of 16920, just for
the sake of six code points.  Ouch!!

Why would you want to do that?  You say you are worried about memory, but
then you would do this sort of thing.  I just don't understand.

I may be wrong here, not least because I can think of possible extenuating
circumstances, but it is my impression that there there is an underlying
assumption in the Python community and many others that being able to
access the Nth character in a string in constant time for arbitrary N is
the most important of all possible considerations.  I

I don't believe that makes as much sense as people think, because I don't
believe character strings really are accessed in that fashion very often
at all.  Sure, if you have a 2D matrix of strings where a given row-column
pair yields one character and you're taking the diagonal you might want
that, but how often does that actually happen?  Virtually never: these
are strings and not matrices we're running FFTs on after all.  We don't
need to be able to load them into vector registers or anything the way
the number-crunching people do.

That's because strings are a sequence of characters: they're text.  Whether
reading text left to right, right to left, or even boustrophedonically, you're
always going one past the character you're currently at.  You aren't going to
the Nth character forward or back for arbitrary N.  That isn't how people deal
with text.  Sometimes they do look at the end, or a few in from the far end,
but even that can be handled in other fashions.

I need to see firm use-case data justifying this overwhelming need for O(1)
access to the the Nth character before I will believe it.  I think it is
too rare to be as concerned with as so many people bizarrely appear to be.
This attachment has serious consequences.  It is because of this attachment
that the whole narrow/wide build thing occurs, where people are willing to
discard a clean, uniform processing model in search of what I do not
believe a reasonable or realistic goal.  Even if they *were* correct, *far*
more bugs are caused by unreliability than by performance.

 * If you were truly concerned with memory use, you would simply use UTF-8.
 * If you were truly concerned with O(1) access time, you would always use UTF-32.
 * Anything that isn't one of these two is some sort of messy compromise.

I promise that nobody ever had a BMP vs non-BMP bug who was working with
either UTF-8 or UTF-32.  This only happens with UTF-16 and UCS-2, which
have all the disadvantages of both UTF-8 and UTF-32 combined yet none of
the advantages of either.  It's the worst of both worlds.

Because you're using UTF-16, you're already paying quite a bit of memory for
text processing in Python compared to doing so in Go or in Perl, which are
both UTF-8 languages.  Since you're already used to paying extra, what's
so wrong with going to purely UTF-32?  That too would solve things.

UTF-8 is not the memory pig people allege it is on Asian text.  Consider:

I saved the Tokyo Wikipedia page for each of these languages as
NFC text and generated the following table comparing them. I've grouped
the languages into Western Latin, Western non-Latin, and Eastern.

   Paras Lines Words Graphs Chars  UTF16 UTF8   8:16 16:8  Language

     519  1525  6300  43120 43147  86296 44023   51% 196%  English
     343   728  1202   8623  8650  17302  9173   53% 189%  Welsh
     541  1722  9013  57377 57404 114810 59345   52% 193%  Spanish
     529  1712  9690  63871 63898 127798 67016   52% 191%  French
     321   837  2442  18999 19026  38054 21148   56% 180%  Hungarian

     202   464   976   7140  7167  14336 11848   83% 121%  Greek
     348   937  2938  21439 21467  42936 36585   85% 117%  Russian

     355   788   613   6439  6466  12934 13754  106%  94%  Chinese, simplified
     209   419   243   2163  2190   4382  3331   76% 132%  Chinese, traditional
     461  1127  1030  25341 25368  50738 65636  129%  77%  Japanese
     410   925  2955  13942 13969  27940 29561  106%  95%  Korean

Where:

  * Paras is the number of blankline-separated  text spans.
  * Lines is the number of linebreak-separated  text spans.
  * Words is the number of whitespace-separated text spans.

  * Graphs is the number of Unicode extended grapheme clusters.
  * Chars  is the number of Unicode code points.

  * UTF16 is how many bytes it takes up stored as UTF-16.
  * UTF8  is how many bytes it takes up stored as  UTF-8.

  * 8:16 is the ratio of  UTF-8 size to UTF-16 size as a percentage.
  * 16:8 is the ratio of UTF-16 size to UTF-8  size as a percentage.

  * Language is which version of the Tokyo page we're talking
    about here.

Here are my observations:

 * Western languages that use the Latin script suffer terribly upon
   conversion from UTF-8 to UTF-16, with English suffering the most
   by expanding by 96% and Hungarian the least by expanding by 80%.
   All are huge.

 * Western languages that do not use the Latin script still suffer, but
   only 15-20%.

 * Eastern languages DO NOT SUFFER in UTF-8 the way everyone claims
   that they do!

To expand on the last point:

 * In Korean and in (simplified) Chinese, you get only 6% bigger in
   UTF-8 than in UTF-16.

 * In Japanese, you get only 29% bigger in UTF-8 than in UTF-16.

 * The traditional Chinese actually got smaller in UTF-8 than in
   UTF-16! In fact, it costs 32% to use UTF-16 over UTF-8 for this
   sample. If you look at the Lines and Words columns, it looks
   that this might be due to white space usage.

So UTF-8 isn't even too bad on Asian languages.

But you howl that it's variable width.  So?  You're already using
a variable-width encoding in Python on narrow builds.  I know you think
otherwise, but I'll prove this below.

Variable width isn't as bad as people claim, partly because fixed width is
not as good as they claim.  Think of the kind of operations that you
normally do on strings.  You want to to go to the next user-visible
grapheme, or to the end of the current word, or go to the start of the next
line.  UTF-32 helps you with none of those, and UTF-8 does not hurt them.
You cannot instantly go to a particular address in memory for any of those
unless you build up a table of offsets as some text editors sometimes do,
especially for lines.  You simply have to parse it out as you go.

Here's why I say that Python uses UTF-16 not UCS-2 on its narrow builds.
Perhaps someone could tell me why the Python documentation says it uses
UCS-2 on a narrow build.  I believe this to be an error, because otherwise
I cannot explain how you can have non-BMP code points in your UTF-8
literals in your source code.  And you clearly can.

    #!/usr/bin/env python3.2
    # -*- coding: UTF-8 -*-
    super = "???????"
    print(super)

This is with a narrow build on Darwin:

    % python3.2 -c 'import sys; print(sys.maxunicode)'
    65535

    % export PYTHONIOENCODING=UTF-8 PERLUNICODE=S

    % python3.2 supertest | uniwc
       Paras    Lines    Words   Graphs    Chars    Bytes File
           0        1        1        8        8       29 standard input

    % python3.2 supertest | uniquote -x
    \x{1D518}\x{1D52B}\x{1D526}\x{1D520}\x{1D52C}\x{1D521}\x{1D522}

Observations and conclusion:

 *  You are emitting 8 code points,  7  in the SMP not in the BMP.

 *  You clearly understand code points above your alleged maxunicode value.

 *  If you were actually using UCS-2, those would not be possible.

 *  I submit that this proves you are actually using UTF-16.  Q.E.D.

Yet you are telling people you are using UCS-2.  Why is that?  Since you
are already using a variable-width encoding, why the supercilious attitude
toward UTF-8?  UTF-16 has the same properties but costs you a lot more.  As
I said before, UTF-16 puts you in the worst of all worlds.

 * If you were truly concerned with memory use, you would simply use UTF-8.
 * If you were truly concerned with O(1) access time, you would always use UTF-32.
 * Anything that isn't one of these two is some sort of messy compromise.

But even with UTF-16 you *can* present to the user a view of logical
characters that doesn't care about the underlying clunkish representation.
The Java regex engine proves that, since "." always matches a single code
point no matter whether it is in the BMP or not.  Similarly, ICU's classes
operate on logical characters -- code points not units -- even though they
use UTF-16 languages.  The Nth code point does not care and should not care
how many units it takes to get there.  It is fine to have both a byte
interface *and* a character interface, but I don't believe having something
that falls in between those two is of any use whatsoever.  And if you don't
have a code point interface, you don't have a character interface.

This is my biggest underlying complaint about Python's string model, but
I believe it fixable, even if doing so exceeds my own personal background.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 13 22:26:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 20:26:21 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313267181.77.0.526018613431.issue12729@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here's why I say that Python uses UTF-16 not UCS-2 on its narrow builds.
> Perhaps someone could tell me why the Python documentation says it uses
> UCS-2 on a narrow build.

There's a disagreement on that point between several developers. See an example sub-thread at:
http://mail.python.org/pipermail/python-dev/2010-November/105751.html

> Since you are already using a variable-width encoding, why the
> supercilious attitude toward UTF-8?

I think you are reading too much into these decisions. It's simply that no-one took the time to write an alternative implementation and demonstrate its superiority. I also believe the original implementation was UCS-2 and surrogate support was added progressively during the years. Hence the terminological mess and the ad-hoc semantics.

I agree that going with UTF-8 and a clever indexing scheme would be a better solution.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 13 22:57:40 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 20:57:40 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313269060.0.0.568845256971.issue12729@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

There are occasions when you want to do string slicing, often of the form:

pos = my_str.index(x)
endpos = my_str.index(y)
substring = my_str[pos : endpos]

To me that suggests that if UTF-8 is used then it may be worth profiling to see whether caching the last 2 positions would be beneficial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 13 23:09:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 21:09:52 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313269060.0.0.568845256971.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313269670.3553.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> There are occasions when you want to do string slicing, often of the form:
> 
> pos = my_str.index(x)
> endpos = my_str.index(y)
> substring = my_str[pos : endpos]
> 
> To me that suggests that if UTF-8 is used then it may be worth
> profiling to see whether caching the last 2 positions would be
> beneficial.

And/or a lookup table giving the byte offset of, say, every 16th
character. It gives you a O(1) lookup with a relatively reasonable
constant cost (you have to scan for less than 16 characters after the
lookup).

On small strings (< 256 UTF-8 bytes) the space overhead for the lookup
table would be 1/16. It could also be constructed lazily whenever more
than 2 positions are cached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 13 23:41:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Aug 2011 21:41:48 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313271708.09.0.138950146455.issue12740@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/issue12740>
_______________________________________

From report at bugs.python.org  Sat Aug 13 23:50:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Aug 2011 21:50:58 +0000
Subject: [issue12744] inefficient pickling of long integers on 64-bit builds
In-Reply-To: <1313166383.93.0.380939327922.issue12744@psf.upfronthosting.co.za>
Message-ID: <1313272258.24.0.560730793147.issue12744@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Nice.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12744>
_______________________________________

From report at bugs.python.org  Sun Aug 14 03:07:32 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 01:07:32 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313269060.0.0.568845256971.issue12729@psf.upfronthosting.co.za>
Message-ID: <15689.1313284036@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Matthew Barnett <report at bugs.python.org> wrote
   on Sat, 13 Aug 2011 20:57:40 -0000: 

> There are occasions when you want to do string slicing, often of the form:

>   pos = my_str.index(x)
>   endpos = my_str.index(y)
>   substring = my_str[pos : endpos]

Me, I would probably give the second call to index the first  
index position to guarantee the end comes after the start:

    str  = "for finding the biggest of all the strings"
    x_at = str.index("big")
    y_at = str.index("the", x_at)
    some = str[x_at:y_at]
    print("GOT", some)

But here's a serious question: is that *actually* a common usage pattern
for accessing strings in Python?  I ask because it wouldn't even *occur* to
me to go at such a problem in that way.  I would have always just written
it this way instead:

    import re
    str  = "for finding the biggest of all the strings"
    some = re.search("(big.*?)the", str).group(1)
    print("GOT", some)

I know I would use the pattern approach, just because that's 
how I always do such things in Perl:

    $str  = "for finding the biggest of all the strings";
    ($some) = $str =~ /(big.*?)the/;
    print "GOT $some\n";

Which is obviously a *whole* lot simpler than the index approach:

    $str  = "for finding the biggest of all the strings";
    $x_at = index($str, "big");
    $y_at = index($str, "the", $x_at);
    $len  = $y_at - $x_at;
    $some = substr($str, $x_at, $len);
    print "GOT $some\n";

With no arithmetic and no need for temporary variables (you can't really
escape needing x_at to pass to the second call to index), it's all a
lot more WYSIWIG.  See how much easier that is?  

Sure, it's a bit cleaner and less noisy in Perl than it is in Python by
virtue of Perl's integrated pattern matching, but I would still use
patterns in Python for this, not index.  

I honestly find the equivalent pattern operations a lot easier to read and write
and maintain than I find the index/substring version.  It's a visual thing.  
I find patterns a win in maintainability over all that busy index monkeywork.  
The index/rindex and substring approach is one I almost never ever turn to.
I bet I use pattern matching 100 or 500 times for each time I use index, and
maybe even more.

I happen to think in patterns.  I don't expect other people to do so.  But
because of this, I usually end up picking patterns even if they might be a
little bit slower, because I think the gain in flexibility and especially
maintability more than makes up for any minor performance concerns.

This might also show you why patterns are so important to me: they're one
of the most important tools we have for processing text.  Index isn't,
which is why I really don't care about whether it has O(1) access.  

> To me that suggests that if UTF-8 is used then it may be worth
> profiling to see whether caching the last 2 positions would be
> beneficial.

Notice how with the pattern approach, which is inherently sequential, you don't
have all that concern about running over the string more than once.  Once you
have the first piece (here, "big"), you proceed directly from there looking for
the second piece in a straightforward, WYSIWIG way.  There is no need to keep an
extra index or even two around on the string structure itself, going at it this way.

I would be pretty surprised if Perl could gain any speed by caching a pair of
MRU index values against its UTF-8 [but see footnote], because again, I think
the normal access pattern wouldn't make use of them.  Maybe Python programmers
don't think of strings the same way, though.  That, I really couldn't tell you.

But here's something to think about:

If it *is* true that you guys do all this index stuff that Perl programmers
just never see or do because of our differing comfort levels with regexes,
and so you think Python that might still benefit from that sort of caching 
because its culture has promoted a different access pattern, then that caching 
benefit would still apply even if you were retain the current UTF-16 representation
instead of going to UTF-8 (which might want it) or to UTF-32 (which wouldn't).

After all, you have the same variable-width caching issue with UTF-16 as with
UTF-8, so if it makes sense to have an MRU cache mapping character indices to
byte indices, then it doesn't matter whether you use UTF-8 or UTF-16!

However, I'd want some passive comparative benchmarks using real programs with
real data, because I would be suspicious of incurring the memory cost of two
more pointers in every string in the whole program.  That's serious.

--tom

FOOTNOTE: The Perl 6 people are thinking about clever ways to set up byte
          offset indices.  You have to do this if you want O(1) access to the
          Nth element for elements that are not simple code points even if you
          use UTF-32.  That's because they want the default string element to be
          a user visible grapheme, not a code point.  I know they have clever
          ideas, but I don't know how critical O(1) access truly is, nor whether 
	  it's worth the overhead this would require.  But perhaps it would be
	  extensible for other sorts of string elements, like locale-based
	  alphabetic units (like <ch>, <dz>, <ll>) or even words, and so would
	  prove interesting to try nonetheless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 03:11:52 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 01:11:52 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313269670.3553.18.camel@localhost.localdomain>
Message-ID: <10002.1313284306@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote
   on Sat, 13 Aug 2011 21:09:52 -0000: 

> And/or a lookup table giving the byte offset of, say, every 16th
> character. It gives you a O(1) lookup with a relatively reasonable
> constant cost (you have to scan for less than 16 characters after the
> lookup).

> On small strings (< 256 UTF-8 bytes) the space overhead for the lookup
> table would be 1/16. It could also be constructed lazily whenever more
> than 2 positions are cached.

You really should talk to the Perl 6 people to see whether their current
strategy for caching offset maps for grapheme positions might be of use to
you.  Larry explained it to me once but I no longer recall any details.

I notice though that they don't seem to think it worth doing for UTF-8 
or UTF-16, just for their synthetic "NFG" (Grapheme Normalization Form)
strings, where it would be needed even if they used UTF-32 underneath.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 04:06:32 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 14 Aug 2011 02:06:32 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313287592.56.0.187094078064.issue12729@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

You're right about starting the second search from where the first finished. Caching the position would be an advantage there.

The memory cost of extra pointers wouldn't be so bad if UTF-8 took less space than the current format.

Regex isn't used as much as in Perl. BTW, the current re module was introduced in Python 1.5, the previous regex and regsub modules being removed in Python 2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 04:35:26 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 02:35:26 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313267181.77.0.526018613431.issue12729@psf.upfronthosting.co.za>
Message-ID: <9771.1313289317@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>> Here's why I say that Python uses UTF-16 not UCS-2 on its narrow builds.
>> Perhaps someone could tell me why the Python documentation says it uses
>> UCS-2 on a narrow build.

> There's a disagreement on that point between several developers. 
> See an example sub-thread at:

> 	http://mail.python.org/pipermail/python-dev/2010-November/105751.html

Some of those folks know what they're talking about, and some do not.

Most of the postings miss the mark.

Python uses UTF-16 for its narrow builds.  It does not use UCS-2.

The argument that it must be UCS-2 because it can store lone surrogates
in memory is spurious.

You have to read The Unicode Standard very *very* closely, but it is not
necessary that all internal buffers always be in well-formed UTF-whatever.
Otherwise it would be impossible to append a code unit at a time to buffer.
I could pull out the reference if I worked at it, because I've had to find
it before.  It's in there.  Trust me.  I know.

It is also spurious to pretend that because you can produce illegal output
when telling it to generate something in UTF-16 that it is somehow not using
UTF-16.  You have simply made a mistake.  You have generated something  that
you have promised you would not generate.   I have more to say about this below.

Finally, it is spurious to argue against UTF-16 because of the code unit
interface.  Java does exactly  the same thing as Python does *in all regards*
here, and no one pretends that Java is UCS-2.  Both are UTF-16.

It is simply a design error to pretend that the number of characters
is the number of code units instead of code points.  A terrible and
ugly one, but it does not mean you are UCS-2.

You are not.  Python uses UTF-16 on narrow builds.  

The ugly terrible design error is digusting and wrong, just as much in 
Python as in Java, and perhaps moreso because of the idiocy of narrow
builds even existing.  But that doesn't make them UCS-2.

If I could wave a magic wand, I would have Python undo its code unit
blunder and go back to code points, no matter what.  That means to stop
talking about serialization schemes and start talking about logical code
points.  It means that slicing and index and length and everything only
report true code points.  This horrible code unit botch from narrow builds
is most easily cured by moving to wide builds only.

However, there is more.

I haven't checked its UTF-16 codecs, but Python's UTF-8 codec is broken
in a bunch of ways.  You should be raising as exception in all kinds of
places and you aren't.  I can see I need to bug report this stuff to.  
I don't to be mean about this.  HONEST!  It's just the way it is.

Unicode currently reserves 66 code points as noncharacters, which it 
guarantees will never be in a legal UTF-anything stream.  I am not talking 
about surrogates, either.

To start with, no code point which when bitwise added with 0xFFFE returns
0xFFFE can never appear in a valid UTF-* stream, but Python allow this
without any error.

That means that both 0xNN_FFFE and 0xNN_FFFF are illegal in all planes,
where NN is 00 through 10 in hex.  So that's 2 noncharacters times 17 
planes = 34 code points illegal for interchange that Python is passing 
through illegally.  

The remaining 32 nonsurrogate code points illegal for open interchange
are 0xFDD0 through 0xFDEF.  Those are not allowed either, but Python
doesn't seem to care.

You simply cannot say you are generating UTF-8 and then generate a byte
sequence that UTF-8 guarantees can never occur.  This is a violation.

***SIGH***

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 05:52:51 2011
From: report at bugs.python.org (Ben Hayden)
Date: Sun, 14 Aug 2011 03:52:51 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313293971.63.0.900914633457.issue12725@psf.upfronthosting.co.za>


Ben Hayden <hayden767 at gmail.com> added the comment:

I made the suggested second change - both in the docs & the socketmodule.c file. If there's a different way to patch documentation, someone let me know. :D

----------
keywords: +patch
nosy: +beardedp
Added file: http://bugs.python.org/file22896/issue12725.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12725>
_______________________________________

From report at bugs.python.org  Sun Aug 14 06:40:41 2011
From: report at bugs.python.org (hy)
Date: Sun, 14 Aug 2011 04:40:41 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
Message-ID: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>


New submission from hy <hoyeung411 at gmail.com>:

The IDLE halts on os x when copy and paste
I tried in 10.6.8 and 10.7
Now I could only use IDLE in Windows in VMware

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 142046
nosy: hoyeung, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE halts on osx when copy and paste
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 06:54:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 04:54:40 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313297680.15.0.194063822462.issue12729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> It is simply a design error to pretend that the number of characters
> is the number of code units instead of code points.  A terrible and
> ugly one, but it does not mean you are UCS-2.

If you are referring to the value returned by len(unicode_string), it is the number of code units.  This is a matter of "practicality beats purity".  Returning the number of code units is O(1) (num_of_bytes/2).  To calculate the number of characters it's instead necessary to scan all the string looking for surrogates and then count any surrogate pair as 1 character.  It was therefore decided that it was not worth to slow down the common case just to be 100% accurate in the "uncommon" case.

That said it would be nice to have an API (maybe in unicodedata or as new str methods?) able to return the number of code units, code points, graphemes, etc, but I'm not sure that it should be the default behavior of len().

> The ugly terrible design error is digusting and wrong, just as much
> in Python as in Java, and perhaps moreso because of the idiocy of
> narrow builds even existing.

Again, wide builds use twice as much the space than narrow ones, but one the other hand you can have fast and correct behavior with e.g. len().  If people don't care about/don't need to use non-BMP chars and would rather use less space, they can do so.  Until we agree that the difference in space used/speed is no longer relevant and/or that non-BMP characters become common enough to prefer the "correct behavior" over the "fast-but-inaccurate" one, we will probably keep both.

> I haven't checked its UTF-16 codecs, but Python's UTF-8 codec is
> broken in a bunch of ways.  You should be raising as exception in
> all kinds of places and you aren't.

I am aware of some problems of the UTF-8 codec on Python 2.  It used to follow RFC 2279 until last year and now it's been updated to follow RFC 3629.
However, for backward compatibility, it still encodes/decodes surrogate pairs.  This broken behavior has been kept because on Python 2, you can encode every code point with UTF-8, and decode it back without errors:
>>> x = [unichr(c).encode('utf-8') for c in range(0x110000)]
>>>
and breaking this invariant would probably make more harm than good.  I proposed to add a "real" utf-8 codec on Python 2, but no one seems to care enough about it.

Also note that this is fixed in Python3:
>>> x = [chr(c).encode('utf-8') for c in range(0x110000)]
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed

>  I can see I need to bug report this stuff to.  

If you find other places where it's broken (both on Python 2 and/or Python 3), please do and feel free to add me to the nosy.  If you can also provide a failing test case and/or point to the relevant parts of the Unicode standard, it would be great.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 06:58:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 04:58:26 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313297906.83.0.663347931785.issue12748@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you specify what version of Python are you using, how do you copy/paste (e.g. ctrl+c/v, from the menu), and if it halts regardless of what you copy/paste?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 07:30:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Aug 2011 05:30:06 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <E1QsTGu-0005FZ-LZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset dfe6f0a603d2 by Ezio Melotti in branch '2.7':
#12725: fix working. Patch by Ben Hayden.
http://hg.python.org/cpython/rev/dfe6f0a603d2

New changeset ab3432a81c26 by Ezio Melotti in branch '3.2':
#12725: fix working. Patch by Ben Hayden.
http://hg.python.org/cpython/rev/ab3432a81c26

New changeset 49e9e34da512 by Ezio Melotti in branch 'default':
#12725: merge with 3.2.
http://hg.python.org/cpython/rev/49e9e34da512

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12725>
_______________________________________

From report at bugs.python.org  Sun Aug 14 07:31:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 05:31:52 +0000
Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313299912.29.0.574037863861.issue12725@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the patch!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12725>
_______________________________________

From report at bugs.python.org  Sun Aug 14 07:50:56 2011
From: report at bugs.python.org (hy)
Date: Sun, 14 Aug 2011 05:50:56 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313301056.89.0.125843775145.issue12748@psf.upfronthosting.co.za>


hy <hoyeung411 at gmail.com> added the comment:

I use the latest python 2.7.2 binary in a freshly installed os x
I use command c and command v, and also use the menu.
Also, it halts when I cut.
No matter what I cut, copy and paste, it halts.
It happens both in the shell and editor.

I have to remind myself not to use copy and paste now. Once I forget, IDLE halts and I have to force quit it and I lost everything unsaved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 07:53:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 05:53:13 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313301193.42.0.60161475847.issue12748@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +kbk, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 08:01:03 2011
From: report at bugs.python.org (David Townshend)
Date: Sun, 14 Aug 2011 06:01:03 +0000
Subject: [issue12741] Add function similar to shutil.move that does not
	overwrite
In-Reply-To: <1313152865.62.0.69696851164.issue12741@psf.upfronthosting.co.za>
Message-ID: <1313301663.13.0.701275677576.issue12741@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

A bit of research has shown that the proposed implementation will not work either, so my next suggestion is something along the lines of

def move2(src, dst):
    try:
        os.link(src, dst)
    except OSError as err:
        # handle error appropriately, raise shutil.Error if dst exists,
        # or use shutil.copy2 if dst is on a different filesystem.
        pass
    else:
        os.unlink(src)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12741>
_______________________________________

From report at bugs.python.org  Sun Aug 14 08:09:45 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 06:09:45 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313297680.15.0.194063822462.issue12729@psf.upfronthosting.co.za>
Message-ID: <5187.1313302168@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>> It is simply a design error to pretend that the number of characters
>> is the number of code units instead of code points.  A terrible and
>> ugly one, but it does not mean you are UCS-2.

> If you are referring to the value returned by len(unicode_string), it
> is the number of code units.  This is a matter of "practicality beats
> purity".  Returning the number of code units is O(1) (num_of_bytes/2).
> To calculate the number of characters it's instead necessary to scan
> all the string looking for surrogates and then count any surrogate
> pair as 1 character.  It was therefore decided that it was not worth
> to slow down the common case just to be 100% accurate in the
> "uncommon" case.

If speed is more important than correctness, I can make any algorithm
infinitely fast.  Given the choice between correct and quick, I will 
take correct every single time.

Plus your strings our immutable! You know how long they are and they 
never change.  Correctness comes at a negligible cost.  

It was a bad choice to return the wrong answer.

> That said it would be nice to have an API (maybe in unicodedata or as
> new str methods?) able to return the number of code units, code
> points, graphemes, etc, but I'm not sure that it should be the default
> behavior of len().

Always code points, never code units.  I even use a class whose length
method returns the grapheme count, because even code points aren't good
enough.  Yes of course graphemes have to be counted.  Big deal.   How 
would you like it if you said to move three to the left in vim and 
it *didn't* count each graphemes as one position?  Madness.

>> The ugly terrible design error is digusting and wrong, just as much
>> in Python as in Java, and perhaps moreso because of the idiocy of
>> narrow builds even existing.

> Again, wide builds use twice as much the space than narrow ones, but
> one the other hand you can have fast and correct behavior with e.g.
> len().  If people don't care about/don't need to use non-BMP chars and
> would rather use less space, they can do so.  Until we agree that the
> difference in space used/speed is no longer relevant and/or that non-
> BMP characters become common enough to prefer the "correct behavior"
> over the "fast-but-inaccurate" one, we will probably keep both.

Which is why I always put loud warnings in my Unicode-related Python
programs that they do not work right on Unicode if running under
a narrow build.  I almost feel I should just exit.

>> I haven't checked its UTF-16 codecs, but Python's UTF-8 codec is
>> broken in a bunch of ways.  You should be raising as exception in
>> all kinds of places and you aren't.

> I am aware of some problems of the UTF-8 codec on Python 2.  It used
> to follow RFC 2279 until last year and now it's been updated to follow
> RFC 3629.

Unicode says you can't put surrogates or noncharacters in a UTF-anything 
stream.  It's a bug to do so and pretend it's a UTF-whatever.

Perl has an encoding form, which it does not call "UTF-8", that you 
can use the UTF-8 algorithm on for any code point, include non-characters
and surrogates and even non-Unicode code points far above 0x10_FFFF, up
to in fact 0xFFFF_FFFF_FFFF_FFFF on 64-bit machines.  It's the internal
format we use in memory.  But we don't call it real UTF-8, either.

It sounds like this is the kind of thing that would be useful to you.

> However, for backward compatibility, it still encodes/decodes
> surrogate pairs.  This broken behavior has been kept because on Python
> 2, you can encode every code point with UTF-8, and decode it back
> without errors:

No, that's not UTF-8 then.  By definition.  See the Unicode Standard.

>>>> x = [unichr(c).encode('utf-8') for c in range(0x110000)]
>>>>

> and breaking this invariant would probably make more harm than good.

Why?  Create something called utf8-extended or utf8-lax or utf8-nonstrict
or something.  But you really can't call it UTF-8 and do that.  

We actually equate "UTF-8" and "utf8-strict".  Our internal extended
UTF-8 is something else.  It seems like you're still doing the old
relaxed version we used to have until 2003 or so.  It seems useful
to be able to have both flavors, the strict and the relaxed one,
and to call them different things.  

Perl defaults to the relaxed one, which gives warnings not exceptions,
if you do things like setting PERLUNICODE to S or SD and such for the
default I/I encoding.  If you actually use "UTF-8" as the encoding on the stream, though, you
get the version that gives exceptions instead.  

    "UTF-8" = "utf8-strict" 	strictly by the standard, raises exceptions otherwise
    "utf8"			loosely only, emits warnings on encoding illegal things

We currently only emit warnings or raise exceptions on I/O, not on chr
operations and such.  We used to raise exceptions on things like
chr(0xD800), but that was a mistake caused by misunderstanding the in-
memory requirements being different from stream requirements.  It's
really really subtle and you have to read the standard very closely to
realize this.

So you are perfectly free to use chr(0x20FFFF) in your own code.  This is
really useful for out-of-band sentinels and such.  However, if you try to
send it out a loose utf8 stream, you get a mandatory warning, and if you
try to send it out a strict UTF-8 stream, you get an exception.

In fact, if you remember the old "migrate ASCII trick" from the tr program,
doing something like this to turn on the high bit to mark characters in some way:

    tr[\0-\x7F][\x80-\xFF]

        (that's what killed WordStar BTW, as they used that trick
         on their ASCII internally so couldn't port to 8-bit
         encodings.  Ooops.)

Given the full 32- or 64-bit (or higher) character range for internal use, 
you can actually do this as a sort of corresponding transform:

    tr[\0-\x{10_FFFF}][\x{20_0000}-\x{3F_FFFF}]

Just don't try to output it. :)  For internal use only.  Blah blah.

(Hm, I just realized you couldn't ever do that sort of thing at all on a
narrow build because you're stuck with UTF-16.  On a wide build, though,
you could, because you'd have UTF-32.  Not that I'm suggesting it!!!)

Yes, that's not necessarily the best way to do most of what one might
naively try using it for, but there are all kinds of intersting things you
can do when your characters' internal code points don't have the same upper
bound as Unicode.

It's taken us years to unravel all this Unicode stuff so it's usable.  We used
to a lot of really um unfortunate things, whether too many errors or too few.
I'm certainly not suggesting you go down those roads.  In some ways, Python's
Unicode support reminds me of ours from rather a long time ago.

We've worked pretty hard at Unicode in Perl for the last few years, although
even ten years ago we already supported \X, all regex properties, and full
casemapping and full casefolding.  So there's always been a strong Unicode
sensitivity in Perl.  It's just taken us a long long long long time to 
get all the kinks out.

I don't imagine most of the Python devel team knows Perl very well, and maybe
not even Java or ICU.  So I get the idea that there isn't as much awareness of
Unicode in your team as there tends to be in those others. From my point of
view, learning from other people's mistakes is a way to get ahead without
incurring all the learning-bumps oneself, so if there's a way to do that for
you, that could be to your benefit, and I'm very happy to share some of our
blunders so you can avoid them yourselves.

> I proposed to add a "real" utf-8 codec on Python 2, but no one seems
> to care enough about it.

Hm.  See previous paragraph. :)

> Also note that this is fixed in Python3:
>>>> x = [chr(c).encode('utf-8') for c in range(0x110000)]
> UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed

Yes, I've noticed that Python3 is better about some of this,
but it doesn't detect the 66 noncharacter code points.  

I haven't checked on decoding yet, but I bet it's the same.

I think having something that does the lax Python2 way and something
else that does the stricter Standard way makes the most sense.  

>>  I can see I need to bug report this stuff to.  

> If you find other places where it's broken (both on Python 2 and/or
> Python 3), please do and feel free to add me to the nosy.  If you can
> also provide a failing test case and/or point to the relevant parts of
> the Unicode standard, it would be great.

I'll wait to report it till I have all my references at ready.

I can probably pretty easily find the part of the Unicode Standard where it
says no UTF can contain code points that are illegal for interchange.
Finding the part that explains that/why you can and indeed must be able to 
have them internally is going to be harder, but I know it's there.

Also, there is a tr18 update that adds a bit of clarification about how it
is sometimes ok to allow a regex engine in a UTF-16 language to find
unpaired surrogates, like checking whether "foo\x{D800}bar" matches
the pattern /\p{Cs}/.  You could never have that string read in from a valid
UTF-{8,16,32} stream, but because it can happen in your program, you have
to be able to match it.  So they finally admit this in the next tr18 update.
But it's still a bit odd, eh?  (And no, that doesn't make it UCS-2! :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 09:15:08 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 07:15:08 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313306108.95.0.490686038302.issue12729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> If speed is more important than correctness, I can make any algorithm
> infinitely fast.  Given the choice between correct and quick, I will 
> take correct every single time.

It's a trade-off.  Using non-BMP chars is fairly unusual (many real-world applications hardly use non-ASCII chars).  Slowing everything down just to allow non-BMP chars on narrow builds is not a good idea IMHO.  Wide builds can be used if one really wants len() and other methods to work properly with non-BMP chars.

> Plus your strings our immutable! You know how long they are and they 
> never change.  Correctness comes at a negligible cost. 

Sure, we can cache the len, but we still have to compute it at least once.  Also it's not just len(), but many other operations like slicing that are affected.

> Unicode says you can't put surrogates or noncharacters in a 
> UTF-anything stream.  It's a bug to do so and pretend it's a 
> UTF-whatever.

The UTF-8 codec described by RFC 2279 didn't say so, so, since our codec was following RFC 2279, it was producing valid UTF-8.  With RFC 3629 a number of things changed in a non-backward compatible way.  Therefore we couldn't just change the behavior of the UTF-8 codec nor rename it to something else in Python 2.  We had to wait till Python 3 in order to fix it.

> Perl has an encoding form, which it does not call "UTF-8", that you
> can use the UTF-8 algorithm on for any code point, include 
> non-characters and surrogates and even non-Unicode code points far
> above 0x10_FFFF, up to in fact 0xFFFF_FFFF_FFFF_FFFF on 64-bit 
> machines.  It's the internal format we use in memory.  But we don't
> call it real UTF-8, either.

This sounds like RFC 2279 UTF-8.  It allowed up to 6 bytes (following the same encoding scheme) and had no restrictions about surrogates (at the time I think only BMP chars existed, so there were no surrogates and the Unicode consortium didn't decide that the limit was 0x10FFFF).

> It sounds like this is the kind of thing that would be useful to you.

I believe this is what the surrogateescape error handler does (up to 0x10FFFF).

> Why?  Create something called utf8-extended or utf8-lax or 
> utf8-nonstrict or something.  But you really can't call it UTF-8 and 
> do that. 

That's what we did in Python 3, but on Python 2 is too late to fix it, especially in a point release.  (Just to clarify, I don't think any of these things will be fixed in 2.7.  There won't be any 2.8, and major changes (especially backwards-incompatible ones) are unlikely to happen in a point release (e.g. 2.7.3), so it's better to focus on Python 3.  Minor bug fixes can still be done even in 2.7 though.)

> Perl defaults to the relaxed one, which gives warnings not exceptions,
> if you do things like setting PERLUNICODE to S or SD and such for the
> default I/I encoding.  If you actually use "UTF-8" as the encoding on 
> the stream, though, you get the version that gives exceptions 
> instead.

In Python we don't usually use warnings for this kind of things (also we don't have things like "use strict").

> I don't imagine most of the Python devel team knows Perl very well,
> and maybe not even Java or ICU.  So I get the idea that there isn't 
> as much awareness of Unicode in your team as there tends to be in
> those others.

I would say there are at least 5-10 Unicode "experts" in our team.  It might be true though that we don't always follow closely what other languages and the Unicode consortium do, but if people reports problem we are willing to fix them (so thanks for reporting them!).

> From my point of view, learning from other people's mistakes is a way
> to get ahead without incurring all the learning-bumps oneself, so if
> there's a way to do that for you, that could be to your benefit, and 
> I'm very happy to share some of our blunders so you can avoid them
> yourselves.

While I really appreciate the fact that you are sharing with us your experience, the solution found and applied in Perl might not always be the best one for Python (but it's still good to learn from others' mistakes).
For example I don't think removing the 0x10FFFF upper limit is going to happen -- even if it might be useful for other things.
Also regular expressions are not part of the core and are not used that often, so I consider problems with narrow/wide builds, codecs and the unicode type much more important than problems with the re/regex module (they should be fixed too, but have lower priority IMHO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 09:20:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 14 Aug 2011 07:20:37 +0000
Subject: [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1313306437.27.0.134410199975.issue12743@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you just remove the "XXX" string, or the entire comment? "XXX" is typically used to indicate that something needs to be done, and the comment makes a clear statement as to what it is that needs to be done.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12743>
_______________________________________

From report at bugs.python.org  Sun Aug 14 09:24:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Aug 2011 07:24:02 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313306642.51.0.242503050995.issue12748@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Chances are that you used the python.org 2.7.2 64-bit/32-bit installer but you did not install the latest ActiveState Tcl, currently 8.5.10, as documented here:

    http://www.python.org/download/mac/tcltk/

On OS X 10.6, there should have been a warning message about this in the IDLE shell window. The Apple-supplied Tcl/Tk 8.5 in both Mac OS X 10.6 and 10.7 have known problems as described in the web page above.  Please try with the latest ActiveState Tcl installed and reopen this issue if that does not resolve the problems you see.

----------
assignee: ronaldoussoren -> ned.deily
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 11:13:05 2011
From: report at bugs.python.org (hy)
Date: Sun, 14 Aug 2011 09:13:05 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313313185.35.0.728511779694.issue12748@psf.upfronthosting.co.za>


hy <hoyeung411 at gmail.com> added the comment:

Thanks but the problem is not completely solved
I followed your instruction and I can now use mouse to click the menu to copy and paste without problems.
But it still halts when using keyboard to do so.
Is there a complete solution?

----------
resolution: works for me -> wont fix
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 16:25:14 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 14 Aug 2011 14:25:14 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313331914.47.0.275105422429.issue12729@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 17:47:39 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 15:47:39 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
Message-ID: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

On neither narrow nor wide builds does this UTF8-encoded bit run without raising an exception: 

   if re.search("[?-?]", "?", re.UNICODE): 
       print("match 1 passed")
   else:
       print("match 2 failed")

The best you can possibly do is to use both a wide build *and* symbolic literals, in which case it will pass. But remove either of both of those conditions and you fail.  This is too restrictive for full Unicode use. 

There should never be any sitation where [a-z] fails to match c when a < c < z, and neither a nor z is something special in a character class.  There is, or perhaps should be, no difference at all between "[a-z]" and "[?-?]", just as there is, or at least should b, no difference between "c" and "?". You can?t have second-class citizens like this that can't be used.

And no, this one is *not* fixed by Matthew Barnett's regex library. There is some dumb UCS-2 assumption lurking deep in Python somewhere that makes this break, even on wide builds, which is incomprehensible to me.

----------
components: Regular Expressions
files: bigrange.py
messages: 142058
nosy: Arfrever, ezio.melotti, jkloth, mrabarnett, pitrou, r.david.murray, tchrist, terry.reedy
priority: normal
severity: normal
status: open
title: lib re cannot match non-BMP ranges (all versions, all builds)
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22897/bigrange.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:00:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 16:00:36 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313337636.05.0.20997349067.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On a wide 2.7 and 3.3 all the 3 tests pass.

On a narrow 3.2 I get 
match 1 passed
Traceback (most recent call last):
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (<class 'str'>, '[?-?]', 32)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "bigrange.py", line 16, in <module>
    if re.search("[?-?]", "?", flags): 
  File "/home/wolf/dev/py/3.2/Lib/re.py", line 158, in search
    return _compile(pattern, flags).search(string)
  File "/home/wolf/dev/py/3.2/Lib/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "/home/wolf/dev/py/3.2/Lib/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/home/wolf/dev/py/3.2/Lib/sre_compile.py", line 491, in compile
    p = sre_parse.parse(p, flags)
  File "/home/wolf/dev/py/3.2/Lib/sre_parse.py", line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File "/home/wolf/dev/py/3.2/Lib/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/wolf/dev/py/3.2/Lib/sre_parse.py", line 461, in _parse
    raise error("bad character range")
sre_constants.error: bad character range

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:06:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 16:06:48 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313338008.86.0.287608821741.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

On wide 3.2 it passes too, so the failure is limited to narrow builds (are you sure that it fails on wide builds for you?).

On a narrow 2.7 I get a slightly different error though:

match 1 passed
Traceback (most recent call last):
  File "bigrange.py", line 16, in <module>
    if re.search("[?-?]", "?", flags): 
  File "/home/wolf/dev/py/2.7/Lib/re.py", line 142, in search
    return _compile(pattern, flags).search(string)
  File "/home/wolf/dev/py/2.7/Lib/re.py", line 244, in _compile
    raise error, v # invalid expression
sre_constants.error: bad character range

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:16:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 16:16:28 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313338588.27.0.523850328384.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I haven't looked at the code, but I think that the re module is just trying to calculate the range between the low surrogate of ? and the high surrogate of ?.
If this is the case, this is the "usual bug" that narrow builds have.

Also note that re.search(u"[\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]".encode('utf-8'), u"\N{MATHEMATICAL SCRIPT CAPITAL C}".encode('utf-8'), re.UNICODE)
"works", but it returns a wrong result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:24:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Aug 2011 16:24:37 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313339077.63.0.221493714058.issue12748@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

That is encouraging.  This is almost certainly a problem with Tk.  The Cocoa Tcl/Tk 8.5 used by Apple and ActiveState has been known to have issues with composite characters.  There are a couple of IDLE things to ask about first.  Have you made any Custom Key Bindings for IDLE?  Or added any IDLE extensions?  Both of these would show up in your ~/.idlerc directory.

On to Tk-related questions:  Which OS X keyboard layout are you using?  Are you using any Input Methods?  (Both of these options are shown in System Preferences.)  What keystrokes are used for the menu shortcuts that cause the hang?  And, by hang, you mean that menu item changes color indicating that it is selected but IDLE freezes at that point?

If you have the time and feel comfortable doing so, it would be helpful to know if the same problems are displayed using the older Carbon Tcl/Tk 8.4.  You could temporarily move your current 2.7 installation out of the way by doing this in a Terminal shell:

    cd /Library/Frameworks/Python.framework/Versions
    sudo mv 2.7 2.7-SAVED
    cd /Applications
    sudo mv Python\ 2.7 Python\ 2.7-SAVED

and then downloading and installing the 32-bit-only (10.3+) 2.7.2 installer from python.org.  It is not necessary to install an ActiveState Tcl/Tk 8.4 for this.  Note that if you have migrated to OS X 10.7 already, you probably will not want to stay with this version because it is not easy with Xcode 4 to install third-party Python packages that require building C extension modules.  You can restore your previous Python by:

    cd /Library/Frameworks/Python.framework/Versions
    sudo mv 2.7-SAVED 2.7
    cd /Applications
    sudo mv Python\ 2.7-SAVED Python\ 2.7

----------
resolution: wont fix -> 
stage: committed/rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:29:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 16:29:38 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313339378.21.0.258945487984.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The error on 3.2 comes from the lru_cache, here's a minimal testcase to reproduce it:
>>> from functools import lru_cache
>>> @lru_cache()
... def func(arg): raise ValueError()
... 
>>> func(3)
Traceback (most recent call last):
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 176, in wrapper
    result = cache[key]
KeyError: (3,)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/3.2/Lib/functools.py", line 180, in wrapper
    result = user_function(*args, **kwds)
  File "<stdin>", line 2, in func
ValueError


Raymond, is this expected or should I open another issue?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:54:49 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 16:54:49 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313306108.95.0.490686038302.issue12729@psf.upfronthosting.co.za>
Message-ID: <25916.1313340867@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Sun, 14 Aug 2011 07:15:09 -0000:

>> Unicode says you can't put surrogates or noncharacters in a
>> UTF-anything stream.  It's a bug to do so and pretend it's a
>> UTF-whatever.

> The UTF-8 codec described by RFC 2279 didn't say so, so, since our
> codec was following RFC 2279, it was producing valid UTF-8.  With RFC
> 3629 a number of things changed in a non-backward compatible way.
> Therefore we couldn't just change the behavior of the UTF-8 codec nor
> rename it to something else in Python 2.  We had to wait till Python 3
> in order to fix it.

I'm a bit confused on this.  You no longer fix bugs in Python 2?

I've dug out the references that state that you are not allowed to do things the
way you are doing them.  This is from the published Unicode Standard version 6.0.0,
chapter 3, Conformance.  It is a very important chapter.

    http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf

Python is in violation of that published Standard by interpreting noncharacter code
points as abstract characters and tolerating them in character encoding forms like
UTF-8 or UTF-16.  This explains that conformant processes are forbidden from doing this.

    Code Points Unassigned to Abstract Characters

     C1 A process shall not interpret a high-surrogate code point or a low-surrogate code point
         as an abstract character.
       ? The high-surrogate and low-surrogate code points are designated for surrogate
         code units in the UTF-16 character encoding form. They are unassigned to any
         abstract character.

==>  C2 A process shall not interpret a noncharacter code point as an abstract character.
       ? The noncharacter code points may be used internally, such as for sentinel val-
         ues or delimiters, but should not be exchanged publicly.

     C3 A process shall not interpret an unassigned code point as an abstract character.
       ? This clause does not preclude the assignment of certain generic semantics to
         unassigned code points (for example, rendering with a glyph to indicate the
         position within a character block) that allow for graceful behavior in the pres-
         ence of code points that are outside a supported subset.
       ? Unassigned code points may have default property values. (See D26.)
       ? Code points whose use has not yet been designated may be assigned to abstract
         characters in future versions of the standard. Because of this fact, due care in
         the handling of generic semantics for such code points is likely to provide better
         robustness for implementations that may encounter data based on future ver-
         sions of the standard.

Next we have exactly how something you call UTF-{8,16-32} must be formed.
*This* is the Standard against which these things are measured; it is not the RFC.

You are of course perfectly free to say you conform to this and that RFC, but you
must not say you conform to the Unicode Standard when you don't.  These are different
things.  I feel it does users a grave disservice to ignore the Unicode Standard in
this, and sheer casuistry to rely on an RFC definition while ignoring the Unicode
Standard whence it originated, because this borders on being intentionally misleading.

    Character Encoding Forms

     C8 When a process interprets a code unit sequence which purports to be in a Unicode char-
         acter encoding form, it shall interpret that code unit sequence according to the corre-
         sponding code point sequence.
==>    ? The specification of the code unit sequences for UTF-8 is given in D92.
       ? The specification of the code unit sequences for UTF-16 is given in D91.
       ? The specification of the code unit sequences for UTF-32 is given in D90.

     C9 When a process generates a code unit sequence which purports to be in a Unicode char-
         acter encoding form, it shall not emit ill-formed code unit sequences.
       ? The definition of each Unicode character encoding form specifies the ill-
         formed code unit sequences in the character encoding form. For example, the
         definition of UTF-8 (D92) specifies that code unit sequences such as <C0 AF>
         are ill-formed.

==> C10 When a process interprets a code unit sequence which purports to be in a Unicode char-
         acter encoding form, it shall treat ill-formed code unit sequences as an error condition
         and shall not interpret such sequences as characters.
       ? For example, in UTF-8 every code unit of the form 110xxxx2 must be followed
         by a code unit of the form 10xxxxxx2. A sequence such as 110xxxxx2 0xxxxxxx2
         is ill-formed and must never be generated. When faced with this ill-formed
         code unit sequence while transforming or interpreting text, a conformant pro-
         cess must treat the first code unit 110xxxxx2 as an illegally terminated code unit
         sequence--for example, by signaling an error, filtering the code unit out, or
         representing the code unit with a marker such as U+FFFD replacement
         character.
       ? Conformant processes cannot interpret ill-formed code unit sequences. How-
         ever, the conformance clauses do not prevent processes from operating on code
         unit sequences that do not purport to be in a Unicode character encoding form.
         For example, for performance reasons a low-level string operation may simply
         operate directly on code units, without interpreting them as characters. See,
         especially, the discussion under D89.
       ? Utility programs are not prevented from operating on "mangled" text. For
         example, a UTF-8 file could have had CRLF sequences introduced at every 80
         bytes by a bad mailer program. This could result in some UTF-8 byte sequences
         being interrupted by CRLFs, producing illegal byte sequences. This mangled
         text is no longer UTF-8. It is permissible for a conformant program to repair
         such text, recognizing that the mangled text was originally well-formed UTF-8
         byte sequences. However, such repair of mangled data is a special case, and it
         must not be used in circumstances where it would cause security problems.
         There are important security issues associated with encoding conversion, espe-
         cially with the conversion of malformed text. For more information, see Uni-
         code Technical Report #36, "Unicode Security Considerations."

Here is the part that explains why Python narrow builds are actually UTF-16 not UCS-2,
and why its documentation needs to be updated:

    D89 In a Unicode encoding form: A Unicode string is said to be in a particular Unicode
           encoding form if and only if it consists of a well-formed Unicode code unit sequence
           of that Unicode encoding form.
        ? A Unicode string consisting of a well-formed UTF-8 code unit sequence is said
           to be in UTF-8. Such a Unicode string is referred to as a valid UTF-8 string, or a
           UTF-8 string for short.
        ? A Unicode string consisting of a well-formed UTF-16 code unit sequence is said
           to be in UTF-16. Such a Unicode string is referred to as a valid UTF-16 string,
           or a UTF-16 string for short.
        ? A Unicode string consisting of a well-formed UTF-32 code unit sequence is said
           to be in UTF-32. Such a Unicode string is referred to as a valid UTF-32 string,
           or a UTF-32 string for short.

==> Unicode strings need not contain well-formed code unit sequences under all conditions.
    This is equivalent to saying that a particular Unicode string need not be in a Unicode
    encoding form.

        ? For example, it is perfectly reasonable to talk about an operation that takes the
           two Unicode 16-bit strings, <004D D800> and <DF02 004D>, each of which
           contains an ill-formed UTF-16 code unit sequence, and concatenates them to
           form another Unicode string <004D D800 DF02 004D>, which contains a well-
           formed UTF-16 code unit sequence. The first two Unicode strings are not in
           UTF-16, but the resultant Unicode string is.

    [...]

     D14 Noncharacter: A code point that is permanently reserved for internal use and that
           should never be interchanged. Noncharacters consist of the values U+nFFFE and
           U+nFFFF (where n is from 0 to 1016) and the values U+FDD0..U+FDEF.
         ? For more information, see Section 16.7, Noncharacters.
         ? These code points are permanently reserved as noncharacters.

     D15 Reserved code point: Any code point of the Unicode Standard that is reserved for
           future assignment. Also known as an unassigned code point.
         ? Surrogate code points and noncharacters are considered assigned code points,
           but not assigned characters.
         ? For a summary classification of reserved and other types of code points, see
           Table 2-3.

    In general, a conforming process may indicate the presence of a code point whose use has
    not been designated (for example, by showing a missing glyph in rendering or by signaling
    an appropriate error in a streaming protocol), even though it is forbidden by the standard
    from interpreting that code point as an abstract character.

Here's how I read all that.

The noncharacters and the unpaired surrogates are illegal for interchange, and their
presence in a UTF means that that UTF is not conformant to the requirements for what
a UTF shall contain.  Nonetheless, internally it is necessary that all code points,
even noncharacter code points and surrogates, be representable, and doing so does not
mean that you are no longer are in that encoding form.  However, you must not allow
such things into a UTF stream, because doing so means that that stream is no longer
a UTF stream.

That's why I say that you are of conformance by having encoders and decoders of UTF
streams tolerate noncharacters.  You are not allowed to call something a UTF and do
non-UTF things with it, because this in violation of conformance requirement C2.
Therefore you must either (1) change what you are calling the thing you doing the
nonconforming thing to, or you must (2) change it to no longer do the nonconforming
thing.  If you do neither, then Python no longer conforms to the formal requirements
for handling such things as these are defined by the Unicode Standard, and therefore
that version of Python is no longer conformant to the version of the Unicode Standard
that it purports conformance to.  And yes, that's a long way of saying it's lying.

It's also why having noncharacters including surrogates in memory does *not* suddenly
mean that there are not stored in a UTF, because you have to be able to do that to
build up buffers per the concatenation example in conformance requirement D89.
Therefore, Python uses UTF-16 internally and should not say it uses UCS-2, because
that is inaccurate and incorrect; in short, it's wrong.  That doesn't help anybody.

At least, that's how I read the Unicode Standard.  Perhaps a more careful reading
than mine would admit alternate interpretations.  If you have not reread its Chapter
3 of late in its entirety, you probably want to do so.  There is quite a bit of
material there that is fundamental to any process that claims to be conformant with
the Unicode Standard.

I hope that makes sense.  These things can be extremely difficult to read, for they
are subtle and quick to anger. :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 18:57:17 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 16:57:17 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313338008.86.0.287608821741.issue12749@psf.upfronthosting.co.za>
Message-ID: <25204.1313341025@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>On wide 3.2 it passes too, so the failure is limited to narrow builds (are =
>you sure that it fails on wide builds for you?).

You're right: my wide build is not Python3, just Python2.  In fact,
it's even worse, because it's the stock build on Linux, which seems
on this machine to be 2.6 not 2.7.

I have private builds that are 2.7 and 3.2, but those are both narrow.
I do not have a 3.3 build.  Should I?

I'm remembering why I removed Python2 from my Unicode talk, because
of how it made me pull my hair out.  People at the talk wanted to know
what I meant, but I didn't have time to go into it.  I think this
gets added to the hairpulling list.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:09:28 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 17:09:28 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313306108.95.0.490686038302.issue12729@psf.upfronthosting.co.za>
Message-ID: <26111.1313341755@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Sun, 14 Aug 2011 07:15:09 -0000: 

> For example I don't think removing the 0x10FFFF upper limit is going to
> happen -- even if it might be useful for other things. 

I agree entirely.  That's why I appended a triple exclamation point to where I
said I certainly do not expect this.  It can only work fully on UTF-8ish systems
and up to 32 bits on UTF-32, and it is most emphatically *not* Unicode.  Yes,
there are things you can do with it, but it risks serious misunderstanding and
even noncomformance if not done very carefully.  The Standard does not forbid
such things internally, but you are not allowed to pass them around in
noninternal streams claiming they are real UTF streams.

> Also regular expressions are not part of the core and are not used
> that often, so I consider problems with narrow/wide builds, codecs and
> the unicode type much more important than problems with the re/regex
> module (they should be fixed too, but have lower priority IMHO).

One advantage of having an external library is the ability to update
it asynchronously.  Another is the possibility to swap in out altogether.
Perl only gained that ability, which Python has always had, some four
years ago with its 5.10 release.  To my knowledge, the only thing people
tend to use this for is to get Russ Cox's re2 library, which has very
different performance characteristics and guarantees that allow it to 
be used in potential starvation denial-of-service situations that the
normal Perl, Python, Java, etc regex engine cannot be safely used for.

-tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:15:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 17:15:52 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313342152.26.0.740730067024.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> You're right: my wide build is not Python3, just Python2.

And is it failing?  Here the tests pass on the wide builds, on both Python 2 and 3.

> In fact, it's even worse, because it's the stock build on Linux, 
> which seems on this machine to be 2.6 not 2.7.

What is worse?  FWIW on my system the default `python` is a 2.7 wide. `python3` is a 3.2 wide.

> I have private builds that are 2.7 and 3.2, but those are both narrow.
> I do not have a 3.3 build.  Should I?

3.3 is the version in development, not released yet.  If you have an HG clone of Python you can make a wide build of 3.x with ./configure --with-wide-unicode andof 2.7 using ./configure --enable-unicode=ucs4.

> I'm remembering why I removed Python2 from my Unicode talk, because
> of how it made me pull my hair out.  People at the talk wanted to know
> what I meant, but I didn't have time to go into it.  I think this
> gets added to the hairpulling list.

I'm not sure what you are referring to here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:19:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Aug 2011 17:19:09 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <25204.1313341025@chthon>
Message-ID: <1313342225.3574.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have private builds that are 2.7 and 3.2, but those are both narrow.
> I do not have a 3.3 build.  Should I?

I don't know if you *should*. But you can make one easily by passing
"--with-wide-unicode" to ./configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:36:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Aug 2011 17:36:42 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <25916.1313340867@chthon>
Message-ID: <1313343278.3574.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > The UTF-8 codec described by RFC 2279 didn't say so, so, since our
> > codec was following RFC 2279, it was producing valid UTF-8.  With RFC
> > 3629 a number of things changed in a non-backward compatible way.
> > Therefore we couldn't just change the behavior of the UTF-8 codec nor
> > rename it to something else in Python 2.  We had to wait till Python 3
> > in order to fix it.
> 
> I'm a bit confused on this.  You no longer fix bugs in Python 2?

In general, we try not to introduce changes that have a high probability
of breaking existing code, especially when what is being "fixed" is a
minor issue which almost nobody complains about.

This is even truer for stable branches, and Python 2 is very much a
stable branch now (no more feature releases after 2.7).

> That's why I say that you are of conformance by having encoders and decoders of UTF
> streams tolerate noncharacters.  You are not allowed to call something a UTF and do
> non-UTF things with it, because this in violation of conformance requirement C2.

Perhaps, but it is not Python's fault if the IETF and the Unicode
consortium have disagreed on what UTF-8 should be. I'm not sure what
people called "UTF-8" when support for it was first introduced in
Python, but you can't blame us for maintaining a consistent behaviour
across releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:46:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 17:46:55 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313344015.71.0.218551063153.issue12729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I'm a bit confused on this.  You no longer fix bugs in Python 2?

We do, but it's unlikely that we will introduce major changes in behavior.
Even if we had to get rid of narrow builds and/or fix len(), we would probably only do it in the next 3.x version (i.e. 3.3), and not in the next bug fix release of 3.2 (i.e. 3.2.2).

> That's why I say that you are of conformance by having encoders and
> decoders of UTF streams tolerate noncharacters.  You are not allowed
> to call something a UTF and do non-UTF things with it, because this
> in violation of conformance requirement C2.

This IMHO should be fixed, but it's another issue.

> If you have not reread its Chapter 3 of late in its entirety, you
> probably want to do so.  There is quite a bit of material there that
> is fundamental to any process that claims to be conformant with
> the Unicode Standard.

I am familiar with the Chapter 3, but admittedly I only read the parts that were relevant to the bugs I was fixing.  I never went through it checking that everything in Python matches the described behavior.
Thanks for pointing out the parts were Python doesn't follow the specs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 19:58:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 17:58:38 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1313344718.01.0.419863795722.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached patch + tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file22898/issue12266.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Sun Aug 14 20:01:28 2011
From: report at bugs.python.org (Catalin Iacob)
Date: Sun, 14 Aug 2011 18:01:28 +0000
Subject: [issue12611] 2to3 crashes when converting doctest using reduce()
In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za>
Message-ID: <1313344888.08.0.890537142507.issue12611@psf.upfronthosting.co.za>


Catalin Iacob <iacobcatalin at gmail.com> added the comment:

I looked at this and understood why it's happening. I don't know exactly how to fix it though, so here's what I found out.

When a doctest appears in a docstring at line n in a file, RefactorTool.parse_block will return a tree corresponding to n - 1 newline characters followed by the code in the doctest. That tree is refactored by RefactoringTool.refactor_tree which usually returns n - 1 newline characters followed by the refactored doctest. However, for the reduce fixer, the tree returned by refactor_tree starts with from functools import reduce followed by n - 1 newline characters and then the doctest reduce line. The failing assert happens when stripping those newlines because they are expected to be at the beginning of the output while in reality they're after the import line.

So the problem is a mismatch between the expectations of the doctest machinery (refactoring code that starts with some newlines results in code that starts with the same number of newlines) and the reduce fixer which adds an import, imports are added at the beginning of the file, therefore something appears before the newlines. Other fixers could exhibit the same problem.

----------
nosy: +catalin.iacob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12611>
_______________________________________

From report at bugs.python.org  Sun Aug 14 20:03:56 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Aug 2011 18:03:56 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313345036.11.0.789905045333.issue12740@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I like random tests in the stdlib, otherwise the same thing gets tested
over and over again. `make buildbottest` prints the seed, and you can do
it for a single test as well:

 $ ./python -m test -r test_heapq
Using random seed 5857004
[1/1] test_heapq
1 test OK.


It looks like the choice is between s.nmembers and len(s). I thought
about len(s), but since Struct.pack() returns a bytes object, this
might be confusing.

Struct.arity may be another option. This also reflects that pack()
will be an n-ary function for the given format string (and that
Struct is a packing object, not really a struct itself).


Still, probably I'm +0.5 on 'nmembers' compared to the other options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sun Aug 14 20:17:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Aug 2011 18:17:33 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313345036.11.0.789905045333.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313345728.3574.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It looks like the choice is between s.nmembers and len(s). I thought
> about len(s), but since Struct.pack() returns a bytes object, this
> might be confusing.

I agree there's a risk of confusion between len()-number-of-elements and
size()-number-of-bytes.
We have a similar confusion with the memoryview object and in retrospect
it's often quite misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sun Aug 14 21:00:22 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 19:00:22 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313342152.26.0.740730067024.issue12749@psf.upfronthosting.co.za>
Message-ID: <2651.1313348403@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote on Sun, 14 Aug 2011 17:15:52 -0000: 

>> You're right: my wide build is not Python3, just Python2.

> And is it failing?  Here the tests pass on the wide builds, on both Python 2 and 3.

Perhaps I am doing something wrong?

    linux% python --version
    Python 2.6.2

    linux% python -c 'import sys; print sys.maxunicode'
    1114111

    linux% cat -n bigrange.py
     1	#!/usr/bin/env python
     2	# -*- coding: UTF-8 -*-
     3	
     4	from __future__ import print_function
     5	from __future__ import unicode_literals
     6	
     7	import re
     8	
     9	flags = re.UNICODE
    10	
    11	if re.search("[a-z]", "c", flags): 
    12	    print("match 1 passed")
    13	else:
    14	    print("match 1 failed")
    15	
    16	if re.search("[?-?]", "?", flags): 
    17	    print("match 2 passed")
    18	else:
    19	    print("match 2 failed")
    20	
    21	if re.search("[\U0001D49C-\U0001D4B5]", "\U0001D49E", flags): 
    22	    print("match 3 passed")
    23	else:
    24	    print("match 3 failed")
    25	
    26	if re.search("[\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]",
    27	    "\N{MATHEMATICAL SCRIPT CAPITAL C}", flags): 
    28	    print("match 4 passed")
    29	else:
    30	    print("match 4 failed")

    linux% python bigrange.py
    match 1 passed
    Traceback (most recent call last):
      File "bigrange.py", line 16, in <module>
	if re.search("[?-?]", "?", flags): 
      File "/usr/lib64/python2.6/re.py", line 142, in search
	return _compile(pattern, flags).search(string)
      File "/usr/lib64/python2.6/re.py", line 245, in _compile
	raise error, v # invalid expression
    sre_constants.error: bad character range

>> In fact, it's even worse, because it's the stock build on Linux, 
>> which seems on this machine to be 2.6 not 2.7.

> What is worse?  FWIW on my system the default `python` is a 2.7 wide. `python3` is a 3.2 wide.

I meant that it was running 2.6 not 2.7.  

>> I have private builds that are 2.7 and 3.2, but those are both narrow.
>> I do not have a 3.3 build.  Should I?

> 3.3 is the version in development, not released yet.  If you have an
> HG clone of Python you can make a wide build of 3.x with ./configure
> --with-wide-unicode andof 2.7 using ./configure --enable-
> unicode=ucs4.

And Antoine Pitrou <pitrou at free.fr> wrote:

>> I have private builds that are 2.7 and 3.2, but those are both narrow.
>> I do not have a 3.3 build.  Should I?

> I don't know if you *should*. But you can make one easily by passing
> "--with-wide-unicode" to ./configure.

Oh good.  I need to read configure --help more carefully next time.
I have to some Lucene work this afternoon, so I can let several builds
chug along.  

Is there a way to easily have these co-exist on the same system?  I'm sure
I have to rebuild all C extensions for the new builds, but I wonder what to
about (for example) /usr/local/lib/python3.2 being able to be only one of
narrow or wide.  Probably I just to go reading the configure stuff better
for alternate paths.  Unsure.  

Variant Perl builds can coexist on the same system with some directories
shared and others not, but I often find other systems aren't quite that
flexible, usually requiring their own dedicated trees.  Manpaths can get
tricky, too.

>> I'm remembering why I removed Python2 from my Unicode talk, because
>> of how it made me pull my hair out.  People at the talk wanted to know
>> what I meant, but I didn't have time to go into it.  I think this
>> gets added to the hairpulling list.

> I'm not sure what you are referring to here.

There seem to many more things to get wrong with Unicode in v2 than in v3.

I don't know how much of this just my slowness at ramping up the learning
curve, how much is due to historical defaults that don't work well for 
Unicode, and how much is 

Python2:

    re.search(u"[\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]".encode('utf-8'), 
               u"\N{MATHEMATICAL SCRIPT CAPITAL C}".encode('utf-8'), re.UNICODE)

Python3:

    re.search("[\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]",
               "\N{MATHEMATICAL SCRIPT CAPITAL C}", re.UNICODE)

The Python2 version is *much* noisier.  

(1) You have keep remembering to u"..." everything because neither
        # -*- coding: UTF-8 -*-
    nor even
        from __future__ import unicode_literals
    suffices.  

(2) You have to manually encode every string, which is utterly bizarre to me.

(3) Plus you then have turn around and tell re, "Hey by the way, you know those
    Unicode strings I just passed you?  Those are Unicode strings, you know."
    Like it couldn't tell that already by realizing it got Unicode not byte 
    strings.  So weird.

It's a very awkward model.  Compare Perl's

   "\N{MATHEMATICAL SCRIPT CAPITAL C}" =~ /\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]/

That's the kind of thing I'm used to.   It knows those are Unicode pattern matches on
Unicode strings with Unicode semantics.  After all, the \N{?} always evaluates to
Unicode strings, so the regex engine of course is Unicodey then without being begged.
To do bytewise processing, I would have to manually do all that encoding rigamorale
like you show for Python2.  And I never want do that, because looking for code units
is way beneath the level of abstraction I strongly prefer to work with.  Code points
are as low as I go, and often not even there, since I often need graphemes or
sometimes even linguistic collating elements (n-graphs), like the <ch> or <ll>
digraphs in traditional Spanish or <dd> or <rh> in Welsh,  or heaven help us the 
<dz> or <sz> digraphs, the <dzs> or <tty> trigraphs, or the <ddsz> tetragraph 
in Hungarian.

    (Yes, only Hungarian alone has a tetragraph, and there are no pentagraphs;
     small solace that, though.)

FWIW, I give Python major kudos for having \N{?} available so that people 
no longer have to embed non-ASCII or magic numbers or ugly function
calls all over their code.    

  *  Non-ASCII sometimes has the advantages of legibility but paradoxically
     also sometimes has the disadvantage of illegibility, bizarre as that
     sounds.  It is too easy to be tricked by lookalikey font issues.

        16	if re.search("[?-?]", "?", flags): 

  *  Magic numbers quite simply suck.  Nobody knows what they are.

        21	if re.search("[\U0001D49C-\U0001D4B5]", "\U0001D49E", flags): 

  *  Requiring explicitly coded callouts to a library are at best tedious and
     annoying.  ICU4J's UCharacter and JDK7's Character classes both have
         String  getName(int codePoint)
     but JDK7 has nothing that goes the other way around; for that, ICU4J has
         int     getCharFromName(String name)
     and ICU4C has 
         UChar32 u_charFromName  (   UCharNameChoice     nameChoice, 
                                     const char *        name, 
                                     UErrorCode *        pErrorCode 
                )
     Anybody can see how deathly unwieldy and of that.  

ICU4C's regex library admits \N{?} just as Perl and Python do, but that 
class is not available in ICU4J, so you have to JNI to it as Android does.  
This is really much cleaner and clearer for maintenance:

        26	if re.search("[\N{MATHEMATICAL SCRIPT CAPITAL A}-\N{MATHEMATICAL SCRIPT CAPITAL Z}]",
        27	    "\N{MATHEMATICAL SCRIPT CAPITAL C}", flags): 

As far as I know, nothing but Perl and Python allows \N{?} in interpolated 
literals ? even for those few languages that *have* interolated literals.

One question: If one really must use code point numbers in strings, does Python 
have any clean uniform way to enter them besides having to choose the clunky \uHHHH 
vs \UHHHHHHHH thing?   The goal is to be able to specify any (legal) number of hex
digits without having to zero-pad them, which is especially with Pyton's \U, since
you usually only need 5 hex digits and only very rarely 6, but the dumb thing makes
you type all 8 of them every time anyway.

You should somehow be able to specify only as many hex digits as you actually need.
Ruby, and now also recent Unicode tech reports like current tr18, tend to use \u{?}
for that, The \x{?} flavor is used by Perl strings and regexes, plus also the regexes
in ICU, JDK7, and Matthew's regex library for Python.  

It's just a lot easier, which is why I miss it from regular Python strings.  It
occurs to me that you could add it completely backwards compatibily, since it is
currently a syntax error:

    % python3.2 -c 'print("\x65")'
    e

    % python3.2 -c 'print("\u0065")'
    e

    % python3.2 -c 'print("\u03B1")'
    ?

    % python3.2 -c 'print("\U0001D4E9")'
    ?

    % python3.2 -c 'print("\u{1D4E9}")'
      File "<string>", line 1
    SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \uXXXX escape
    Exit 1

    % python3.2 -c 'print("\x{1D4E9}")'
      File "<string>", line 1
    SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-2: truncated \xXX escape
    Exit 1

Perl only uses \x, not \x AND \u AND \U the way Python does, because 
ahem, it seems a bit silly to have three different ways to do it. :)

    % perl -le 'print "\x9"' | cat -t
    ^I
    % perl -le 'print "\x65"'
    e

    % perl -le 'print "\x{9}"' | cat -t
    ^I
    % perl -le 'print "\x{65}"'
    e
    % perl -le 'print "\x{3B1}"'
    ?
    % perl -le 'print "\x{FB03}"'
    ?
    % perl -le 'print "\x{1D4E9}"'
    ?
    % perl -le 'print "\x{1FFFF}"   lt "\x{100000}"'
    1
    % perl -le 'print "\x{10_FFFF}" gt "\x{01_FFFF}"'
    1

Thanks for your all your generous help and kindly patience.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 21:06:01 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 19:06:01 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313344015.71.0.218551063153.issue12729@psf.upfronthosting.co.za>
Message-ID: <12962.1313348749@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Sun, 14 Aug 2011 17:46:55 -0000: 

>> I'm a bit confused on this.  You no longer fix bugs in Python 2?

> We do, but it's unlikely that we will introduce major changes in behavior.

> Even if we had to get rid of narrow builds and/or fix len(), we would
> probably only do it in the next 3.x version (i.e. 3.3), and not in the
> next bug fix release of 3.2 (i.e. 3.2.2).

Antoine Pitrou <report at bugs.python.org> wrote
   on Sun, 14 Aug 2011 17:36:42 -0000:

> This is even truer for stable branches, and Python 2 is very much a
> stable branch now (no more feature releases after 2.7).

Does that mean you now go to 2.7.1, 2.7.2, etc?

I had thought that 2.6 was going to be the last, but then 2.7
ame out.  I think I remember Guido said something about there 
never being a 2.10, so I wasn't too surprised to see 2.7.  

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 21:36:26 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 14 Aug 2011 19:36:26 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313350586.62.0.349107172718.issue12749@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

On a narrow build, "\N{MATHEMATICAL SCRIPT CAPITAL A}" is stored as 2 code units, and neither re nor regex recombine them when compiling a regex or looking for a match.

regex supports \xNN, \uNNNN and \UNNNNNNNN and \N{XYZ} itself, so they can be used in a raw string literal, but it doesn't recombine code units.

I could add recombination to regex at some point if time has passed and no further progress has been made in the language's support for Unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 21:56:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 19:56:22 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313351782.96.0.717306448693.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Perhaps I am doing something wrong?

That's weird, I tried on a wide Python 2.6.6 too and it works even there.  Maybe a bug that got fixed between 2.6.2 and 2.6.6?  Or maybe something else?

> Is there a way to easily have these co-exist on the same system?

Here I have different HG clones, one for each release (2.7, 3.2, 3.3), and I run ./configure (--with-wide-unicode) && make -j2.  Then I just run ./python from there without installing it in the system.
You might do the same or look at "make altinstall".  If you run "make install" it will install it as the default Python, so that's probably what you want.  Another option is to use virtualenv.

> The Python2 version is *much* noisier.  

Yes, Python 3 fixed many of these things and it's a much "cleaner" language.

> (1) You have keep remembering to u"..." everything because neither
>        # -*- coding: UTF-8 -*-
>    nor even
>        from __future__ import unicode_literals
>    suffices.  

Before Unicode Python only had plain (byte)strings, when Unicode strings were introduced the u"..." syntax was chosen to distinguish them.  On Python 3, "..." is a Unicode string, whereas b"..." is used for bytes.
"# -*- coding: UTF-8 -*-" is only about the encoding used to save the file, and doesn't affect other things.  Also this is the default on Python 3 so it's not necessary anymore (it's ASCII (or iso-8859-1?) on Python2).
"from __future__ import unicode_literals" allows you to use "..." and b"..." instead of u"..." and "..." on Python 2.  In my example I used u"..." to be explicit and because I was running from the terminal without using unicode_literals.

> (2) You have to manually encode every string, which is utterly
> bizarre to me.

re works with both bytes and Unicode strings, on both Python 2 and Python 3.  I was encoding them to see if it was able to handle the range when it was in a UTF-8 encoded string, rather than a Unicode string.  Even if it didn't fail with an exception, it failed with a wrong result (and that's even worse).

> (3) Plus you then have turn around and tell re, "Hey by the way, you
> know those Unicode strings I just passed you?  Those are Unicode 
> strings, you know."
> Like it couldn't tell that already by realizing it got Unicode not
> byte strings.  So weird.

The re.UNICODE flags affects the behavior of e.g. \w and \d, it's not telling re that we are passing Unicode strings rather than bytes.  By default on Python 2 those only match ASCII letters and digits.  This is also fixed on Python 3, where by default they match non-ASCII letters and digits (unless you pass re.ASCII).

> *  Requiring explicitly coded callouts to a library are at best 
> tedious and annoying.  ICU4J's UCharacter and JDK7's Character 
> classes both have
>         String  getName(int codePoint)

FWIW we have unicodedata.lookup('SNOWMAN')

> One question: If one really must use code point numbers in strings, 
> does Python have any clean uniform way to enter them besides having
> to choose the clunky \uHHHH vs \UHHHHHHHH thing?

Nope.  OTOH it doesn't happen to often to use those (especially the \U version), so I'm not sure that it's worth adding something else just to save a few chars (also \x{12345} is only one char less than \U00012345).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:01:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 20:01:06 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313352066.08.0.482612421195.issue12729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

2.7 is the last 2.x.  There won't be any 2.8 (also I never heard that 2.6 was supposed to be the last).
We already have 2.7.2, and we will continue with 2.7.3, 2.7.4, etc for a few more years.  Eventually 2.7 will only get security fixes and the development will be focused on 3.x only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:03:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 20:03:52 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1313352232.87.0.261447945044.issue12749@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

BTW, you can find more information about the one-dir-per-clone setup (and other useful info) here: http://docs.python.org/devguide/committing.html#using-several-working-copies

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:28:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Aug 2011 20:28:37 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1313353717.55.0.274244349048.issue10744@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks for the patch. I agree with the interpretation of the format string.
One thing is unclear though: Using this interpretation the multi-dimensional 
array notation in format strings only seems useful for pointers to arrays.

The PEP isn't so clear on that, would you agree?


I'm not done reviewing the patch, just a couple of nitpicks:

  - We need a function declaration of _ctypes_alloc_format_string_with_shape()
    in ctypes.h.

  - prefix_len = 32*(ndim+1) + 3: This is surely sufficient, but (ndim+1)
    is not obvious to me. I think we need (20 + 1) * ndim + 3.

  - I'd use "%zd" for Py_ssize_t (I know that in other parts of the
    code "%ld" is used, too).

----------
assignee: theller -> 
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10744>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:36:48 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Aug 2011 20:36:48 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313354208.2.0.245392150355.issue12740@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Just to throw in a new name: Struct.nitems would also be possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:46:20 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 14 Aug 2011 20:46:20 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1313354780.62.0.95129727948.issue11835@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached patch for this issue.

This only happens on MSVC x64 (I actually tired to repro on Arch Linux x64 before starting work on it and it didn't repro).

What happens is that MSVC on x64 always passes structures larger than 8 bytes by reference. See here: http://msdn.microsoft.com/en-us/library/ms235286(v=vs.90).aspx

Now this was accounted for in callproc.c, line 1143 in development branch with this:

        if (atypes[i]->type == FFI_TYPE_STRUCT
#ifdef _WIN64
            && atypes[i]->size <= sizeof(void *)
#endif
            )
            avalues[i] = (void *)args[i].value.p;
        else
            avalues[i] = (void *)&args[i].value;

This fix wasn't made in libffi_msvc/ffi.c though. Here, regardless of whether we have x64 or x86 build, if z >= sizeof(int) we will hit else branch in libffi_msvc/ffi.c at line 114 and do:

      else
	{
	  memcpy(argp, *p_argv, z);
	}
      p_argv++;
      argp += z;

In our case, we copy 28 bytes as arguments (size of our structure) but in fact for x64 we only need 8 as structure is passed by reference so argument is just a pointer. My patch will adjust z before hitting if statement on x64 and it will cause correct copy as pointer.

----------
nosy: +vladris
Added file: http://bugs.python.org/file22899/issue11835_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Sun Aug 14 22:55:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Aug 2011 20:55:18 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313355318.56.0.09678509405.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tom, I appreciate your taking the time to help us improve our Unicode story. I agree that the compromises made a decade ago need to be revisited and revised.

I think it will help if you better understand our development process. Our current *intent* is that 'Python x.y' be a fixed language and that 'CPython x.y.0', '.1', '.2', etc be increasingly (and strictly -- no regressions) better implementations of Python x.y. (Of course, the distribution and installation names and up-to-now dropping of '.0' may confuse the distinction, but it is real.) As a consequence, correct Python x.y code that runs correctly on the CPython x.y.z implementation should run correctly on x.y.(z+1).

For the purpose of this tracker, a behavior issue ('bug') is a discrepancy between the documented intent of a supported Python x.y and the behavior of the most recent CPython x.y.z implementation thereof. A feature request is a design issue, a request for a change in the language definition (and in the corresponding .0 implementation). Most people (including you, obviously) that file feature requests regard them as addressing design bugs. But still, language definition bugs are different from implementation bugs.

Of course, this all assumes that the documents are correct and unambiguous. But accomplishing that can be as difficult as correct code. Obvious mistakes are quickly corrected. Ambiguities in relation to uncontroversial behavior are resolved by more exactly specifying the actual behavior. But ambiguities about behavior that some consider wrong, are messy. We can consult the original author if available, consult relevant tests if present, take votes, but some fairly arbitrary decision may be needed. A typical response may be to clarify behavior in the docs for the current x.y release and consider behavior changes for the next x.(y+1) release.

So the answer to your question, "Do we fix bugs?", is that we fix doc and implementation behavior bugs in the next micro x.y.z behavior bug-fix release and language design bugs in the next minor x.y language release. But note that language changes merely have to be improvements for Python in the future without necessarily worrying about whether a design decision made years ago was  or is a 'bug'.

The purpose of me discussing or questioning the 'type' of some of your issues is to *facilitate* change by getting the issue on the right track, in relation to our development process, as soon as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 14 23:42:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Aug 2011 21:42:57 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1313358177.44.0.901437728267.issue11835@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Mon Aug 15 00:29:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Aug 2011 22:29:24 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313360964.57.0.407057365646.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is off-topic, but there was discussion on whether or not to have a 2.7. The decision was to focus on back-porting things that would make the eventual transition to 3.x easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 00:48:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Aug 2011 22:48:08 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313362088.14.0.572596538579.issue12740@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In general, I think we can prevent confusion about the meaning of __len__ by sticking to the general rule:  len(object)==len(list(obj)) for anything that produces an iterable result.  In the case of struct, that would be the length of the tuple returned by struct.unpack() or the number of values consumed by struct.pack().

This choice is similar to what was done for collections.Counter where len(Counter(a=10, b=20)) returns 2 (the number of dict keys) rather than 30 (the number of elements in the Bag-like container).  A similar choice   was make for structseq objects when len(ss) == len(iter(ss)) despite there being other non-positional names that are retrievable.

It's true that we get greater clarity by spelling out the specific meaning in the context of structs, as in s.num_members or some such, but we start to lose the advantages of polymorphism and ease of learning/remembering that comes with having consistent API choices.  For any one API such as structs, it probably makes sense to use s.num_members, but for the standard library as a whole, it is probably better to try to make len(obj) have a consistent meaning rather than having many different names for the size of the returned tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Mon Aug 15 01:55:08 2011
From: report at bugs.python.org (hy)
Date: Sun, 14 Aug 2011 23:55:08 +0000
Subject: [issue12748] IDLE halts on osx when copy and paste
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313366108.1.0.456666471298.issue12748@psf.upfronthosting.co.za>


hy <hoyeung411 at gmail.com> added the comment:

Thank you. I kinda know what happens now.

First, I didn't made any change to IDLE after installed.

Second, I'm using dvorak-qwerty. Normally the keyboard layout changes to qwerty when I press Cmd key so that I can type in Dvorak and use the short cut in qwerty. But in IDLE it's not the same case. I find that the halt problem only occur when I copy. So I tried cut and paste. It happens that I can use both Cmd+x and Cmd+b (x in Dvorak layout) to cut and both Cmd+v and Cmd+.(v in Dvorak layout) to paste. So if I press Cmd+c, I'm inputting both Cmd+c and Cmd+j at the same time. And I think that's the reason why it halts. 

By hang, it's exactly what you described.

Also, i tried Tcl/Tk 8.4, the same problem happens.

It's weird since I don't have this problem in Windows when I use a third-party dvorak-qwerty input method.

I temporally changed to Dvorak now to avoid this problem, although there is a little bit inconvenient since all shortcut has changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Mon Aug 15 02:21:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 00:21:28 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313367688.35.0.32127762405.issue12672@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the sentence is a bit confusing and the 'object method' ambiguous. I suspect that the sentence was written years ago. In current Python, [].append is a bound method of class 'builtin_function_or_method'. I *suspect* that the intended contrast, and certainly the important one, is that between C functions, which get added to PyTypeObject structures, and their Python object wrappers that are visible from Python, but which must not be put in the type structure. The varieties of wrappers are irrelevant in this context and for the purpose of avoiding that mistake. So I would rewrite the sentence as:

These C functions are called ?type methods? to distinguish them from Python wrapper objects, such as ``list.append`` or ``[].append``, visible in Python code.

Looking further down,
"Now if you go and look up the definition of PyTypeObject in object.h you?ll see that it has many more fields that the definition above.",
needs 'that' changed to 'than' and I would insert " following tp_doc" after 'fields'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Mon Aug 15 02:26:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 00:26:53 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313368013.46.0.107285515249.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python's narrow builds are, in a sense, 'between' UCS-2 and UTF-16. They support non-BMP chars but only partially, because, BY DESIGN*, indexing and len are by code units, not codepoints. They are documented as being UCS-2 because that is what M-A Lemburg, the original designer and writer of Python's unicode type and the unicode-capable re module, wants them to be called. The link to msg142037, which is one of 50+ in the thread (and many or most other disagree), pretty well explains his viewpoint. The positive side is that we deliver more than we promise. The negative side is that by not promising what perhaps we should allows is not to deliver what perhaps we should.

*While I think this design decision may have been OK a decade ago for a first implementation of an *optional* text type, I do not think it so for the future for revised implementations of what is now *the* text type. I think narrow builds can and should be revised and upgraded to index, slice, and measure by codepoints. Here is my current idea:

If the code unit stream contains any non-BMP characters (ie, surrogate pair of 16-bit code units), construct a sequence of *indexes* of such characters (pairs). The fixed length of the string in codepoints is n-k, where n is the number of code units (the current length) and k is the length of the auxiliary sequence and the number of pairs. For indexing, look up the character index in the list of indexes by binary search and increment the codepoint index by the index of the index found to get the corresponding code unit index. (I have omitted the details needed avoid off-by-1 errors.)

This would make indexing O(log(k)) when there are surrogates. If that is really a problem because k is a substantial fraction of a 'large' n, then one should use a wide build. By using a separate internal class, there would be no time or space penalty for all-BMP text. I will work on a prototype in Python.

PS: The OSCON link in msg142036 currently gives me 404 not found

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 02:55:52 2011
From: report at bugs.python.org (Michael Hall)
Date: Mon, 15 Aug 2011 00:55:52 +0000
Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on
	Ubuntu 11.04
In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za>
Message-ID: <1313369752.52.0.799206220987.issue12738@psf.upfronthosting.co.za>


Michael Hall <michaelhall1k at gmail.com> added the comment:

I tried switching from joining on the work_queue to just joining on the individual child processes, and it seems to work now. Weird. Anyway, it'd be nice to see the JoinableQueue fixed, but it's not pressing any more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12738>
_______________________________________

From report at bugs.python.org  Mon Aug 15 03:28:59 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Aug 2011 01:28:59 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313371739.37.0.873991517212.issue12729@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Have a look here: http://98.245.80.27/tcpc/OSCON2011/gbu/index.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 03:58:26 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Mon, 15 Aug 2011 01:58:26 +0000
Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter
In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za>
Message-ID: <1313373506.25.0.783896937634.issue11835@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Changing type to behavior as it doesn't crash on 3.3. I believe issue was opened against 2.6 and Santoso changed it to 2.7 and up where there is no crash.

Another data point: there is similar fix in current version of libffi here: https://github.com/atgreen/libffi/blob/master/.pc/win64-struct-args/src/x86/ffi.c

Since at the moment we are not integrating new libffi, I believe my fix should do (libffi fix is slightly different but I'm matching what we have in callproc.c which is not part of libffi).

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11835>
_______________________________________

From report at bugs.python.org  Mon Aug 15 04:17:25 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 02:17:25 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313368013.46.0.107285515249.issue12729@psf.upfronthosting.co.za>
Message-ID: <26823.1313374629@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

"Terry J. Reedy" <report at bugs.python.org> wrote
   on Mon, 15 Aug 2011 00:26:53 -0000: 

> PS: The OSCON link in msg142036 currently gives me 404 not found

Sorry, I wrote 

     http://training.perl.com/OSCON/index.html

but meant 

     http://training.perl.com/OSCON2011/index.html

I'll fix it on the server in a short spell.

I am trying to keep the document up to date as I learn more, so it
isn't precisely the talk I gave in Portland.

> Python's narrow builds are, in a sense, 'between' UCS-2 and UTF-16.

So I'm finding.  Perhaps that's why I keep getting confused. I do have a pretty firm
notion of what UCS-2 and UTF-16 are, and so I get sometimes self-contradictory results.
Can you think of anywhere that Python acts like UCS-2 and not UTF-16?  I'm not sure I
have found one, although the regex thing might count.

Thank you guys for being so helpful and understanding.

> They support non-BMP chars but only partially, because, BY DESIGN*,
> indexing and len are by code units, not codepoints. 

That's what Java did, too, and for the same reason.  Because they had
a UCS-2 implementation for Unicode 1.1 so when Unicode 2.0 came out
and they learned that they would need more than 16 bits, they piggybacked
UTF-16 onto the top of it instead of going for UTF-8 or UTF-32, and they're
still paying that price, and to my mind, heavily and continually.

Do you use Java?  It is very like Python in many of its 16-bit character issues.
Most of the length and indexing type functions address things by code unit
only, not copepoint.  But they would never claim to be UCS-2.

Oh, I realize why they did it.  For one thing, they had bytecode out there
that they had to support.  For another, they had some pretty low-level APIs
that didn't have enough flexibility of abstraction, so old source had to keep
working as before, even though this penalized the future.  Forever, kinda.

While I wish they had done better, and kinda think they could have, it
isn't my place to say.  I wasn't there (well, not paying attention) when
this was all happening, because I was so underwhelmed by the how annoyingly
overhyped it was.  A billion dollars of marketing can't be wrong, you know?
I know that smart people looked at it, seriously.  I just find the cure
they devised to be more in the problem set than the solution set.

I like how Python works on wide builds, especially with Python3. I was
pretty surprised that the symbolic names weren't working right on the
earlier version of the 2.6 wide build I tried them on.

I know have both wide and narrow builds installed of both 2.7 and 3.2,
so that shouldn't happen again.

> They are documented as being UCS-2 because that is what M-A Lemburg,
> the original designer and writer of Python's unicode type and the unicode-
> capable re module, wants them to be called. The link to msg142037,
> which is one of 50+ in the thread (and many or most other disagree),
> pretty well explains his viewpoint.

Count me as one of those many/most others who disagree. :)

> The positive side is that we deliver more than we promise. The
> negative side is that by not promising what perhaps we should allows
> is not to deliver what perhaps we should.

It is always better to deliver more than you say than to deliver less.

> * While I think this design decision may have been OK a decade ago for
>   a first implementation of an *optional* text type, I do not think it
>   so for the future for revised implementations of what is now *the*
>   text type. I think narrow builds can and should be revised and
>   upgraded to index, slice, and measure by codepoints. 

Yes, I think so, too.  If you look at the growth curve of UTF-8 alone,
it has followed a mathematically exponential growth curve in the 
first decade of this century.  I suspect that will turn into an S
surve with with aymtoptotic shoulders any time now.  I haven't looked
at it lately, so maybe it already has.  I know that huge corpora I work
with at work are all absolutely 100% Unicode now.  Thank XML for that.

> Here is my current idea:

> If the code unit stream contains any non-BMP characters (ie, surrogate
> pair of 16-bit code units), construct a sequence of *indexes* of such
> characters (pairs). The fixed length of the string in codepoints is
> n-k, where n is the number of code units (the current length) and k is
> the length of the auxiliary sequence and the number of pairs. For
> indexing, look up the character index in the list of indexes by binary
> search and increment the codepoint index by the index of the index
> found to get the corresponding code unit index. (I have omitted the
> details needed avoid off-by-1 errors.)

> This would make indexing O(log(k)) when there are surrogates. If that
> is really a problem because k is a substantial fraction of a 'large'
> n, then one should use a wide build. By using a separate internal
> class, there would be no time or space penalty for all-BMP text. I
> will work on a prototype in Python.

You are a brave man, and good.  Bravo!

It may be that that was the sort of thing that Larry was talking to me
about 6-8 months ago regarding how to construct a better way to access
strings by grapheme index.  

Everyone always talks about important they're sure O(1) access must be, and how they
therefore abosolutely have to have it no matter the tradeoffs.  But without two
implementations to compare real-world access patterns against, one really can't know.  
I know that index/rindex and substring operations are very rare in how I myself process
strings, but I have seen how Python people turn to those all the time when I would
reflexively use a pattern match.  So usage patterns may very; hence the desire for real
comparisons.  I'm perfectly willing to be convinced, but I want to see real data.

If I get time, I'll check into whether the Perl 6 people have any real data about that.
I had thought that that Parrot was currently using ICU4C for its string handling, which
may mean they're afflicted by UTF-16, something I wouldn't think they would tolerate,
especially since they need code points above 0x10_FFFF for their Normalization Form G
(Grapheme).  Piggy packing that on UTF-16 would require stealing some Private Use code
point to act as multilevel surrogates so that UTF-16 is infinitely extensible the way
UTF-8 is.  Not sure what I think about that, but it's been mentioned as a loophole
escape for when Unicode has to renege on its 21-bit promise.  I sure hope everyone has
stopped using UTF-16 by then myself.  It's trouble enough right now.

Hm, now that I think ICU about it, ICU just might use int sequences interally, so UTF-
32, for its own strings, so that might be it.  Yes, I see they too are going for O(1)
access.  Nonetheless, a careful enough UTF-16 implementation with a rich enough API is
able to access all of Unicode with no trouble.  It's just that the Java API from Sun is
not one such.  The Perl 6 spec is all about graphemes, and graphemes are all about code
points, which means an implementation could work around 16-bit code units so the user
never has to think about them. That would be just like the Perl 5 implmentation works
around 8-bit code units and never let the user notice it.

Hey, if you can build TCP out of IP, anything is possible. :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 04:20:05 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 15 Aug 2011 02:20:05 +0000
Subject: [issue12693] test.support.transient_internet prints to stderr when
	verbose is false
In-Reply-To: <1312521271.03.0.978158187308.issue12693@psf.upfronthosting.co.za>
Message-ID: <1313374805.19.0.100837771951.issue12693@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The line from the source I am talking about is http://hg.python.org/cpython/file/49e9e34da512/Lib/test/support.py#l943 . And as for the output:

> ./python.exe -m test -uall test_ssl                                                  
[1/1] test_ssl
Resource 'ipv6.google.com' is not available
1 test OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12693>
_______________________________________

From report at bugs.python.org  Mon Aug 15 04:31:13 2011
From: report at bugs.python.org (Daniel O'Connor)
Date: Mon, 15 Aug 2011 02:31:13 +0000
Subject: [issue12750] datetime.datetime timezone problems
Message-ID: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>


New submission from Daniel O'Connor <darius at dons.net.au>:

It isn't possible to add a timezone to a naive datetime object which means that if you are getting them from some place you can't directly control there is no way to set the TZ.

eg pywws' DataStore returns naive datetime's which are in UTC. There is no way to set this and hence strftime seems to think they are in local time.

I can sort of see why you would disallow changing a TZ once set but it doesn't make sense to prevent this for naive DTs.

Also, utcnow() returns a naive DT whereas it would seem to be more sensible to return it with a UTC TZ.

----------
components: Library (Lib)
messages: 142095
nosy: Daniel.O'Connor
priority: normal
severity: normal
status: open
title: datetime.datetime timezone problems
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Mon Aug 15 05:31:13 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 03:31:13 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <26823.1313374629@chthon>
Message-ID: <24710.1313379053@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

I wrote:

>> Python's narrow builds are, in a sense, 'between' UCS-2 and UTF-16.

> So I'm finding.  Perhaps that's why I keep getting confused. I do have a pretty firm
> notion of what UCS-2 and UTF-16 are, and so I get sometimes self-contradictory results.
> Can you think of anywhere that Python acts like UCS-2 and not UTF-16?  I'm not sure I
> have found one, although the regex thing might count.

I just thought of one.  The casemapping functions don't work right on
Deseret, which is a non-BMP case-changing scripts.  That's one I submitted
as a bug, because I figure if the the UTF-8 decoder can decode the non-BMP
code points into paired UTF-16 surrogates, then the casing functions had
jolly well be able to deal with it.  If the UTF-8 decoder knows it is only
going to UCS-2, then it should have raised on exception on my non-BMP source.
Since it went to UTF-16, the rest of the language should have behaved accordingly.
Java does to this right, BTW, despite its UTF-16ness.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 06:18:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 04:18:45 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313381925.68.0.734607018807.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>It is always better to deliver more than you say than to deliver less.
Except when promising too little is a copout.

>Everyone always talks about important they're sure O(1) access must be,

I thought that too until your challenge. But now that you mention it, indexing is probably not the bottleneck in most document processing. We are optimizing without measuring! We all know that is bad.

If done transparently, non-O(1) indexing should only be done when it is *needed*. And if it is a bottleneck, switch to a wide build -- or get a newer, faster machine.

I first used Python 1.3 on a 10 megahertz DOS machine. I just got a  multicore 3.+ gigahertz machine. Tradeoffs have changed and just as we use cycles (and space) for nice graphical interfaces, we should use some for global text support. In the same pair of machines, core memory jumped from 2 megabytes to 24 gigabytes. (And the new machine cost perhaps as much in adjusted dollars.) Of course, better unicode support should come standard with the OS and not have to be re-invented by every language and app.

Having promised to actually 'work on a prototype in Python', I decided to do so before playing. I wrote the following test:

tucs2 = 'A\U0001043cBC\U0001042f\U00010445DE\U00010428H'
tutf16= UTF16(tucs2)
tlist = ['A', '\U0001043c','B','C','\U0001042f','\U00010445',
         'D','E','\U00010428','H']
tlis2 = [tutf16[i] for i in range(len(tlist))]
assert tlist == tlis2

and in a couple hours wrote and debugged the class to make it pass (and added a couple of length tests). See the uploaded file.

Adding an __iter__ method to iterate by characters (with hi chars returned as wrapped length-1 surrogate pairs) instead of code units would be trivial. Adding the code to __getitem__ to handle slices should not be too hard. Slices containing hi characters should be wrapped. The cpdex array would make that possible without looking at the whole slice.

The same idea could be used to index by graphemes. For European text that used codepoints for pre-combined (accented) characters as much as possible, the overhead should not be too much. 

This may not be the best issue to attach this to, but I believe that improving the narrow build would allow fixing of the re/regex problems reported here.

----------
Added file: http://bugs.python.org/file22900/utf16.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 06:26:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 04:26:32 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313382392.05.0.97118641401.issue12672@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Mon Aug 15 06:56:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 04:56:54 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313384214.92.0.150594455382.issue12729@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Keep in mind that we should be able to access and use lone surrogates too, therefore:
s = '\ud800'  # should be valid
len(s)  # should this raise an error? (or return 0.5 ;)?
s[0]  # error here too?
list(s)  # here too?

p = s + '\udc00'
len(p)  # 1?
s[0]  # '\U00010000' ?
s[1]  # IndexError?
list(p + 'a')  # ['\ud800\udc00', 'a']?

We can still decide that strings with lone surrogates work only with a limited number of methods/functions but:
1) it's not backward compatible;
2) it's not very consistent

Another thing I noticed is that (at least on wide builds) surrogate pairs are not joined "on the fly":
>>> p
'\ud800\udc00'
>>> len(p)
2
>>> p.encode('utf-16').decode('utf-16')
'?'
>>> len(_)
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 08:22:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 06:22:46 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <E1QsqZQ-00072B-PL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c34772013c53 by Ezio Melotti in branch '3.2':
#12266: Fix str.capitalize() to correctly uppercase/lowercase titlecased and cased non-letter characters.
http://hg.python.org/cpython/rev/c34772013c53

New changeset eab17979a586 by Ezio Melotti in branch '2.7':
#12266: Fix str.capitalize() to correctly uppercase/lowercase titlecased and cased non-letter characters.
http://hg.python.org/cpython/rev/eab17979a586

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Mon Aug 15 08:27:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 06:27:47 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <E1QsqdG-0007JU-Dx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1ea72da11724 by Ezio Melotti in branch 'default':
#12266: merge with 3.2.
http://hg.python.org/cpython/rev/1ea72da11724

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Mon Aug 15 08:31:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 06:31:57 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <1313389917.58.0.241285100953.issue12266@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
resolution: duplicate -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Mon Aug 15 08:53:34 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 06:53:34 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313384214.92.0.150594455382.issue12729@psf.upfronthosting.co.za>
Message-ID: <20871.1313391185@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote on Mon, 15 Aug 2011 04:56:55 -0000: 

> Another thing I noticed is that (at least on wide builds) surrogate pairs are not joined "on the fly":
> >>> p
> '\ud800\udc00'
> >>> len(p)
> 2
> >>> p.encode('utf-16').decode('utf-16')
> '?'
> >>> len(_)
> 1

    (For those who may not immediately realize from reading the surrogates,
     '?' is code point 0x10000, the first non-BMP code point.  I piped it 
     through `uniquote -x` just to make sure.)

Yes, that makes perfect sense.  It's something of a buggy feature or featureful bug
that UTF-16 does this.  

When you are thinking of arbitrary sequences of code points, which is
something you have be able to do in memory but not in a UTF stream, then
one can say that one has four code points of anything in the 0 .. 0x10FFFF
range.  Those can be any arbitrary code points only (1) *while* in memory,
*and* assuming a (2) non-UTF16, ie UTF-32 or UTF-8 representation.  You
cannot do that with UTF-16, which is why it works only on a Python wide
build.  Otherwise they join up.

The reason they "join up" in UTF-16 is also the reason why unlike in regular
memory where you might be able to use an alternate representation like UTF-8 or
UTF-32, UTF streams cannot contain unpaired surrogates: because if that stream
were in UTF-16, you would never be able to tell the difference between a
sequence of a lead surrogate followed by a tail surrogate and the same thing
meaning just one non-BMP code point.  Since you would not be able to tell the
difference, it always only means the latter, and the former sense is illegal.
This is why lone surrogates are illegal in UTF streams.

In case it isn't obvious, *this* is the source of the [?--?] bug in all
the UTF-16 or UCS-2 regex languages. It is why Java 7 added \x{...}, so
that they can rewrite that as [\x{1D49C}--\x{1D4B5}] to pass the regex
compiler, so that it seems something indirect, not just surrogates.

That's why I always check it in my cross-language regex tests.  A 16-bit
language has to have a workaround, somehow, or it will be in trouble.

The Java regex compiler doesn't generate UTF-16 for itself, either. It
generates UTF-32 for its pattern.  You can see this right at the start of
the source code.  This is from the Java Pattern class:

    /**
     * Copies regular expression to an int array and invokes the parsing
     * of the expression which will create the object tree.
     */
    private void compile() {
        // Handle canonical equivalences
        if (has(CANON_EQ) && !has(LITERAL)) {
            normalize();
        } else {
            normalizedPattern = pattern;
        }
        patternLength = normalizedPattern.length();

        // Copy pattern to int array for convenience
        // Use double zero to terminate pattern
        temp = new int[patternLength + 2];

        hasSupplementary = false;
        int c, count = 0;
        // Convert all chars into code points
        for (int x = 0; x < patternLength; x += Character.charCount(c)) {
            c = normalizedPattern.codePointAt(x);
            if (isSupplementary(c)) {
                hasSupplementary = true;
            }
            temp[count++] = c;
        }

        patternLength = count;   // patternLength now in code points

See how that works?  They use an int(-32) array, not a char(-16) array!  It's reasonably
clever, and necessary.  Because it does that, it can now compile \x{1D49C} or erstwhile
embedded UTF-8 non-BMP literals into UTF-32, and not get upset by the stormy sea of
troubles that surrogates are. You can't have surrogates in ranges if you don't do
something like this in a 16-bit language.

Java couldn't fix the [?--?] bug except by doing the \x{...} indirection trick,
because they are stuck with UTF-16.  However, they actually can match the string
"?" against the pattern "^.$", and have it fail on "^..$".   Yes, I know: the
code-unit length of that string is 2, but its regex count is just one dot worth.

I *believe* they did it that way because tr18 says it has to work that way, but
they may also have done it just because it makes sense.  My current contact at
Oracle doing regex support is not the guy who originally wrote the class, so I
am not sure.  (He's very good, BTW.  For Java 7, he also added named captures,
script properties, *and* brought the class up to conformance with tr18's 
"level 1" requirements.)

I'm thinking Python might be able to do in the regex engine on narrow builds the 
sort of thing that Java does.  However, I am also thinking that that might
be a lot of work for a situation more readily addressed by phasing out narrow
builds or at least telling people they should use wide builds to get that thing
to work.  

--tom

======================================================================

        ============================================
        ===>  QUASI OFF TOPIC ADDENDUM FOLLOWS  <===
        ============================================

The rest of this message is just a comparison demo of how Perl treats the
same sort of surrogate stuff that you were showing with Python. I'm not
sure that it as relevant to your problem as the Java part just was, since
we don't have UTF-16 the way Java does.  

One place it *may* be relevant to Python, which is the only reason I'm
including it, is that it shows what sort of elastic boundaries you have
with the old loose form utf8 that you no longer have with the current
strict definition of UTF-8 from the Unicode Standard.  

It turns out that you can't play those surrogate halvsies games in Perl,
because it thinks you're nuts. :)

   (Whether this is a bug or a feature may depend on where you're standing, but
    we're trying to conform with our reading of the Standard.  Things like the
    Unicode Collation Algorithm have third-party conformance suites, but I
    don't know of any for encoders/decoders, so one is back to deciding whether
    one has correctly understood the Standard.  As we all know, this isn't
    always all that easy.)

This is the clincher at the far end, so you can quit reading now if you want:

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}")' | uniquote -b 
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}\x{DC00}")' | uniquote -b
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    UTF-16 surrogate U+DC00 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00\x00\x00

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}"), encode("UTF-16LE", "\x{DC00}")' | uniquote -b 
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    UTF-16 surrogate U+DC00 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00\x00\x00

(Meanwhile, back to the quasi-off-topic monologue.)

Oh, you can have isolated surrogates in memory just fine.  We use abstract
code points not code units, and since we aren't UTF-16, there's no problem there:

    % perl -le 'print length("\x{D800}")'
    1
    % perl -le 'print length("\x{D800}\x{DC00}")'
    2
    % perl -le 'print length("\x{DC00}\x{D800}")'
    2

But you aren't allowed to *encode* those abstract characters into a UTF encoding form.  

        (The -CS switch is like having PERLUNICODE=S or PYTHONIOENCODING=utf8)

    % perl -CS -le 'print "\x{D800}\x{DC00}"'
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Unicode surrogate U+DC00 is illegal in UTF-8 at -e line 1.
    ??????

Now, you might think my encoder did that, but it didn't.  Those "??????" are is from my
dumb Mac Terminal, *not* from the Perl utf8 encoder.  This is yet another reason, BTW, 
why using "?" for the replacement for a non-encodable code point is strongly discouraged 
by Unicode.  Otherwise it is too hard whether it is a "?" because it was in the original
data or a "?" because it was a replacment char.  Some of our encoders do use

     ?  FFFD        REPLACEMENT CHARACTER
        * used to replace an incoming character whose value is unknown or unrepresentable in Unicode
        * compare the use of 001A as a control character to indicate the substitute function

But that isn't triggering here.  Run through uniquote shows that you got
illegal surrogates in your (loose) utf8 stream:

    % perl -CS -le 'print "\x{D800}\x{DC00}"' | uniquote -x
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Unicode surrogate U+DC00 is illegal in UTF-8 at -e line 1.
    \x{D800}\x{DC00}

Use -b on uniquote to get bytes not hex chars:

    % perl -CS -le 'print "\x{D800}\x{DC00}"' | uniquote -b
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Unicode surrogate U+DC00 is illegal in UTF-8 at -e line 1.
    \xED\xA0\x80\xED\xB0\x80

Yes, I'm not fond of the dribbled-out warning, either.  It should of course be
an exception.  Part of what is going on here is that Perl's regular "utf8"
encoding is the (I believe) the same loose one that Python also uses, the old
one from before the restrictions. If you use the strict "UTF-8", then you get...

    % perl -le 'binmode(STDOUT, "encoding(UTF-8)"); print "\x{D800}\x{DC00}"' 
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Unicode surrogate U+DC00 is illegal in UTF-8 at -e line 1.
    "\x{d800}" does not map to utf8.
    "\x{dc00}" does not map to utf8.
    \x{D800}\x{DC00}

Which is pretty whacky.  I'm *not* uniquoting that this time around, the
encoder is.   It did the \x{} substitution because it is absolutely
forbidden from ever emitting surrogates in a valid strict UTF-8 stream,
the way it will begrudgingly do in a loose utf8 stream (although the
result is not valid as strict UTF-8).

If you run with all warnings promoted into exceptions (as I almost always do),
then you get more reasonable behavior, maybe.   I'm going to use a command-line
switch that's just like saying

    use warnings "FATAL" => "all".

in the top-level scope.  First with loose utf8:

    % perl -Mwarnings=FATAL,all -CS -le 'print "\x{D800}\x{DC00}"' 
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Exit 255

And next with strict UTF-8:

    % perl -Mwarnings=FATAL,all -le 'binmode(STDOUT, "encoding(UTF-8)"); print "\x{D800}\x{DC00}"' 
    Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
    Exit 25

So when you make them fatal, you get an exception -- which by not being caught,
causes the program to exit.  

    (The "Exit" is printed by my shell, and no, I'm sorry but I don't
     know why the status value differs.  Well, kinda I know.  It's
     because errno was 25 (ENOTTY) in the second case, but had been 0 in
     the first case so that turned into an unsigned char -1.)

If you *promise* Perl you know what you're doing and full speed ahead, you can
disable utf8 warnings, which will work to get you your two surrogates in the
outbound *loose* utf8 stream, as six bytes that look like UTF-8 but actually
"can't" be (called that) due to the Standard's rules:

    % perl -M-warnings=utf8  -CS -le 'print "\x{D800}\x{DC00}"'
    ??????
    % perl -M-warnings=utf8 -CS -le 'print "\x{D800}\x{DC00}"' | uniquote -x
    \x{D800}\x{DC00}
    % perl -M-warnings=utf8 -CS -le 'print "\x{D800}\x{DC00}"' | uniquote -b
    \xED\xA0\x80\xED\xB0\x80

    (The weird module import is like saying 
        no warnings "utf8";
    as the outer scope.)

You can't get it with strict UTF-8 no matter how hard you try though.  Only
the loose one will put out invalid UTF-8.

So what about UTF-16?  Can we build things up piecemeal?  Turns out that
no, we can't.  I *think* this is a feature, but I'm not 100.000% sure.

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}")' | uniquote -b 
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}\x{DC00}")' | uniquote -b
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    UTF-16 surrogate U+DC00 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00\x00\x00

    % perl -MEncode -le 'print encode("UTF-16LE", "\x{D800}"), encode("UTF-16LE", "\x{DC00}")' | uniquote -b 
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    UTF-16 surrogate U+DC00 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00\x00\x00

You get all nulls because it refused to give you anything for surrogates.
Although you can force it for UTF-8 if you use the loose utf8 version that
is out of spec, there is just nothing you can to do encode into UTF-16 
code points that are surrogates.  Just can't.  There is no loose UTF-16.

Or that's what it looks like to me.  You can have surrogates in memory, but
those cannot make into a UTF-16 stream.  Or a UTF-32 stream either.

    % perl -MEncode -le 'print encode("UTF-32LE", "\x{D800}")' | uniquote -b
    UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.
    \x00\x00\x00\x00

You have to encode integral code points, not halvsies:

    % perl -C0 -MEncode -le 'print encode("UTF-16BE", "\x{10000}")' | uniquote -b
    \xD8\x00\xDC\x00
    % perl -C0 -MEncode -le 'print encode("UTF-16LE", "\x{10000}")' | uniquote -b
    \x00\xD8\x00\xDC
    % perl -C0 -MEncode -le 'print encode("UTF-16",   "\x{10000}")' | uniquote -b
    \xFE\xFF\xD8\x00\xDC\x00

    % perl -C0 -MEncode -le 'print encode("UTF-32BE", "\x{10000}")' | uniquote -b
    \x00\x01\x00\x00
    % perl -C0 -MEncode -le 'print encode("UTF-32LE", "\x{10000}")' | uniquote -b
    \x00\x00\x01\x00
    % perl -C0 -MEncode -le 'print encode("UTF-32",   "\x{10000}")' | uniquote -b
    \x00\x00\xFE\xFF\x00\x01\x00\x00

    % perl -C0 -MEncode -le 'print encode("UTF-8",    "\x{10000}")' | uniquote -b
    \xF0\x90\x80\x80
    % perl -C0 -MEncode -le 'print encode("UTF-8",    "\x{10000}")' | uniquote -x
    \x{10000}

    % perl -C0 -MEncode -le 'print encode("UTF-8",    "\x{10000}")' 
    ?
    % perl -CS          -le 'print                    "\x{10000}" ' 
    ?

tom++

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 09:04:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 07:04:59 +0000
Subject: [issue12266] str.capitalize contradicts oneself
In-Reply-To: <1307253299.62.0.8609224268.issue12266@psf.upfronthosting.co.za>
Message-ID: <E1QsrEI-0001IK-4d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d3816fa1bcdf by Ezio Melotti in branch '2.7':
#12266: move the tests in test_unicode.
http://hg.python.org/cpython/rev/d3816fa1bcdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12266>
_______________________________________

From report at bugs.python.org  Mon Aug 15 10:17:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 08:17:58 +0000
Subject: [issue12711] Explain tracker components in devguide
In-Reply-To: <1312816793.58.0.483795700679.issue12711@psf.upfronthosting.co.za>
Message-ID: <1313396278.21.0.23563998487.issue12711@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in http://hg.python.org/devguide/rev/c9dd231b0940

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12711>
_______________________________________

From report at bugs.python.org  Mon Aug 15 10:28:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 08:28:57 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1313396937.56.0.613744905156.issue12746@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #12737.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12746>
_______________________________________

From report at bugs.python.org  Mon Aug 15 10:29:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 08:29:28 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313396968.57.0.498954535422.issue12737@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #12746.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Mon Aug 15 11:00:31 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 09:00:31 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1313398831.17.0.869812056016.issue12746@psf.upfronthosting.co.za>


Changes by Tom Christiansen <tchrist at perl.com>:


----------
nosy: +tchrist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12746>
_______________________________________

From report at bugs.python.org  Mon Aug 15 11:04:59 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Aug 2011 09:04:59 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313384214.92.0.150594455382.issue12729@psf.upfronthosting.co.za>
Message-ID: <4E48E136.2090802@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

> Keep in mind that we should be able to access and use lone surrogates too, therefore:
> s = '\ud800'  # should be valid
> len(s)  # should this raise an error? (or return 0.5 ;)?
> s[0]  # error here too?
> list(s)  # here too?
> 
> p = s + '\udc00'
> len(p)  # 1?
> s[0]  # '\U00010000' ?
> s[1]  # IndexError?
> list(p + 'a')  # ['\ud800\udc00', 'a']?
> 
> We can still decide that strings with lone surrogates work only with a limited number of methods/functions but:
> 1) it's not backward compatible;
> 2) it's not very consistent
> 
> Another thing I noticed is that (at least on wide builds) surrogate pairs are not joined "on the fly":
>>>> p
> '\ud800\udc00'
>>>> len(p)
> 2
>>>> p.encode('utf-16').decode('utf-16')
> '?'
>>>> len(_)
> 1

Hi Tom,

welcome to Python land :-) Here's some more background information
on how Python's Unicode implementation works:

You need to differentiate between Unicode code points stored in
Unicode objects and ones encoded in transfer formats by codecs.

We generally do allow lone surrogates, unassigned code
points, lone combining code points, etc. in Unicode objects
since Python needs to be able to work on all Unicode code points
and build strings with them.

The transfer format codecs do try to combine surrogates
on decoding data on UCS4 builds. On UCS2 builds they create
surrogate pairs as necessary. On output, those pairs will again
be joined to get round-trip safety.

It helps if you think of Python's Unicode objects using UCS2
and UCS4 instead of UTF-16/32. Python does try to make working
with UCS2 easy and in many cases behaves as if it were using
UTF-16 internally, but there are, of course, limits to this. In
practice, you only rarely get to see any of these special cases,
since non-BMP code points are usually not found in everyday
use. If they do become a problem for you, you have the option
of switching to a UCS4 build of Python.

You also have to be aware of the fact that Python started
Unicode in 1999/2000 with Unicode 2.0/3.0, so it uses the
terminology of those versions, some of which has changed in
more recent versions of Unicode.

For more background information, you might want take a look
at this talk from 2002:

http://www.egenix.com/library/presentations/#PythonAndUnicode

Related to the other tickets you opened You'll also find that
collation and compression was already on the plate back then,
but since no one step forward, it wasn't implemented.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                50 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
nosy: +lemburg
title: Python lib re cannot handle Unicode properly due to narrow/wide bug -> Python lib re cannot handle Unicode properly due to	narrow/wide bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:06:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 10:06:25 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
Message-ID: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

A lot of code is duplicated in unicodeobject.c to manipulate ("encode/decode") surrogates. Each function has from one to three different implementations. The new decode_ucs4() function adds a new implementation. Attached patch replaces this code by macros.

I think that only the implementations of IS_HIGH_SURROGATE and IS_LOW_SURROGATE are important for speed. ((ch & 0xFFFFFC00UL) == 0xD800) (from decode_ucs4) is *a little bit* faster than (0xD800 <= ch && ch <= 0xDBFF) on my CPU (Atom Z520 @ 1.3 GHz): running test_unicode 4 times takes ~54 sec instead of ~57 sec (-3%).

These 3 macros have to be checked, I wrote the first one:

#define IS_SURROGATE(ch) (((ch) & 0xFFFFF800UL) == 0xD800)
#define IS_HIGH_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xD800)
#define IS_LOW_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xDC00)

I added cast to Py_UCS4 in COMBINE_SURROGATES to avoid integer overflow if Py_UNICODE is 16 bits (narrow build). It's maybe useless.

#define COMBINE_SURROGATES(ch1, ch2) \
 (((((Py_UCS4)(ch1) & 0x3FF) << 10) | ((Py_UCS4)(ch2) & 0x3FF)) + 0x10000)

HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument has been preproceed to fit in [0; 0xFFFF]. I added this requirement in the comment of these macros. It would be better to have only one macro to do the two operations, but because "*p++" (dereference and increment) is usually used, I prefer to avoid one unique macro (I don't like passing *p++ in a macro using its argument more than once).

Or we may add a third macro using HIGH_SURROGATE and LOW_SURROGATE.

I rewrote the main loop of PyUnicode_EncodeUTF16() to avoid an useless test on ch2 on narrow build.

I also added a IS_NONBMP macro just because I prefer macro over hardcoded constants.

----------
files: unicode_macros.patch
keywords: patch
messages: 142108
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, loewis, pitrou, tchrist, terry.reedy
priority: normal
severity: normal
status: open
title: Use macros for surrogates in unicodeobject.c
versions: Python 3.3
Added file: http://bugs.python.org/file22901/unicode_macros.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:10:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 10:10:09 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313403009.34.0.750389313817.issue12751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We may use the following unlikely macro for IS_SURROGATE, IS_HIGH_SURROGATE and IS_LOW_SURROGATE:

#define likely(x)	__builtin_expect(!!(x), 1)
#define unlikely(x)	__builtin_expect(!!(x), 0)

I suppose that we should use microbenchmarks to validate these macros?

Should I open a new issue for this idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:20:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:20:26 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1313403626.16.0.499976455012.issue12737@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

So the issue here is that while using combing chars, str.title() fails to titlecase the string properly.

The algorithm implemented by str.title() [0] is quite simple: it loops through the code units, and uppercases all the chars that follow a char that is not lower/upper/titlecased.
This means that if D?me doesn't use combining accents, the char before the 'm' is '?', '?' is a lowercase char, so 'm' is not capitalized.
If the '?' is represented as 'e' + '?', the char before the 'm' is '?', '?' is not a lower/upper/titlecase char, so the 'm' is capitalized.

I guess we could normalize the string before doing the title casing, and then normalize it back.
Also the str methods don't claim to follow Unicode afaik, so unless we decide that they should, we could implement whatever algorithm we want.

[0]: Objects/unicodeobject.c:6752

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:23:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:23:32 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313403812.84.0.540180692065.issue12751@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This has been proposed already in #10542 (the issue also has patches).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:30:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:30:03 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313404203.74.0.80585032843.issue12731@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the regex module works fine here, I think it's better to leave the re module alone and include the regex module in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:43:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:43:45 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313405025.2.0.708995236328.issue12734@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This indeed should be "fixed" by replacing 're' with 'regex'.  So I would suggest to focus your tests on 'regex' and report them there so that possible bugs gets fixed and tested before we include the module in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12734>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:45:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:45:43 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1313405143.81.0.0140310672233.issue12733@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

As I said on #12734 and #12731, if the 'regex' module address this issue, we should just wait until we include it in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12733>
_______________________________________

From report at bugs.python.org  Mon Aug 15 12:59:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:59:05 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313405945.7.0.061445246957.issue12730@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is actually a duplicated of #9200.

@Terry

> Besides which, all I see (on Windowsj) in Firefox is things like
> "????????????????????????????".

Encoding problem.  Firefox thinks this is some iso-8859-*.  You can fix this selecting 'Unicode (UTF-8)' from "View -> Character Encoding".

> IDLE just has empty boxes.

This is most likely because it doesn't use a font able to display those chars.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> str.isprintable() is always False for large code points

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:01:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:01:48 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313406108.56.0.333271162975.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I closed #12730 as a duplicate of this and updated the title of this issue.

----------
title: str.isprintable() is always False for large code points -> Make str methods work with non-BMP chars on narrow builds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:02:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:02:00 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313406120.21.0.66136050137.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also #12751.

----------
nosy: +tchrist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:02:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:02:22 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313406142.87.0.374591675712.issue9200@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +tchrist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:12:42 2011
From: report at bugs.python.org (Julian Taylor)
Date: Mon, 15 Aug 2011 11:12:42 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
Message-ID: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>


New submission from Julian Taylor <jtaylor.debian at googlemail.com>:

using unicode strings for locale.normalize gives following traceback with python2.7:

~$ python2.7 -c 'import locale; locale.normalize(u"en_US")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/locale.py", line 358, in normalize
    fullname = localename.translate(_ascii_lower_map)
TypeError: character mapping must return integer, None or unicode

with python2.6 it works and it also works with non-unicode strings in 2.7

----------
components: Unicode
messages: 142118
nosy: jtaylor
priority: normal
severity: normal
status: open
title: locale.normalize does not take unicode strings
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:13:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:13:38 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313406818.82.0.974899997069.issue12752@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:29:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 11:29:03 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <E1QsvLp-0003ry-OW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 16edc5cf4a79 by Ezio Melotti in branch '3.2':
#12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/16edc5cf4a79

New changeset fb49394f75ed by Ezio Melotti in branch '2.7':
#12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/fb49394f75ed

New changeset c821e3a54930 by Ezio Melotti in branch 'default':
#12204: merge with 3.2.
http://hg.python.org/cpython/rev/c821e3a54930

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:29:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:29:57 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313407797.8.0.966466340051.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:30:38 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 15 Aug 2011 11:30:38 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1313407838.22.0.985651825404.issue12729@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

For what it's worth, I've had idea about string storage, roughly based on how *nix stores data on disk.

If a string is small, point to a block of codepoints.

If a string is medium-sized, point to a block of pointers to codepoint blocks.

If a string is large, point to a block of pointers to pointer blocks.

This means that a large string doesn't need a single large allocation.

The level of indirection can be increased as necessary.

For simplicity, all codepoint blocks contain the same number of codepoints, except the final codepoint block, which may contain fewer.

A codepoint block may use the minimum width necessary (1, 2 or 4 bytes) to store all of its codepoints.

This means that there are no surrogates and that different sections of the string can be stored in different widths to reduce memory usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 15 13:59:23 2011
From: report at bugs.python.org (Julian Taylor)
Date: Mon, 15 Aug 2011 11:59:23 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313409563.28.0.053916693114.issue12752@psf.upfronthosting.co.za>


Julian Taylor <jtaylor.debian at googlemail.com> added the comment:

this is a regression introduced by fixing http://bugs.python.org/issue1813

This breaks some user code,. e.g. wx.Locale.GetCanonicalName returns unicode.
Example bugs:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/824734
https://bugs.launchpad.net/ubuntu/+source/playonlinux/+bug/825421

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:01:48 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 15 Aug 2011 12:01:48 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <4E490AA7.8040506@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Julian Taylor wrote:
> 
> New submission from Julian Taylor <jtaylor.debian at googlemail.com>:
> 
> using unicode strings for locale.normalize gives following traceback with python2.7:
> 
> ~$ python2.7 -c 'import locale; locale.normalize(u"en_US")'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
>   File "/usr/lib/python2.7/locale.py", line 358, in normalize
>     fullname = localename.translate(_ascii_lower_map)
> TypeError: character mapping must return integer, None or unicode
> 
> with python2.6 it works and it also works with non-unicode strings in 2.7

This looks like a side-effect of the change Antoine made to the locale
module when trying to make the case mapping work in a non-locale
dependent way.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:05:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Aug 2011 12:05:21 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313409921.15.0.463652306347.issue12204@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Are you sure this should have been backported?  Are there any apps that may be working now but won't be after the next point release?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:11:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Aug 2011 12:11:28 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313410163.3557.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument
> has been preproceed to fit in [0; 0xFFFF]. I added this requirement in
> the comment of these macros.

The macros should preprocess the argument themselves. It will make the
code even simpler.
Otherwise +1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:40:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 12:40:44 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412044.54.0.62685309529.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is only a doc patch, maybe you are confusing this issue with #12266?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:47:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Aug 2011 12:47:19 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412439.45.0.797327557605.issue12204@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Right.  I was looking at the other patches that went in in the last 24 hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 14:50:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 12:50:11 +0000
Subject: [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412611.24.0.872094945914.issue12204@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It's unlikely that #12266 might break apps.  The behavior changed only for fairly unusual characters, and the old behavior was clearly wrong.
FWIW the str.capitalize() implementation of PyPy doesn't have the bug, and after the fix both CPython and PyPy have the same behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12204>
_______________________________________

From report at bugs.python.org  Mon Aug 15 16:09:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Aug 2011 14:09:46 +0000
Subject: [issue12750] datetime.datetime timezone problems
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313417386.16.0.809512171771.issue12750@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In what way does 'replace' not satisfy your need to set the tzinfo?

As for utcnow, we can't change what it returns for backward compatibility reasons, but you can get a non-naive utc datatime by doing datetime.now(timezone.utc).  (I must admit, however, that at least this morning I can't wrap my head around how that works based on the docs :(.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Mon Aug 15 16:23:44 2011
From: report at bugs.python.org (Daniel O'Connor)
Date: Mon, 15 Aug 2011 14:23:44 +0000
Subject: [issue12750] datetime.datetime timezone problems
In-Reply-To: <1313417386.16.0.809512171771.issue12750@psf.upfronthosting.co.za>
Message-ID: <E6F8BC0C-E2C3-4D3A-8828-4D9F0B2EE19A@dons.net.au>


Daniel O'Connor <darius at dons.net.au> added the comment:

On 15/08/2011, at 23:39, R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> In what way does 'replace' not satisfy your need to set the tzinfo?

Ahh that would work, although it is pretty clumsy since you have to specify everything else as well.

In the end I used calendar.timegm (which I only found out about after this).

> As for utcnow, we can't change what it returns for backward compatibility reasons, but you can get a non-naive utc datatime by doing ?

That is a pity :(

> datetime.now(timezone.utc).  (I must admit, however, that at least this morning I can't wrap my head around how that works based on the docs :(.

OK.. I am only using 2.7 so I can't try that :)

> 
> ----------
> nosy: +r.david.murray
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12750>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Mon Aug 15 17:36:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Aug 2011 15:36:17 +0000
Subject: [issue12750] datetime.datetime timezone problems
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313422577.83.0.152353179224.issue12750@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah.  Well, pre-3.2 datetime itself did not generate *any* non-naive datetimes.

Nor do you need to specify everything for replace.  dt.replace(tzinfo=tz) should work just fine.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:15:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 17:15:31 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1313428531.37.0.895024758346.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here are some benchmarks:
Commands:
# half of the bytes are invalid
./python -m timeit -s 'b = bytes(range(256)); b_dec = b.decode' 'b_dec("utf-8", "surrogateescape")'
./python -m timeit -s 'b = bytes(range(256)); b_dec = b.decode' 'b_dec("utf-8", "replace")'
./python -m timeit -s 'b = bytes(range(256)); b_dec = b.decode' 'b_dec("utf-8", "ignore")'

With patch:
1000 loops, best of 3: 854 usec per loop
1000 loops, best of 3: 509 usec per loop
1000 loops, best of 3: 415 usec per loop

Without patch:
1000 loops, best of 3: 670 usec per loop
1000 loops, best of 3: 470 usec per loop
1000 loops, best of 3: 382 usec per loop

Commands (from the interactive interpreter):
# all valid codepoints
import timeit
b = "".join(chr(c) for c in range(0x110000) if c not in range(0xD800, 0xE000)).encode("utf-8")
b_dec = b.decode
timeit.Timer('b_dec("utf-8")', 'from __main__ import b_dec').timeit(100)/100
timeit.Timer('b_dec("utf-8", "surrogateescape")', 'from __main__ import b_dec').timeit(100)/100
timeit.Timer('b_dec("utf-8", "replace")', 'from __main__ import b_dec').timeit(100)/100
timeit.Timer('b_dec("utf-8", "ignore")', 'from __main__ import b_dec').timeit(100)/100

With patch:
0.03830226898193359
0.03849360942840576
0.03835036039352417
0.03821949005126953

Without patch:
0.03750091791152954
0.037977190017700196
0.04067679166793823
0.038579678535461424

Commands:
# near-worst case scenario, 1 byte dropped every 5 from a valid utf-8 string
b2 = bytes(c for k,c in enumerate(b) if k%5)
b2_dec = b2.decode
timeit.Timer('b2_dec("utf-8", "surrogateescape")', 'from __main__ import b2_dec').timeit(10)/10
timeit.Timer('b2_dec("utf-8", "replace")', 'from __main__ import b2_dec').timeit(10)/10
timeit.Timer('b2_dec("utf-8", "ignore")', 'from __main__ import b2_dec').timeit(10)/10

With patch:
9.645482301712036
6.602735090255737
5.338080596923828

Without patch:
8.124328684806823
5.804249691963196
4.851014900207519

All tests done on wide 3.2.

Since the changes are about errors, decoding of valid utf-8 strings is not affected.  Decoding with non-strict error handlers and invalid strings are slower, but I don't think the difference is significant.
If the patch is fine I will commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:26:20 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Aug 2011 17:26:20 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313429180.23.0.763014445011.issue10542@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A PEP 393 draft implementation is available at https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into 3.3, this issue will be outdated: there won't be "narrow" builds of Python anymore (nor will there be "wide" builds).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:33:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 17:33:10 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313429590.61.0.419198540847.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That's a really good news.
Some Unicode issues can still be fixed on 2.7 and 3.2 though.
FWIW I was planning to look at this and #9200 in the following days and see if I can fix them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:47:02 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 17:47:02 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313430422.45.0.891773423138.issue12730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My Firefox is already set at utf-8. More likely a font limitation. I will look again after installing one of the fonts Tom suggested.

The pair of boxes on IDLE are for the surrogate pairs. Perhaps tk does not even try to display a single char. I will experiment more when I have a more complete font.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:48:34 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 17:48:34 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
Message-ID: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>


New submission from Tom Christiansen <tchrist at perl.com>:

Unicode character names share a common namespace with formal aliases and with named sequences, but Python recognizes only the original name. That means not everything in the namespace is accessible from Python.  (If this is construed to be an extant bug from than an absent feature, you probably want to change this from a wish to a bug in the ticket.)

This is a problem because aliases correct errors in the original names, and are the preferred versions.  For example, ISO screwed up when they called U+01A2 LATIN CAPITAL LETTER OI.  It is actually LATIN CAPITAL LETTER GHA according to the file NameAliases.txt in the Unicode Character Database.  However, Python blows up when you try to use this:

    % env PYTHONIOENCODING=utf8 python3.2-narrow -c 'print("\N{LATIN CAPITAL LETTER OI}")'
    ?

    % env PYTHONIOENCODING=utf8 python3.2-narrow -c 'print("\N{LATIN CAPITAL LETTER GHA}")'
      File "<string>", line 1
    SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-27: unknown Unicode character name
    Exit 1

This unfortunate, because the formal aliases correct egregious blunders, such as the Standard reading "BRAKCET" instead of "BRACKET":

$ uninames '^\s+%'
 ?  01A2        LATIN CAPITAL LETTER OI
        % LATIN CAPITAL LETTER GHA
 ?  01A3        LATIN SMALL LETTER OI
        % LATIN SMALL LETTER GHA
        * Pan-Turkic Latin alphabets
 ?  0CDE        KANNADA LETTER FA
        % KANNADA LETTER LLLA
        * obsolete historic letter
        * name is a mistake for LLLA
 ?  0E9D        LAO LETTER FO TAM
        % LAO LETTER FO FON
        = fo fa
        * name is a mistake for fo sung
 ?  0E9F        LAO LETTER FO SUNG
        % LAO LETTER FO FAY
        * name is a mistake for fo tam
 ?  0EA3        LAO LETTER LO LING
        % LAO LETTER RO
        = ro rot
        * name is a mistake, lo ling is the mnemonic for 0EA5
 ?  0EA5        LAO LETTER LO LOOT
        % LAO LETTER LO
        = lo ling
        * name is a mistake, lo loot is the mnemonic for 0EA3
 ?  0FD0        TIBETAN MARK BSKA- SHOG GI MGO RGYAN
        % TIBETAN MARK BKA- SHOG GI MGO RGYAN
        * used in Bhutan
 ? A015        YI SYLLABLE WU
        % YI SYLLABLE ITERATION MARK
        * name is a misnomer
 ? FE18        PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRAKCET
        % PRESENTATION FORM FOR VERTICAL RIGHT WHITE LENTICULAR BRACKET
        * misspelling of "BRACKET" in character name is a known defect
        # <vertical> 3017
 ?  1D0C5       BYZANTINE MUSICAL SYMBOL FHTORA SKLIRON CHROMA VASIS
        % BYZANTINE MUSICAL SYMBOL FTHORA SKLIRON CHROMA VASIS
        * misspelling of "FTHORA" in character name is a known defect

There are only 

In Perl, \N{...} grants access to the single, shared, common namespace of Unicode character names, formal aliases, and named sequences without distinction:

    % env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER OI}")'
    ?
    % env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER GHA}")'
    ?

    % env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER OI}")'  | uniquote -x
    \x{1A2}
    % env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER GHA}")' | uniquote -x
    \x{1A2}

It is my suggestion that Python do the same thing. There are currently only 11 of these.  

The third element in this shared namespace of name, named sequences, are multiple code points masquerading under one name.  They come from the NamedSequences.txt file in the Unicode Character Database.  An example entry is:

    LATIN CAPITAL LETTER A WITH MACRON AND GRAVE;0100 0300

There are 418 of these named sequences as of Unicode 6.0.0.  This shows that Perl can also access named sequences:

  $ env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}")'
  ??

  $ env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}")' | uniquote -x
  \x{100}\x{300}

  $ env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{KATAKANA LETTER AINU P}")'            
  ??

  $ env PERL_UNICODE=S perl -Mcharnames=:full -le 'print("\N{KATAKANA LETTER AINU P}")' | uniquote -x
   \x{31F7}\x{309A}


Since it is a single namespace, it makes sense that all members of that namespace should be accessible using \N{...} as a sort of equal-opportunity accessor mechanism, and it does not make sense that they not be.

Just makes sure you take only the approved named sequences from the NamedSequences.txt file. It would be unwise to give users access to the provisional sequences located in a neighboring file I shall not name :) because those are not guaranteed never to be withdrawn the way the others are, and so you would risk introducing an incompatibility.

If you look at the ICU UCharacter class, you can see that they provide a more

----------
components: Interpreter Core
messages: 142136
nosy: mrabarnett, tchrist
priority: normal
severity: normal
status: open
title: \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:51:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 17:51:42 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313430702.82.0.497446707325.issue12730@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> My Firefox is already set at utf-8.

Every page can specify the encoding it uses (in HTTP headers, <meta> tag and/or xml prologue).  If none of these are specified, afaik Firefox tries to detect the encoding, and sometimes fails.  What encoding does it show for you in the menu when you open the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:55:08 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 17:55:08 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313430422.45.0.891773423138.issue12730@psf.upfronthosting.co.za>
Message-ID: <20915.1313430898@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Terry J. Reedy <tjreedy at udel.edu> added the comment:

> My Firefox is already set at utf-8. More likely a font limitation. I
> will look again after installing one of the fonts Tom suggested.

Symbola is best for exotic glyphs, especially astral ones.

Alfios just looks nice as a normal default roman.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 19:55:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 17:55:23 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1313430923.45.0.971568633343.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
stage:  -> test needed
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Aug 15 20:02:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 18:02:07 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313431327.76.0.937601511804.issue12730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You are right, FF switched on me without notice. Bad FF.
Thank you! What I now see makes much more sense.
[ "???????", "???????", "???????", "???????"  ],
and I now know to check on other pages (although Tom's Unicode talk slides still have boxes even in utf-8, so that must be a font lack).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 20:40:56 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 18:40:56 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313431327.76.0.937601511804.issue12730@psf.upfronthosting.co.za>
Message-ID: <12730.1313433631@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Terry J. Reedy <tjreedy at udel.edu> added the comment:

> You are right, FF switched on me without notice. Bad FF. Thank you! What
> I now see makes much more sense.

>    [ "???????", "???????", "???????", "???????"  ],

> and I now know to check on other pages (although Tom's Unicode talk
> slides still have boxes even in utf-8, so that must be a font lack).

Do you have Symbola installed?  Here's Appendix I on Fonts for things that
should look right for the presentation to look right.  

    * I recommend two free fonts from George Douros at users.teilar.gr/~g1951d/ known to
      work with this presentation: his Al?os font for regular text, and his Symbola font
      for fancy emoji. If any of these don?t look right to you, you probably need to
      supplement your system fonts:

            Ligatures: ? ? ? ? ? ? ? ? ?
            Math letters: ? ? ? ? ? ?
            Gothic & Deseret: ????, ???????
            Symbols: ? ? ? ? ? ?
            Emoticons: ? ? ? ? ? ?
            Upside?down: ?p??? ?no? uo ?u?pu??s ?q s??? p???
            Combining characters: ??,??,??,??,??,??,??

    * The last line with combining characters is especially hard to get to look right. 
      You may ?nd that the shareware font Everson Mono works when all else fails.

You do need Unicode 5.1 support for the LATIN CAPITAL LETTER SHARP S, and
you need Unicode 6.0 support for most of the emoji (I think Snow Leopard
has colorized versions of these.  The Ligature line above looks good in Alfios.

It  turns out it may not always the font used with combining chars as it is whether and
well your browser supports true combining characters dynamically generated, or whether it
runs stuff through NFC and looks for substitution glyphs.  I am not a GUI person, so am
mostly just guessing.

But this I find interesting:  If you look at slide 33 of my first talk or slide 5 of my
second talk, which are duplicates entitled Canonical Conundra, the second column which is
labelled Glyphs explicitly uses Time New Roman because of this issue.  Even so you can
tell it is doing the NFC trick, because lines 1+2 have the same NFC of \x{F5} or ?, as do
3+4+5 with \x{22D} with ?, and and 6+7 with ??.

The glyphs from the first group are both identical, and so are all three those of the
second group, as both the first two groups have a single precomposed character available
for their NFC.  In contrast, there is no single precomposed glyph available for 6+7, and
you can tell that it's stacking it on the fly using slightly less tight grouping rules
than the font has in the precomposed versions above it.

I use Safari, but I am told Firefox looks ok, too.  Opera is my normal browser but it
does the copout I just described on combining chars without ever being able to
dynamically stack them if the copout fail, so I can't use it for this presentation.

--tom

  $ uniprops -a 'LATIN CAPITAL LETTER SHARP S' 'DESERET CAPITAL LETTER DEE' 'GOTHIC LETTER MANNA' 'SNAKE' 'FACE SCREAMING IN FEAR'

    U+1E9E <?> \N{LATIN CAPITAL LETTER SHARP S}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
        All Any Alnum Alpha Alphabetic Assigned InLatinExtendedAdditional Cased Cased_Letter LC Changes_When_Casefolded CWCF
           Changes_When_Casemapped CWCM Changes_When_Lowercased CWL Changes_When_NFKC_Casefolded CWKCF Lu L Gr_Base Grapheme_Base
           Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Latin_Extended_Additional Uppercase_Letter Print Upper
           Uppercase Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper
           X_POSIX_Word
        Age=5.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Latin_Extended_Additional Canonical_Combining_Class=0
           Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Decomposition_Type=None DT=None
           East_Asian_Width=Neutral Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX Hangul_Syllable_Type=NA
           Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup Joining_Type=Non_Joining
           JT=U Joining_Type=U Script=Latin Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None Numeric_Value=NaN
           NV=NaN Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 SC=Latn Script=Latn Sentence_Break=UP
           Sentence_Break=Upper SB=UP Word_Break=ALetter WB=LE Word_Break=LE _X_Begin

    U+10414 <?> \N{DESERET CAPITAL LETTER DEE}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
        All Any Alnum Alpha Alphabetic Assigned InDeseret Cased Cased_Letter LC Changes_When_Casefolded CWCF
           Changes_When_Casemapped CWCM Changes_When_Lowercased CWL Changes_When_NFKC_Casefolded CWKCF Deseret Dsrt Lu L Gr_Base
           Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Uppercase_Letter Print Upper Uppercase Word
           XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word
        Age=3.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Deseret Canonical_Combining_Class=0
           Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Decomposition_Type=None DT=None
           Script=Deseret East_Asian_Width=Neutral Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
           Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
           Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None
           Numeric_Value=NaN NV=NaN Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1
           Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 SC=Dsrt Script=Dsrt
           Sentence_Break=UP Sentence_Break=Upper SB=UP Word_Break=ALetter WB=LE Word_Break=LE _X_Begin

    U+1033C <?> \N{GOTHIC LETTER MANNA}
        \w \pL \p{L_} \p{Lo}
        All Any Alnum Alpha Alphabetic Assigned InGothic Gothic Is_Gothic L Lo Goth Gr_Base Grapheme_Base Graph GrBase
           ID_Continue IDC ID_Start IDS Letter L_ Other_Letter Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum
           X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Word
        Age=3.1 Bidi_Class=L Bidi_Class=Left_To_Right BC=L Block=Gothic Canonical_Combining_Class=0
           Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Decomposition_Type=None DT=None
           East_Asian_Width=Neutral Script=Gothic Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
           Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
           Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None
           Numeric_Value=NaN NV=NaN Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1
           Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 Script=Goth SC=Goth
           Sentence_Break=LE Sentence_Break=OLetter SB=LE Word_Break=ALetter WB=LE Word_Break=LE _X_Begin

    U+1F40D <?> \N{SNAKE}
        \pS \p{So}
        All Any Assigned InMiscellaneousSymbolsAnd_Pictographs Common Zyyy So S Gr_Base Grapheme_Base Graph GrBase
           Miscellaneous_Symbols_And_Pictographs Other_Symbol Print Symbol X_POSIX_Graph X_POSIX_Print
        Age=6.0 Bidi_Class=ON Bidi_Class=Other_Neutral BC=ON Block=Miscellaneous_Symbols_And_Pictographs
           Canonical_Combining_Class=0 Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Script=Common
           Decomposition_Type=None DT=None East_Asian_Width=Neutral Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX
           Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup
           Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None
           Numeric_Value=NaN NV=NaN Present_In=6.0 IN=6.0 SC=Zyyy Script=Zyyy Sentence_Break=Other SB=XX Sentence_Break=XX
           Word_Break=Other WB=XX Word_Break=XX _X_Begin

    U+1F631 <?> \N{FACE SCREAMING IN FEAR}
        \pS \p{So}
        All Any Assigned InEmoticons Common Zyyy Emoticons So S Gr_Base Grapheme_Base Graph GrBase Other_Symbol Print Symbol
           X_POSIX_Graph X_POSIX_Print
        Age=6.0 Bidi_Class=ON Bidi_Class=Other_Neutral BC=ON Block=Emoticons Canonical_Combining_Class=0
           Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Script=Common Decomposition_Type=None
           DT=None East_Asian_Width=Neutral Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX Hangul_Syllable_Type=NA
           Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup Joining_Type=Non_Joining
           JT=U Joining_Type=U Line_Break=AL Line_Break=Alphabetic LB=AL Numeric_Type=None NT=None Numeric_Value=NaN NV=NaN
           Present_In=6.0 IN=6.0 SC=Zyyy Script=Zyyy Sentence_Break=Other SB=XX Sentence_Break=XX Word_Break=Other WB=XX
           Word_Break=XX _X_Begin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:05:17 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 19:05:17 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313435117.45.0.435256915564.issue12734@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Sorry I didn't include a test case. Hope this makes up for it.  If not, please tell me how to write better test cases. :(

Yeah ok, so I'm a bit persnickety or even unorthodox about my vertical alignment, but it really helps to make what is different from one to line to the next stand out if the parts that are the same from line to line are at the same column every time.

----------
Added file: http://bugs.python.org/file22902/nametests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12734>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:06:21 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 19:06:21 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313435181.45.0.315083753769.issue12734@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Oh whoops, that was the long ticket.  Shall I reupload to the right number?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12734>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:16:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 19:16:51 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313435811.74.0.360140166373.issue12730@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Adding Symbola filled in the symbols and emoticons lines.
The gothic chars are still missing even with Alfios.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:20:59 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 19:20:59 +0000
Subject: [issue12730] Python's casemapping functions are untrustworthy due to
	narrow/wide build issues
In-Reply-To: <1313435811.74.0.360140166373.issue12730@psf.upfronthosting.co.za>
Message-ID: <9142.1313436047@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Terry J. Reedy <tjreedy at udel.edu> added the comment:

>Adding Symbola filled in the symbols and emoticons lines.
>The gothic chars are still missing even with Alfios.

That's too bad, as the Gothic paternoster is kinda cute. :)

Hm, I wonder where I got them from.  I think there must 
be a way to figure that out using the Mac FontBook program,
but I don't know what it is other than pasting them in
the sample screen and scrolling through the fonts to see
how those get rendered.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:28:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 15 Aug 2011 19:28:23 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1313436503.25.0.473457964578.issue12746@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/issue12746>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:35:01 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 15 Aug 2011 19:35:01 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313436901.64.0.396352529747.issue9200@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/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:51:39 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 19:51:39 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1313437899.81.0.770907883865.issue12753@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Here?s the right test file for the right ticket.

----------
Added file: http://bugs.python.org/file22903/nametests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Mon Aug 15 21:51:59 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 19:51:59 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1313437919.85.0.822546814996.issue12734@psf.upfronthosting.co.za>


Changes by Tom Christiansen <tchrist at perl.com>:


Removed file: http://bugs.python.org/file22902/nametests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12734>
_______________________________________

From report at bugs.python.org  Mon Aug 15 22:39:19 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Aug 2011 20:39:19 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313440759.4.0.609762986834.issue12752@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

A cheap way of fixing this would be to test for str-ness of localename and if it's a unicode, just localname.encode('ascii')

Or is that completely insane?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 22:47:48 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Aug 2011 20:47:48 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313441268.59.0.550674484357.issue12752@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

For example:


diff -r fb49394f75ed Lib/locale.py
--- a/Lib/locale.py	Mon Aug 15 14:24:15 2011 +0300
+++ b/Lib/locale.py	Mon Aug 15 16:47:23 2011 -0400
@@ -355,6 +355,8 @@
 
     """
     # Normalize the locale name and extract the encoding
+    if isinstance(localename, unicode):
+        localename = localename.encode('ascii')
     fullname = localename.translate(_ascii_lower_map)
     if ':' in fullname:
         # ':' is sometimes used as encoding delimiter.
diff -r fb49394f75ed Lib/test/test_locale.py
--- a/Lib/test/test_locale.py	Mon Aug 15 14:24:15 2011 +0300
+++ b/Lib/test/test_locale.py	Mon Aug 15 16:47:23 2011 -0400
@@ -412,6 +412,11 @@
         locale.setlocale(locale.LC_CTYPE, loc)
         self.assertEqual(loc, locale.getlocale())
 
+    def test_normalize_issue12752(self):
+        # Issue #1813 caused a regression where locale.normalize() would no
+        # longer accept unicode strings.
+        self.assertEqual(locale.normalize(u'en_US'), 'en_US.ISO8859-1')
+
 
 def test_main():
     tests = [

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 22:48:24 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Aug 2011 20:48:24 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313441304.11.0.151459461405.issue12752@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22904/issue12752.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Mon Aug 15 23:39:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 21:39:51 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313444391.63.0.520968964189.issue12751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Mon Aug 15 23:45:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 21:45:00 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313444700.2.0.967105171695.issue12751@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This has been proposed already in #10542 (the issue also has patches).

The two issues are different: this issue is only a refactoring, whereas #10542 adds a new "feature" (function/macro: Py_UNICODE_NEXT).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Tue Aug 16 00:40:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Aug 2011 22:40:25 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313448025.61.0.165949800295.issue12752@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The proposed resolution looks ok. Another possibility is simply to use .lower() if the string is an unicode string, since that will bypass the C locale.

----------
nosy: +pitrou
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Tue Aug 16 00:57:04 2011
From: report at bugs.python.org (Daniel O'Connor)
Date: Mon, 15 Aug 2011 22:57:04 +0000
Subject: [issue12750] datetime.datetime timezone problems
In-Reply-To: <1313422577.83.0.152353179224.issue12750@psf.upfronthosting.co.za>
Message-ID: <2D86C48E-8621-49C1-BBE9-82B6009CA31E@dons.net.au>


Daniel O'Connor <darius at dons.net.au> added the comment:

On 16/08/2011, at 1:06, R. David Murray wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> Ah.  Well, pre-3.2 datetime itself did not generate *any* non-naive datetimes.
> 
> Nor do you need to specify everything for replace.  dt.replace(tzinfo=tz) should work just fine.

OK.

I did try this and it seems broken though..
In [19]: now = datetime.datetime.utcnow()

In [21]: now.replace(tzinfo = pytz.utc)
Out[21]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110, tzinfo=<UTC>)

In [22]: datetime.datetime.strftime(now, "%s")
Out[22]: '1313414653'

In [23]: now
Out[23]: datetime.datetime(2011, 8, 15, 22, 54, 13, 173110)

[ur 8:22] ~ >date -ujr 1313414653
Mon 15 Aug 2011 13:24:13 UTC

i.e. it appears that replace() applies the TZ offset to a naive datetime object effectively assuming it is local time rather than un-timezoned (which is what the docs imply to me)

> ----------
> resolution:  -> invalid
> stage:  -> committed/rejected
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12750>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Tue Aug 16 01:01:47 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Aug 2011 23:01:47 +0000
Subject: [issue12754] Add alternative random number generators
Message-ID: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

While keeping the MT generator as the default, add new alternative random number generators as drop-in replacements.  Since MT was first introduced, PRNG technology has continued to advance.

I'm opening this feature request to be a centralized place to discuss which alternatives should be offered.

Since we already have a mostly-good-enough(tm) prng, any new generators need to be of top quality, be well researched, and offer significantly different performance characteristics than we have now (i.e. speed, cryptographic strength, simplicity, smaller state vectors, etc).

At least one of the new generators should be cryptographically strong (both to the left and to the right) while keeping reasonable speed for simulation, sampling, and gaming apps.  (The speed requirement precludes the likes of Blum Blum Shub for example.)  I believe there are several good candidates based on stream ciphers or that use block ciphers in a feedback mode.

----------
assignee: rhettinger
components: Library (Lib)
messages: 142151
nosy: rhettinger
priority: low
severity: normal
status: open
title: Add alternative random number generators
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 01:17:33 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Aug 2011 23:17:33 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313450253.73.0.710812587949.issue12752@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Tue Aug 16 01:51:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 23:51:02 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <E1Qt6vs-000067-Rx@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0d64fe6c737f by Barry Warsaw in branch '2.7':
The simplest possible fix for the regression in bug 12752 by encoding unicodes
http://hg.python.org/cpython/rev/0d64fe6c737f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Tue Aug 16 01:51:53 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Aug 2011 23:51:53 +0000
Subject: [issue12752] locale.normalize does not take unicode strings
In-Reply-To: <1313406762.16.0.00679239298306.issue12752@psf.upfronthosting.co.za>
Message-ID: <1313452313.82.0.699418641333.issue12752@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12752>
_______________________________________

From report at bugs.python.org  Tue Aug 16 02:00:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Aug 2011 00:00:57 +0000
Subject: =?utf-8?q?=5Bissue12748=5D_Problems_using_IDLE_accelerators_with_OS_X_Dvo?=
	=?utf-8?q?rak_-_Qwerty_=E2=8C=98_input_method?=
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313452857.71.0.528585678629.issue12748@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Interesting, I didn't know the "Dvorak - Qwerty ?" input method existed.  In just some causal experimentation with it, it seems pretty clear that the input method is not being consistently followed by Tk and there seem to be differences between Tk 8.4 and 8.5.  Part of the problem, I think, is that some of the keyboard accelerators are implemented in menus provided by Tk itself and the unrecognized ones are passed on to IDLE.  Unfortunately, Tk does not fully implement Input Method text processing although there does seem to be some work-in-progress in the Tk community to help fix that, see for instance:

http://sourceforge.net/tracker/?func=detail&aid=3205153&group_id=12997&atid=112997

But the work for that issue, if it does get released, may still have no impact on this problem.

If someone is interested in further investigating the issue, I would suggest setting up a small Tcl test case using menu accelerators using Tcl/Tk Wish and, if the problem can be demonstrated there, opening an issue on the Tk tracker.  I'm reasonably certain there is nothing to be done about this in Python itself but I'm not interested in spending more time to prove that.  So I'm going to close this issue as "wont fix".  If anyone has an interest in it, feel free to reopen and reassign.

----------
assignee: ned.deily -> 
priority: normal -> low
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
title: IDLE halts on osx when copy and paste -> Problems using IDLE accelerators with OS X Dvorak - Qwerty ? input method
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Tue Aug 16 02:22:05 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 00:22:05 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313454125.14.0.832348714138.issue12754@psf.upfronthosting.co.za>


Sturla Molden <sturla at molden.no> added the comment:

George Marsaglia's latest random number generator KISS4691 is worth considering, though I am not sure the performance is that different from MT19937. 

Here is a link to Marsaglia's post on comp.lang.c. Marasglia passed away shortly after (Feb. 2011), and to my knowledge a paper on KISS4691 was never published:

http://www.rhinocerus.net/forum/lang-c/620168-kiss4691-potentially-top-ranked-rng.html

On my laptop, KISS4691 could produce about 110 million random numbers per second (148 millon if inlined), whereas MT19937 produced 118 million random numbers per second. Another user on comp.lang.c reported that (with my benchmark) KISS4691 was about twice as fast as MT19937 on his computer. As for quality, I have been told that MT19937 only failes a couple of obscure tests for randomness, whereas KISS4691 failes no single-seed test.

The source code I used for this test is available here:

http://folk.uio.no/sturlamo/prngtest.zip

(Requires Windows because that's what I use, sorry, might work with winelib on Linux though.)

Marsaglia has previously recommended several PRNGs that are considerably simpler and faster than MT19937. These are the ones used in the 3rd edition of "Numerical Receipes" (yes I know that not a sign of good quality). We can look at them too, with Marsaglia's comments:

https://groups.google.com/group/sci.stat.math/msg/edcb117233979602?hl=en&pli=1

https://groups.google.com/group/sci.math.num-analysis/msg/eb4ddde782b17051?hl=en&pli=1

There are also SIMD-oriented versions of MT19937, though for licensing and portability reasons they might not be suitable for Python's standard library.

High-performance PRNGs are also present in the Intel MKL and AMD ACML libraries. These could be used if Python was linked against these libraries at build-time.

Regards,
Sturla Molden

----------
nosy: +sturlamolden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 02:47:45 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 00:47:45 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313455665.21.0.862881881766.issue12754@psf.upfronthosting.co.za>


Sturla Molden <sturla at molden.no> added the comment:

I'm posting the code for comparison of KISS4691 and MT19937. I do realize KISS4691 might not be sufficiently different from MT19937 in characteristics for Raymond Hettinger to consider it. But at least here it is for reference should it be of value.

----------
Added file: http://bugs.python.org/file22905/prngtest.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 02:58:27 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 00:58:27 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313456307.65.0.357736657538.issue12754@psf.upfronthosting.co.za>


Sturla Molden <sturla at molden.no> added the comment:

Another (bug fix) post by Marsaglia on KISS4691:

http://www.phwinfo.com/forum/comp-lang-c/460292-ensuring-long-period-kiss4691-rng.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 03:06:10 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 01:06:10 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313456770.54.0.772496337254.issue12754@psf.upfronthosting.co.za>


Changes by Sturla Molden <sturla at molden.no>:


Removed file: http://bugs.python.org/file22905/prngtest.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 03:08:53 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 01:08:53 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313456933.72.0.671435035408.issue12754@psf.upfronthosting.co.za>


Changes by Sturla Molden <sturla at molden.no>:


Added file: http://bugs.python.org/file22906/prngtest.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 04:44:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 16 Aug 2011 02:44:05 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313345036.11.0.789905045333.issue12740@psf.upfronthosting.co.za>
Message-ID: <CAK1Qoor-_tNv-f1QLyi4C-Ew6U64QQKZfvKuyGT3d90wPrfueg@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Sun, Aug 14, 2011 at 1:03 PM, Stefan Krah <report at bugs.python.org> wrote:
>
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
>
> I like random tests in the stdlib, otherwise the same thing gets tested
> over and over again. `make buildbottest` prints the seed, and you can do
> it for a single test as well:
>
> ?$ ./python -m test -r test_heapq
> Using random seed 5857004
> [1/1] test_heapq
> 1 test OK.

Ah, I see.  Then you can reproduce a run like:

$ ./python -m test -r --randseed=5857004 test_heapq

Perhaps it might be useful to include the failing output in the
assertion message as well
(just in case the seed printing option is not used):

======================================================================
FAIL: test_Struct_nmemb (__main__.StructTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_struct.py", line 596, in test_Struct_nmemb
    self.assertEqual(s.nmemb, n, "for struct.Struct(%s)" % fmt)
AssertionError: 3658572 != 3658573 : for
struct.Struct(378576l?403320c266165pb992937H198961PiIL529090sfh887898d796871B)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Tue Aug 16 04:45:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 16 Aug 2011 02:45:06 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313462706.63.0.108833753683.issue12672@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, I'm not 100% sure about what you mean by "Python wrapper objects ... visible from Python", but I think I'll disagree.

There's a big difference between "C functions" in general and "type methods" this document speaks of. Let's leave list aside for a moment, since its being built-in complicates matters a bit, and let's talk about the "Noddy" type this documentation page plays with.

You may implement "normal" methods for Noddy, such as the "name" method added in the first example, by defining an array of PyMethodDef structures and assigning it to tp_methods.

On the other hand, the other tp_ fields imlpement special type methods (used by __new__, __str__, getattr/setattr, and so on). This is the major difference. Both are C functions, but some implement special type methods and some implement "normal" object methods.

If this is also what you meant, I apologize for disagreeing :-)

I believe my latest rephrasing proposal is reflecting the above understanding.

P.S. as for s/that/than/ further down - good catch, will add it to the patch when we decide about the first issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Tue Aug 16 05:21:47 2011
From: report at bugs.python.org (Sturla Molden)
Date: Tue, 16 Aug 2011 03:21:47 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313464907.29.0.811138091536.issue12754@psf.upfronthosting.co.za>


Sturla Molden <sturla at molden.no> added the comment:

Further suggestions to improve the random module:

** Object-oriented PRNG: Let it be an object which stores the random state internally, so we can create independent PRNG objects. I.e. not just one global generator.

** Generator for quasi-random Sobol sequences.  These fail most statistical tests for randomness. But for many practical uses of random numbers, e.g. simulations and numerical integration, convergence can be orders of magnitude faster (often 1000x faster convergence) but still numerically correct. That is, they are not designed to "look random", but fill the sample space as uniformly as possible.

** For cryptographically strong random numbers, os.urandom is a good back-end. It will use /dev/urandom on Linux and CryptGenRandom on Windows.  We still e.g. need a method to convert random bits from os.urandom to floats with given distributions. os.urandom is already in the standard library, so there is no reason the random module should not use it.

** Ziggurat method for generating normal, exponential and gamma deviates. This avoids most call to trancendental functions (sin, cos, log) in transforming from uniform random deviates, and is thus much faster.

** Option to return a buffer (bytearray?) with random numbers. Some times we don't need Python ints or floats, but rather the raw bytes.

** Support for more statistical distributions. Provide a much broader coverage than today. 

** Markov Chain Monte Carlo (MCMC) generator. Provide simple plug-in factories for the Gibbs sampler and the Metropolis-Hastings alorithm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 05:57:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 16 Aug 2011 03:57:36 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313467056.28.0.0615003069089.issue12754@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please focus your thoughts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 16 06:44:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Aug 2011 04:44:19 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313469859.3.0.657392022271.issue12672@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"the type object determines which (C) functions get called when, for instance, an attribute gets looked up on an object or it is multiplied by another object. These C functions are called ?type methods?

"These C functions" are any of the C functions that are members of the type object. But they are C-level methods.

"to distinguish them from things like [].append (which we call ?object methods?)."

[].append is a Python-level method object that wraps a C function.

My revised suggestion is "... in contrast to PyObject that contain C functions, such as list.append or [].append."

The only contrast that makes sense to me in this context is between directly callable C functions and Py_Objects (which have just been described) that contain a C function. I believe that author is addressing Python programmers who are used to 'method' referring to Python objects whereas the author wants to use 'method' to refer to C functions, which are not Python objects.

Or the sentence could be deleted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Tue Aug 16 07:46:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 16 Aug 2011 05:46:07 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313473567.46.0.436005479756.issue12672@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

"[].append is a Python-level method object that wraps a C function."

What makes you think that? There's no Python implementation of .append that I know of. Neither is there a Python implementation of the Noddy.name method that is discussed in the page. Both are implemented solely in C and exposed as methods for their respective classes via the tp_methods array.

"Or the sentence could be deleted."

This could be problematic, because the document does refer to "type methods" on several occasions, and it makes sense to define what it means.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Tue Aug 16 08:26:44 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Tue, 16 Aug 2011 06:26:44 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
Message-ID: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>


New submission from Chandra Sekhar Reddy <sanch09 at ca.com>:

Service application crashed in python25.dll, below are the environment details.

Operating System : Windows server 2008 R2 (Virtual Machine)
Application Type : Service Application

FAULTING_IP: 
python25!PyObject_Malloc+2d
1e09603d 8b30            mov     esi,dword ptr [eax]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 1e09603d (python25!PyObject_Malloc+0x0000002d)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

PROCESS_NAME:  adem.exe

ADDITIONAL_DEBUG_TEXT:  
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

FAULTING_MODULE: 76f80000 ntdll

DEBUG_FLR_IMAGE_TIMESTAMP:  4625bfe5

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 

FOLLOWUP_IP: 
python25!PyObject_Malloc+2d
1e09603d 8b30            mov     esi,dword ptr [eax]

FAULTING_THREAD:  00002474

BUGCHECK_STR:  APPLICATION_FAULT_INVALID_POINTER_WRITE_NULL_POINTER_WRITE_NULL_POINTER_READ_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_WRITE_NULL_POINTER_WRITE

DEFAULT_BUCKET_ID:  INVALID_POINTER_WRITE_NULL_POINTER_WRITE

LAST_CONTROL_TRANSFER:  from 1e0c1093 to 1e09603d

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0505f088 1e0c1093 00000025 04a128ea 04a128d0 python25!PyObject_Malloc+0x2d
00000000 00000000 00000000 00000000 00000000 python25!PyString_FromStringAndSize+0x43


STACK_COMMAND:  ~4s; .ecxr ; kb

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  python25!PyObject_Malloc+2d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: python25

IMAGE_NAME:  python25.dll

BUCKET_ID:  WRONG_SYMBOLS

FAILURE_BUCKET_ID:  INVALID_POINTER_WRITE_NULL_POINTER_WRITE_c0000005_python25.dll!PyObject_Malloc

----------
components: Windows
messages: 142163
nosy: chandra
priority: normal
severity: normal
status: open
title: Service application crash in python25!PyObject_Malloc
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Tue Aug 16 08:39:46 2011
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Aug 2011 06:39:46 +0000
Subject: [issue12750] datetime.datetime timezone problems
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313476786.17.0.844413008006.issue12750@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/issue12750>
_______________________________________

From report at bugs.python.org  Tue Aug 16 08:52:55 2011
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Aug 2011 06:52:55 +0000
Subject: [issue12756] datetime.datetime.utcnow should return a UTC timestamp
Message-ID: <1313477575.0.0.856648078618.issue12756@psf.upfronthosting.co.za>


New submission from Ben Finney <ben+python at benfinney.id.au>:

=====
$ date -u +'%F %T %s %z'
2011-08-16 06:42:12 1313476932 +0000

$ python -c 'import sys, datetime; now = datetime.datetime.utcnow(); sys.stdout.write(now.strftime("%F %T %s %z"))'
2011-08-16 06:42:12 1313440932 
=====

The documentation for ?datetime.datetime.utcnow? says ?Return a new datetime representing UTC day and time.? The resulting object should be in the UTC timezone, not a naive no-timezone value.

This results in programs specifically requesting UTC time with ?utcnow?, but then Python treating the return value as representing local time since it is not marked with the UTC timezone.

----------
components: Library (Lib)
messages: 142164
nosy: Daniel.O'Connor, bignose, r.david.murray
priority: normal
severity: normal
status: open
title: datetime.datetime.utcnow should return a UTC timestamp
type: feature request
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12756>
_______________________________________

From report at bugs.python.org  Tue Aug 16 09:18:06 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 16 Aug 2011 07:18:06 +0000
Subject: [issue12757] undefined name in doctest.py
Message-ID: <1313479086.68.0.065111934389.issue12757@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

doctest.py, line 2274 (in 2.7):

    def shortDescription(self):
        return "Skipping tests from %s" % module.__name__

"module" is not defined here. Assigning to David since he last changed this line. Test script attached.

----------
assignee: r.david.murray
components: Library (Lib)
files: t.py
messages: 142165
nosy: georg.brandl, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: undefined name in doctest.py
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22907/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12757>
_______________________________________

From report at bugs.python.org  Tue Aug 16 09:37:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Aug 2011 07:37:17 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313480237.08.0.934695979453.issue12755@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you please give more context? From the information you gave:
- Python is embedded in some program "adem.exe".
- Memory seems corrupted, and a C call to PyString_FromStringAndSize() segfaults in PyObject_Malloc().

Most of the time, it will be an issue in the application, and not a python bug.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Tue Aug 16 09:52:04 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 07:52:04 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
Message-ID: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>


New submission from Maxim Koltsov <kolmax94 at gmail.com>:

Python docs (http://docs.python.org/library/time.html#time.time) say that time.time() function should return UTC timestamp, but actually i get local one:
>>> time.mktime(time.gmtime()), time.time(), time.mktime(time.localtime())
(1313466499.0, 1313480899.384221, 1313480899.0)
As you can see, the result of second statement is equal to result of the third, while it must be equal to result of the first. Checked on 2.7 and 3.1. My OS is Gentoo/Linux, timezone-info is the latest version (2011h).

----------
messages: 142167
nosy: maksbotan
priority: normal
severity: normal
status: open
title: time.time() returns local time instead of UTC
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:11:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:11:49 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <4E4A263F.4050900@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Maxim Koltsov wrote:
> 
> New submission from Maxim Koltsov <kolmax94 at gmail.com>:
> 
> Python docs (http://docs.python.org/library/time.html#time.time) say that time.time() function should return UTC timestamp, but actually i get local one:
>>>> time.mktime(time.gmtime()), time.time(), time.mktime(time.localtime())
> (1313466499.0, 1313480899.384221, 1313480899.0)
> As you can see, the result of second statement is equal to result of the third, while it must be equal to result of the first. Checked on 2.7 and 3.1. My OS is Gentoo/Linux, timezone-info is the latest version (2011h).

The description in the docs is a bit misleading.

time.time() returns the local time in number of seconds since the epoch
(1970-01-01 00:00:0O UTC).

UTC refers to the epoch, not the timezone used by time.time().

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:14:53 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 08:14:53 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313482493.37.0.748217167067.issue12758@psf.upfronthosting.co.za>


Maxim Koltsov <kolmax94 at gmail.com> added the comment:

Then docs must be fixed. By the way, help(time.time) correctly says about localtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:17:19 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:17:19 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313482639.23.0.726064271832.issue12758@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:17:33 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:17:33 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313482653.63.0.946526636944.issue12758@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:19:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 08:19:07 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313482747.15.0.150691490186.issue12751@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

#10542 proposes the following macros to factor out common code:
 #define _Py_UNICODE_ISSURROGATE
 #define _Py_UNICODE_ISHIGHSURROGATE
 #define _Py_UNICODE_ISLOWSURROGATE
 #define _Py_UNICODE_JOIN_SURROGATES
and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring):
 #define _Py_UNICODE_NEXT
 #define _Py_UNICODE_PUT_NEXT

Your patch proposes the same 4 macros:
 #define IS_SURROGATE
 #define IS_HIGH_SURROGATE
 #define IS_LOW_SURROGATE
 #define COMBINE_SURROGATES
+ 3 additional macros:
 #define IS_NONBMP
 #define HIGH_SURROGATE
 #define LOW_SURROGATE

So the two issue looks quite similar to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:25:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 08:25:54 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313483154.51.0.545266104115.issue12758@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Would dropping 'in UTC' from
"""
Return the time as a floating point number expressed in seconds since the epoch, in UTC.
"""
be an acceptable solution?  AFAIK there are no "non-UTC epochs".

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:27:32 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 08:27:32 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313483252.93.0.273974026474.issue12758@psf.upfronthosting.co.za>


Maxim Koltsov <kolmax94 at gmail.com> added the comment:

Maybe add some words about local timezone?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:30:27 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:30:27 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313429180.23.0.763014445011.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4A2A9E.6010501@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> A PEP 393 draft implementation is available at https://bitbucket.org/t0rsten/pep-393/ (branch pep-393); if this gets into 3.3, this issue will be outdated: there won't be "narrow" builds of Python anymore (nor will there be "wide" builds).

Even if PEP 393 should go into Py4k one day (I don't believe that
such major changes can be done in a minor release), we will still have
to deal with surrogates in codecs, which is where these macros will get
used, so I don't see how PEP 393 relates to the idea of adding helper
macros to simplify the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 10:31:38 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:31:38 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313482747.15.0.150691490186.issue12751@psf.upfronthosting.co.za>
Message-ID: <4E4A2AE5.1020509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> #10542 proposes the following macros to factor out common code:
>  #define _Py_UNICODE_ISSURROGATE
>  #define _Py_UNICODE_ISHIGHSURROGATE
>  #define _Py_UNICODE_ISLOWSURROGATE
>  #define _Py_UNICODE_JOIN_SURROGATES
> and to avoid checking for narrow/wide builds and recombine surrogates manually (so still refactoring):
>  #define _Py_UNICODE_NEXT
>  #define _Py_UNICODE_PUT_NEXT
> 
> Your patch proposes the same 4 macros:
>  #define IS_SURROGATE
>  #define IS_HIGH_SURROGATE
>  #define IS_LOW_SURROGATE
>  #define COMBINE_SURROGATES
> + 3 additional macros:
>  #define IS_NONBMP
>  #define HIGH_SURROGATE
>  #define LOW_SURROGATE
> 
> So the two issue looks quite similar to me.

Can we please fold this issue into #10542. We've already had the
discussion there.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                49 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Tue Aug 16 11:12:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 09:12:10 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313485930.8.0.601749695449.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the 4 macros:
 #define _Py_UNICODE_ISSURROGATE
 #define _Py_UNICODE_ISHIGHSURROGATE
 #define _Py_UNICODE_ISLOWSURROGATE
 #define _Py_UNICODE_JOIN_SURROGATES
are quite straightforward and can avoid using the trailing _.

Since I would like to see #9200 fixed on 3.2 (and possibly 2.7 too), would it be ok to:
 1) commit the patch with the trailing _ for all the macros on 3.2(/2.7);
 2) commit the patch with the trailing _ only for the _NEXT macros in 3.3;
 3) fix #9200 on all these branches using the new macros (with or without _);
 4) remove the trailing _ from the _NEXT macros in 3.4 if it turns out to work well;


> we will still have to deal with surrogates in codecs,
> which is where these macros will get used

They will also be used in many str methods and afaiu PEP 393 should address that.  I'm not sure it addresses codecs and builtin functions like chr() and ord() too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 11:17:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 09:17:01 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313486221.67.0.380443207718.issue12758@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

"""
Return the local time as a floating point number expressed in seconds since the epoch.
"""

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 11:18:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 09:18:46 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313485930.8.0.601749695449.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313486199.3542.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think the 4 macros:
>  #define _Py_UNICODE_ISSURROGATE
>  #define _Py_UNICODE_ISHIGHSURROGATE
>  #define _Py_UNICODE_ISLOWSURROGATE
>  #define _Py_UNICODE_JOIN_SURROGATES
> are quite straightforward and can avoid using the trailing _.

I don't want to bikeshed, but can we have proper consistent word
separation?
_Py_UNICODE_IS_HIGH_SURROGATE, not _Py_UNICODE_ISHIGHSURROGATE
(etc.)

> > we will still have to deal with surrogates in codecs,
> > which is where these macros will get used
> 
> They will also be used in many str methods and afaiu PEP 393 should
> address that.  I'm not sure it addresses codecs and builtin functions
> like chr() and ord() too.

AFAIU, PEP 393 avoids producing surrogate pairs in the canonical
internal representation (that's one of its selling points). Only the
UTF-16 codecs would need to deal with surrogate pairs, in the encoded
form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 11:23:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 09:23:50 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313486630.0.0.581318602819.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

All the other macros[0] follow the same convention, e.g. Py_UNICODE_ISLOWER and Py_UNICODE_TOLOWER.  I agree that keeping the words separate makes them more readable though.
[0]: Include/unicodeobject.h:328

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 11:37:18 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 09:37:18 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313487438.52.0.594374700545.issue12758@psf.upfronthosting.co.za>


Maxim Koltsov <kolmax94 at gmail.com> added the comment:

Seems OK to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Tue Aug 16 12:00:54 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Tue, 16 Aug 2011 10:00:54 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313488854.27.0.819372297787.issue12755@psf.upfronthosting.co.za>


Chandra Sekhar Reddy <sanch09 at ca.com> added the comment:

Hi Amaury,

Thanks for your update on the issue.

Here are few details of our application adem.exe

1. We have three c-projects namely, AdemCube, wv, CAM, the output of the build binaries will give us _ADEMCube.pyd, _wv.pyd, _cam.pyd

2. The main project is spider project which is in python, this python code will make us of the above libraries. The output of this project will result in adem.exe

The adem.exe when it executes it internally calls methods to above libraries explained in point 1. Here in this library we use call to the method below

 PyErr_SetString(CubeError, errorString);

The call to this method is internally calls PyString_FromStringAndSize() which internally calls PyObject_Malloc(). This is the place where it is crashing.

Please let me know if you need any information.

Thanks,
-Chandra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Tue Aug 16 12:12:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 10:12:43 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313489563.75.0.760563674121.issue12755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Are you sure that errorString is not NULL? It looks like a bug in your application, not in Python.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Tue Aug 16 12:34:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 16 Aug 2011 10:34:45 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313490885.91.0.698558814955.issue12740@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Including the format string in the error output is a good idea. Meador,
was this a constructed failure to show the output or did it really
occur?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Tue Aug 16 13:04:42 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Tue, 16 Aug 2011 11:04:42 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313485930.8.0.601749695449.issue10542@psf.upfronthosting.co.za>
Message-ID: <26743.1313492664@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

>Ezio Melotti <ezio.melotti at gmail.com> added the comment:

>I think the 4 macros:
> #define _Py_UNICODE_ISSURROGATE
> #define _Py_UNICODE_ISHIGHSURROGATE
> #define _Py_UNICODE_ISLOWSURROGATE
> #define _Py_UNICODE_JOIN_SURROGATES
>are quite straightforward and can avoid using the trailing _.

For what it's worth, I've seen Unicode documentation that talks about
that prefers the terms "lead surrogate" and "trail surrogate" as being
clearer than the terms "high surrgoate" and "low   surrogate".

For example, from the Unicode BOM FAQ at http://unicode.org/faq/utf_bom.html

    Q: What are surrogates?

    A: Surrogates are code points from two special ranges of Unicode values, reserved for use as the leading, and
       trailing values of paired code units in UTF-16. Leading, also called high, surrogates are from D800?? to DBFF??,
       and trailing, or low, surrogates are from DC00?? to DFFF??. They are called surrogates, since they do not
       represent characters directly, but only as a pair.

BTW, considering recent discussions, you might want to read:

    Q: Are there any 16-bit values that are invalid?

    A: The two values FFFE?? and FFFF?? as well as the 32 values from FDD0?? to FDEF?? represent noncharacters. They are
       invalid in interchange, but may be freely used internal to an implementation. Unpaired surrogates are invalid as
       well, i.e. any value in the range D800?? to DBFF?? not followed by a value in the range DC00?? to DFFF??, or any
       value in the range DC00?? to DFFF?? not preceded by a value in the range D800?? to DBFF??. [AF]

and also the answer to:

    Q: Are there any paired surrogates that are invalid?

whose answer I here omit for brevity, as it is a table.

I suspect that you guys are now increasingly sold on the answer to the next FAQ right after that one, now. :)

    Q: Because supplementary characters are uncommon, does that mean I can ignore them?

    A: Just because supplementary characters (expressed with surrogate pairs in UTF-16) are uncommon does 
       not mean that they should be neglected. They include:

        * emoji symbols and emoticons, for interoperating with Japanese mobile phones
        * uncommon (but not unused) CJK characters, important for personal and place names
        * variation selectors for ideographic variation sequences
        * important symbols for mathematics
        * numerous minority scripts and historic scripts, important for some user communities

Another example of using "lead" and "trail" surrogates is in the first
sentence from http://icu-project.org/apiref/icu4j/com/ibm/icu/text/UTF16.html

    * Naming: For clarity, High and Low surrogates are called Lead and Trail in the API, which gives a better sense of
      their ordering in a string. offset16 and offset32 are used to distinguish offsets to UTF-16 boundaries vs offsets
      to UTF-32 boundaries. int char32 is used to contain UTF-32 characters, as opposed to char16, which is a UTF-16
      code unit.
    * Roundtripping Offsets: You can always roundtrip from a UTF-32 offset to a UTF-16 offset and back. Because of the
      difference in structure, you can roundtrip from a UTF-16 offset to a UTF-32 offset and back if and only if
      bounds(string, offset16) != TRAIL.
    * Exceptions: The error checking will throw an exception if indices are out of bounds. Other than than that, all
      methods will behave reasonably, even if unmatched surrogates or out-of-bounds UTF-32 values are present.
      UCharacter.isLegal() can be used to check for validity if desired.
    * Unmatched Surrogates: If the string contains unmatched surrogates, then these are counted as one UTF-32 value.
      This matches their iteration behavior, which is vital. It also matches common display practice as missing glyphs
      (see the Unicode Standard Section 5.4, 5.5).
    * Optimization: The method implementations may need optimization if the compiler doesn't fold static final methods.
      Since surrogate pairs will form an exceeding small percentage of all the text in the world, the singleton case
      should always be optimized for.

You can also see this reflected in the utf.h file from the ICU project as part of their C API in ICU4C:

    #define     U_SENTINEL   (-1)
            This value is intended for sentinel values for APIs that (take or) return single code points (UChar32). 
    #define     U_IS_UNICODE_NONCHAR(c)
            Is this code point a Unicode noncharacter? 
    #define     U_IS_UNICODE_CHAR(c)
            Is c a Unicode code point value (0..U+10ffff) that can be assigned a character? 
    #define     U_IS_BMP(c)   ((uint32_t)(c)<=0xffff)
            Is this code point a BMP code point (U+0000..U+ffff)? 
    #define     U_IS_SUPPLEMENTARY(c)   ((uint32_t)((c)-0x10000)<=0xfffff)
            Is this code point a supplementary code point (U+10000..U+10ffff)? 
    #define     U_IS_LEAD(c)   (((c)&0xfffffc00)==0xd800)
            Is this code point a lead surrogate (U+d800..U+dbff)? 
    #define     U_IS_TRAIL(c)   (((c)&0xfffffc00)==0xdc00)
            Is this code point a trail surrogate (U+dc00..U+dfff)? 
    #define     U_IS_SURROGATE(c)   (((c)&0xfffff800)==0xd800)
            Is this code point a surrogate (U+d800..U+dfff)? 
    #define     U_IS_SURROGATE_LEAD(c)   (((c)&0x400)==0)
            Assuming c is a surrogate code point (U_IS_SURROGATE(c)), is it a lead surrogate? 
    #define     U_IS_SURROGATE_TRAIL(c)   (((c)&0x400)!=0)
            Assuming c is a surrogate code point (U_IS_SURROGATE(c)), is it a trail surrogate?

Another one is:

    http://www.opensource.apple.com/source/WebCore/WebCore-1C25/icu/unicode/utf16.h

which contains:

    #define U16_IS_SINGLE(c) !U_IS_SURROGATE(c)
    #define U16_IS_LEAD(c) (((c)&0xfffffc00)==0xd800)
    #define U16_IS_TRAIL(c) (((c)&0xfffffc00)==0xdc00)
    #define U16_IS_SURROGATE(c) U_IS_SURROGATE(c)
    #define U16_IS_SURROGATE_LEAD(c) (((c)&0x400)==0)
    #define U16_SURROGATE_OFFSET ((0xd800<<10UL)+0xdc00-0x10000)
    #define U16_GET_SUPPLEMENTARY(lead, trail) \
    #define U16_LEAD(supplementary) (UChar)(((supplementary)>>10)+0xd7c0)
    #define U16_TRAIL(supplementary) (UChar)(((supplementary)&0x3ff)|0xdc00)
    #define U16_LENGTH(c) ((uint32_t)(c)<=0xffff ? 1 : 2)

In fact, you might want to read over that file, as it has embedded documentation
for these, and has other macros for being careful about surrogates.  For example,
here's one in full:

    /**
     * Get a code point from a string at a random-access offset,
     * without changing the offset.
     * "Unsafe" macro, assumes well-formed UTF-16.
     *
     * The offset may point to either the lead or trail surrogate unit
     * for a supplementary code point, in which case the macro will read
     * the adjacent matching surrogate as well.
     * The result is undefined if the offset points to a single, unpaired surrogate.
     * Iteration through a string is more efficient with U16_NEXT_UNSAFE or U16_NEXT.
     *
     * @param s const UChar * string
     * @param i string offset
     * @param c output UChar32 variable
     * @see U16_GET
     * @stable ICU 2.4
     */
    #define U16_GET_UNSAFE(s, i, c) { \
	(c)=(s)[i]; \
	if(U16_IS_SURROGATE(c)) { \
	    if(U16_IS_SURROGATE_LEAD(c)) { \
		(c)=U16_GET_SUPPLEMENTARY((c), (s)[(i)+1]); \
	    } else { \
		(c)=U16_GET_SUPPLEMENTARY((s)[(i)-1], (c)); \
	    } \
	} \
    }

So keeping your preamble bits, I might have considered doing it
this way if it were me doing it:

    #define _Py_UNICODE_IS_SURROGATE
    #define _Py_UNICODE_IS_LEAD_SURROGATE
    #define _Py_UNICODE_IS_TRAIL_SURROGATE
    #define _Py_UNICODE_JOIN_SURROGATES

But I also come from a culture that uses more underscores than you guys tend 
to, as shown in some of the macro names shown below from utf8.h file.  I find
that most projects use more underscores in uppercase names than Python does. :)

--tom

#define UTF_START_MARK(len) (((len) >  7) ? 0xFF : (0xFE << (7-(len))))
#define UTF_START_MASK(len) (((len) >= 7) ? 0x00 : (0x1F >> ((len)-2)))
#define UTF_CONTINUATION_MARK           0x80
#define UTF_ACCUMULATION_SHIFT          6
#define UTF_CONTINUATION_MASK           ((U8)0x3f)
#define UNISKIP(uv) ( (uv) < 0x80           ? 1 : \
#define UNISKIP(uv) ( (uv) < 0x80           ? 1 : \
#define NATIVE_IS_INVARIANT(c)          UNI_IS_INVARIANT(NATIVE8_TO_UNI(c))
#define IN_BYTES (CopHINTS_get(PL_curcop) & HINT_BYTES)
#define UNICODE_SURROGATE_FIRST         0xD800
#define UNICODE_SURROGATE_LAST          0xDFFF
#define UNICODE_REPLACEMENT             0xFFFD
#define UNICODE_BYTE_ORDER_MARK         0xFEFF
#define PERL_UNICODE_MAX        0x10FFFF
#define UNICODE_WARN_SURROGATE     0x0001       /* UTF-16 surrogates */
#define UNICODE_WARN_NONCHAR       0x0002       /* Non-char code points */
#define UNICODE_WARN_SUPER         0x0004       /* Above 0x10FFFF */
#define UNICODE_WARN_FE_FF         0x0008       
#define UNICODE_DISALLOW_SURROGATE 0x0010
#define UNICODE_DISALLOW_NONCHAR   0x0020
#define UNICODE_DISALLOW_SUPER     0x0040
#define UNICODE_DISALLOW_FE_FF     0x0080
#define UNICODE_WARN_ILLEGAL_INTERCHANGE \
#define UNICODE_DISALLOW_ILLEGAL_INTERCHANGE \
#define UNICODE_ALLOW_SURROGATE 0
#define UNICODE_ALLOW_SUPER     0
#define UNICODE_ALLOW_ANY       0
#define UNICODE_IS_SURROGATE(c)         ((c) >= UNICODE_SURROGATE_FIRST && \
#define UNICODE_IS_REPLACEMENT(c)       ((c) == UNICODE_REPLACEMENT)
#define UNICODE_IS_BYTE_ORDER_MARK(c)   ((c) == UNICODE_BYTE_ORDER_MARK)
#define UNICODE_IS_NONCHAR(c)           ((c >= 0xFDD0 && c <= 0xFDEF) \
#define UNICODE_IS_SUPER(c)             ((c) > PERL_UNICODE_MAX)
#define UNICODE_IS_FE_FF(c)             ((c) > 0x7FFFFFFF)
#define UNICODE_GREEK_CAPITAL_LETTER_SIGMA      0x03A3
#define UNICODE_GREEK_SMALL_LETTER_FINAL_SIGMA  0x03C2
#define UNICODE_GREEK_SMALL_LETTER_SIGMA        0x03C3
#define GREEK_SMALL_LETTER_MU                   0x03BC
#define GREEK_CAPITAL_LETTER_MU 0x039C  /* Upper and title case of MICRON */
#define LATIN_CAPITAL_LETTER_Y_WITH_DIAERESIS 0x0178    /* Also is title case */
#define LATIN_CAPITAL_LETTER_SHARP_S    0x1E9E
#define UNI_DISPLAY_ISPRINT     0x0001
#define UNI_DISPLAY_BACKSLASH   0x0002
#define UNI_DISPLAY_QQ          (UNI_DISPLAY_ISPRINT|UNI_DISPLAY_BACKSLASH)
#define UNI_DISPLAY_REGEX       (UNI_DISPLAY_ISPRINT|UNI_DISPLAY_BACKSLASH)
#define LATIN_SMALL_LETTER_SHARP_S      0x00DF
#define LATIN_SMALL_LETTER_Y_WITH_DIAERESIS 0x00FF
#define MICRO_SIGN 0x00B5
#define LATIN_CAPITAL_LETTER_A_WITH_RING_ABOVE 0x00C5
#define LATIN_SMALL_LETTER_A_WITH_RING_ABOVE 0x00E5
#define ANYOF_FOLD_SHARP_S(node, input, end)    \
#define SHARP_S_SKIP 2

PS: Those won't always make sense for lack of continuation lines and enclosing ifdefs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 13:22:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Aug 2011 11:22:37 +0000
Subject: [issue12756] datetime.datetime.utcnow should return a UTC timestamp
In-Reply-To: <1313477575.0.0.856648078618.issue12756@psf.upfronthosting.co.za>
Message-ID: <1313493757.26.0.626681833899.issue12756@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12756>
_______________________________________

From report at bugs.python.org  Tue Aug 16 13:43:01 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Tue, 16 Aug 2011 11:43:01 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313485930.8.0.601749695449.issue10542@psf.upfronthosting.co.za>
Message-ID: <8895.1313494957@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

I now see there are lots of good things in the BOM FAQ that have come up
lately regarding surrogates and other illegal characters, and about what
can go in data streams.  

I quote a few of these from http://unicode.org/faq/utf_bom.html below:

    Q: How do I convert an unpaired UTF-16 surrogate to UTF-8? 

    A: A different issue arises if an unpaired surrogate is encountered when converting ill-formed UTF-16 data. 
       By represented such an *unpaired* surrogate on its own as a 3-byte sequence, the resulting UTF-8 data stream
       would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires
       that encoding form conversion always results in valid data stream. Therefore a converter *must* treat this
       as an error.

    Q: How do I convert an unpaired UTF-16 surrogate to UTF-32? 

    A: If an unpaired surrogate is encountered when converting ill-formed UTF-16 data, any conformant converter must
       treat this as an error. By representing such an unpaired surrogate on its own, the resulting UTF-32 data stream
       would become ill-formed. While it faithfully reflects the nature of the input, Unicode conformance requires that
       encoding form conversion always results in valid data stream.

    Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining
       UTF-8 bytes are in big-endian order?

    A: Yes, UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8
       always has the same byte order. An initial BOM is only used as a signature ? an indication that an otherwise
       unmarked text file is in UTF-8. Note that some recipients of UTF-8 encoded data do not expect a BOM. Where UTF-8
       is used transparently in 8-bit environments, the use of a BOM will interfere with any protocol or file format
       that expects specific ASCII characters at the beginning, such as the use of "#!" of at the beginning of Unix
       shell scripts.

    Q: What should I do with U+FEFF in the middle of a file?

    A: In the absence of a protocol supporting its use as a BOM and when not at the beginning of a text stream, U+FEFF
       should normally not occur. For backwards compatibility it should be treated as ZERO WIDTH NON-BREAKING SPACE
       (ZWNBSP), and is then part of the content of the file or string. The use of U+2060 WORD JOINER is strongly
       preferred over ZWNBSP for expressing word joining semantics since it cannot be confused with a BOM. When
       designing a markup language or data protocol, the use of U+FEFF can be restricted to that of Byte Order Mark. In
       that case, any U+FEFF occurring in the middle of a file can be treated as an unsupported character.

    Q: How do I tag data that does not interpret U+FEFF as a BOM?

    A: Use the tag UTF-16BE to indicate big-endian UTF-16 text, and UTF-16LE to indicate little-endian UTF-16 text. 
       If you do use a BOM, tag the text as simply UTF-16. 

    Q: Why wouldn?t I always use a protocol that requires a BOM?

    A: Where the data has an associated type, such as a field in a database, a BOM is unnecessary. In particular, 
       if a text data stream is marked as UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary *nor
       permitted*. Any U+FEFF would be interpreted as a ZWNBSP.  Do not tag every string in a database or set of fields
       with a BOM, since it wastes space and complicates string concatenation. Moreover, it also means two data fields
       may have precisely the same content, but not be binary-equal (where one is prefaced by a BOM).

Somewhat frustratingly, I am now almost more confused than ever by the last two sentences here:

    Q: What is a UTF?

    A: A Unicode transformation format (UTF) is an algorithmic mapping from every Unicode code point (except surrogate
       code points) to a unique byte sequence. The ISO/IEC 10646 standard uses the term ?UCS transformation format? for
       UTF; the two terms are merely synonyms for the same concept.

       Each UTF is reversible, thus every UTF supports *lossless round tripping*: mapping from any Unicode coded
       character sequence S to a sequence of bytes and back will produce S again. To ensure round tripping, a UTF
       mapping *must also* map all code points that are not valid Unicode characters to unique byte sequences. These
       invalid code points are the 66 *noncharacters* (including FFFE and FFFF), as well as unpaired surrogates.

My confusion is about the invalid code points. The first two FAQs I cite at the top are quite clear that it is illegal
to have unpaired surrogates in a UTF stream.  I don?t understand therefore what it saying about ?must also? mapping all
code points that aren?t valid Unicode characters to ?unique byte sequences? to ensure roundtripping.  At first reading,
I?d almost say those appear to contradict each other.  I must just be being boneheaded though.  It?s very early morning
yet, and maybe it will become clearer upon a fifth or sixth reading.  Maybe it has to with replacement characters?  No, 
that can?t be right.  Muddle muddle.  Sigh.

Important material is also found in http://www.unicode.org/faq/basic_q.html:

    Q: Are surrogate characters the same as supplementary characters?

    A: This question shows a common confusion. It is very important to distinguish surrogate code points (in the range
       U+D800..U+DFFF) from supplementary code points (in the completely different range, U+10000..U+10FFFF). Surrogate
       code points are reserved for use, in pairs, in representing supplementary code points in UTF-16.

       There are supplementary characters (i.e. encoded characters represented with a single supplementary code point), but
       there are not and will never be surrogate characters (i.e. encoded characters represented with a single surrogate
       code point).

    Q: What is the difference between UCS-2 and UTF-16?

    A: UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1, before surrogate code
       points and UTF-16 were added to Version 2.0 of the standard. This term should now be avoided.

       UCS-2 does not define a distinct data format, because UTF-16 and UCS-2 are identical for purposes of data exchange.
       Both are 16-bit, and have exactly the same code unit representation.

       Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary
       characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not
       handle processing of character properties, code point boundaries, collation, etc. for supplementary characters.

And in reference to UTF-16 being slower by code point than by code unit:

    Q: How about using UTF-32 interfaces in my APIs?

    A: Except in some environments that store text as UTF-32 in memory, most Unicode APIs are using UTF-16. With UTF-16
       APIs  the low level indexing is at the storage or code unit level, with higher-level mechanisms for graphemes or
       words specifying their boundaries in terms of the code units. This provides efficiency at the low levels, and the
       required functionality at the high levels.

        If its [sic] ever necessary to locate the n?? character, indexing by character can be implemented as a high
        level operation. However, while converting from such a UTF-16 code unit index to a character index or vice versa
        is fairly straightforward, it does involve a scan through the 16-bit units up to the index point. In a test run,
        for example, accessing UTF-16 storage as characters, instead of code units resulted in a 10? degradation. While
        there are some interesting optimizations that can be performed, it will always be slower on average. Therefore
        locating other boundaries, such as grapheme, word, line or sentence boundaries proceeds directly from the code
        unit index, not indirectly via an intermediate character code index.

I am somewhat amused by this summary:

    Q: What does Unicode conformance require?

    A: Chapter 3, Conformance discusses this in detail. Here's a very informal version: 

        * Unicode characters don't fit in 8 bits; deal with it.
        * 2 [sic] Byte order is only an issue in I/O.
        * If you don't know, assume big-endian.
        * Loose surrogates have no meaning.
        * Neither do U+FFFE and U+FFFF.
        * Leave the unassigned codepoints alone.
        * It's OK to be ignorant about a character, but not plain wrong.
        * Subsets are strictly up to you.
        * Canonical equivalence matters.
        * Don't garble what you don't understand.
        * Process UTF-* by the book.
        * Ignore illegal encodings.
        * Right-to-left scripts have to go by bidi rules. 

And don?t know what I think about this, except that there sure a lot of 
screw?ups out there if it is truly as easy as they would would have you believe:

    Given that any industrial-strength text and internationalization support API has to be able to handle sequences of
    characters, it makes little difference whether the string is internally represented by a sequence of [...] code
    units, or by a sequence of code-points [...]. Both UTF-16 and UTF-8 are designed to make working with substrings
    easy, by the fact that the sequence of code units for a given code point is unique.

Take this all with a grain of salt, since I found various typos in these FAQs
and occasionally also language that seems to reflect an older nomenclature than
is now seen in the current published Unicode Standard, meaning 6.0.0.  Probably
best then to take only general directives from their FAQs and leave language?
lawyering to the formal printed Standard, insofar as that is possible ? which
sometimes it is not, because they do make mistakes from time to time, and even
less frequently, correct these.  :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 13:44:15 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Tue, 16 Aug 2011 11:44:15 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313486199.3542.3.camel@localhost.localdomain>
Message-ID: <7561.1313495047@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote
   on Tue, 16 Aug 2011 09:18:46 -0000: 

>> I think the 4 macros:
>>  #define _Py_UNICODE_ISSURROGATE
>>  #define _Py_UNICODE_ISHIGHSURROGATE
>>  #define _Py_UNICODE_ISLOWSURROGATE
>>  #define _Py_UNICODE_JOIN_SURROGATES
>> are quite straightforward and can avoid using the trailing _.

> I don't want to bikeshed, but can we have proper consistent word separation?
> _Py_UNICODE_IS_HIGH_SURROGATE, not _Py_UNICODE_ISHIGHSURROGATE
> (etc.)

Oh good, I thought it was only me whohadtroublereadingthose. :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 13:54:14 2011
From: report at bugs.python.org (Alexander)
Date: Tue, 16 Aug 2011 11:54:14 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py throw an
	exception
Message-ID: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>


New submission from Alexander <fredeom at mail.ru>:

Run:
python <PYTHON_PATH>/Tools/scripts/redemo.py
Enter "(?P=)" in entry field.
See unhandled exception occures.
There is special text field in example for such cases. It should be used to show error messages, not a console.

----------
components: Demos and Tools
files: redemo.py.png
messages: 142186
nosy: fredeom
priority: normal
severity: normal
status: open
title: "(?P=)" input for Tools/scripts/redemo.py throw an exception
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22908/redemo.py.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Tue Aug 16 14:08:35 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Tue, 16 Aug 2011 12:08:35 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313486630.0.0.581318602819.issue10542@psf.upfronthosting.co.za>
Message-ID: <32167.1313496501@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Ezio Melotti <report at bugs.python.org> wrote
   on Tue, 16 Aug 2011 09:23:50 -0000: 

> All the other macros[0] follow the same convention, e.g. Py_UNICODE_ISLOWER
> and Py_UNICODE_TOLOWER.  I agree that keeping the words separate makes them
> more readable though.

> 	[0]: Include/unicodeobject.h:328

I am guessing that that is not quite why those don't have underscores
in them.  I bet it is actually something else.  Watch:

    % unigrep '^\s*#\s*define\s+Py_[\p{Lu}_]+\b' unicodeobject.h
    #define Py_UNICODEOBJECT_H
    #define Py_USING_UNICODE
    #define Py_UNICODE_WIDE
    #define Py_UNICODE_ISSPACE(ch) \
    #define Py_UNICODE_ISLOWER(ch) _PyUnicode_IsLowercase(ch)
    #define Py_UNICODE_ISUPPER(ch) _PyUnicode_IsUppercase(ch)
    #define Py_UNICODE_ISTITLE(ch) _PyUnicode_IsTitlecase(ch)
    #define Py_UNICODE_ISLINEBREAK(ch) _PyUnicode_IsLinebreak(ch)
    #define Py_UNICODE_TOLOWER(ch) _PyUnicode_ToLowercase(ch)
    #define Py_UNICODE_TOUPPER(ch) _PyUnicode_ToUppercase(ch)
    #define Py_UNICODE_TOTITLE(ch) _PyUnicode_ToTitlecase(ch)
    #define Py_UNICODE_ISDECIMAL(ch) _PyUnicode_IsDecimalDigit(ch)
    #define Py_UNICODE_ISDIGIT(ch) _PyUnicode_IsDigit(ch)
    #define Py_UNICODE_ISNUMERIC(ch) _PyUnicode_IsNumeric(ch)
    #define Py_UNICODE_ISPRINTABLE(ch) _PyUnicode_IsPrintable(ch)
    #define Py_UNICODE_TODECIMAL(ch) _PyUnicode_ToDecimalDigit(ch)
    #define Py_UNICODE_TODIGIT(ch) _PyUnicode_ToDigit(ch)
    #define Py_UNICODE_TONUMERIC(ch) _PyUnicode_ToNumeric(ch)
    #define Py_UNICODE_ISALPHA(ch) _PyUnicode_IsAlpha(ch)
    #define Py_UNICODE_ISALNUM(ch) \
    #define Py_UNICODE_COPY(target, source, length)                         \
    #define Py_UNICODE_FILL(target, value, length) \
    #define Py_UNICODE_MATCH(string, offset, substring) \
    #define Py_UNICODE_REPLACEMENT_CHARACTER ((Py_UNICODE) 0xFFFD)

It looks like what is actually happening there is that you started out
with names of the normal ctype(3) macroish thingies:

     isalpha isupper islower isdigit isxdigit isalnum isspace ispunct
     isprint isgraph iscntrl isblank isascii  toupper isblank isascii
     toupper tolower toascii

and wanted to preserve those, which would lead to Py_UNICODE_TOLOWER and
Py_UNICODE_TOUPPER, since there are no functions in the original C versions
those seem to mirror.  Then when you wanted more of that ilk, you sensibly
kept to the same naming convention.

I eyeball few exceptions to that style here:

    % perl -nle '/^\s*#\s*define\s+(Py_[\p{Lu}_]+)\b/ and print $1' Include/*.h | sort -dfu | fmt -150
    Py_ABSTRACTOBJECT_H Py_ALIGNED Py_ALLOW_RECURSION Py_ARITHMETIC_RIGHT_SHIFT Py_ASDL_H Py_AST_H Py_ATOMIC_H Py_BEGIN_ALLOW_THREADS Py_BITSET_H
    Py_BLOCK_THREADS Py_BLTINMODULE_H Py_BOOLOBJECT_H Py_BYTEARRAYOBJECT_H Py_BYTES_CTYPE_H Py_BYTESOBJECT_H Py_CAPSULE_H Py_CELLOBJECT_H Py_CEVAL_H
    Py_CHARMASK Py_CLASSOBJECT_H Py_CLEANUP_SUPPORTED Py_CLEAR Py_CODECREGISTRY_H Py_CODE_H Py_COMPILE_H Py_COMPLEXOBJECT_H Py_CURSES_H Py_DECREF
    Py_DEPRECATED Py_DESCROBJECT_H Py_DICTOBJECT_H Py_DTSF_ALT Py_DTSF_SIGN Py_DTST_FINITE Py_DTST_INFINITE Py_DTST_NAN Py_END_ALLOW_RECURSION
    Py_END_ALLOW_THREADS Py_ENUMOBJECT_H Py_EQ Py_ERRCODE_H Py_ERRORS_H Py_EVAL_H Py_FILEOBJECT_H Py_FILEUTILS_H Py_FLOATOBJECT_H Py_FORCE_DOUBLE
    Py_FORCE_EXPANSION Py_FORMAT_PARSETUPLE Py_FRAMEOBJECT_H Py_FUNCOBJECT_H Py_GCC_ATTRIBUTE Py_GE Py_GENOBJECT_H Py_GETENV Py_GRAMMAR_H Py_GT
    Py_HUGE_VAL Py_IMPORT_H Py_INCREF Py_INTRCHECK_H Py_INVALID_SIZE Py_ISALNUM Py_ISALPHA Py_ISDIGIT Py_IS_FINITE Py_IS_INFINITY Py_ISLOWER Py_IS_NAN
    Py_ISSPACE Py_ISUPPER Py_ISXDIGIT Py_ITEROBJECT_H Py_LE Py_LISTOBJECT_H Py_LL Py_LOCAL Py_LOCAL_INLINE Py_LONGINTREPR_H Py_LONGOBJECT_H Py_LT
    Py_MARSHAL_H Py_MARSHAL_VERSION Py_MATH_E Py_MATH_PI Py_MEMCPY Py_MEMORYOBJECT_H Py_METAGRAMMAR_H Py_METHODOBJECT_H Py_MODSUPPORT_H Py_MODULEOBJECT_H
    Py_NAN Py_NE Py_NODE_H Py_OBJECT_H Py_OBJIMPL_H Py_OPCODE_H Py_OSDEFS_H Py_OVERFLOWED Py_PARSETOK_H Py_PGEN_H Py_PGENHEADERS_H Py_PRINT_RAW
    Py_PYARENA_H Py_PYDEBUG_H Py_PYFPE_H Py_PYGETOPT_H Py_PYMATH_H Py_PYMEM_H Py_PYPORT_H Py_PYSTATE_H Py_PYTHON_H Py_PYTHONRUN_H Py_PYTHREAD_H
    Py_PYTIME_H Py_RANGEOBJECT_H Py_REFCNT Py_REF_DEBUG Py_RETURN_FALSE Py_RETURN_INF Py_RETURN_NAN Py_RETURN_NONE Py_RETURN_TRUE Py_SAFE_DOWNCAST
    Py_SET_ERANGE_IF_OVERFLOW Py_SET_ERRNO_ON_MATH_ERROR Py_SETOBJECT_H Py_SIZE Py_SLICEOBJECT_H Py_STRCMP_H Py_STRTOD_H Py_STRUCTMEMBER_H Py_STRUCTSEQ_H
    Py_SYMTABLE_H Py_SYSMODULE_H Py_TOKEN_H Py_TOLOWER Py_TOUPPER Py_TPFLAGS_BASE_EXC_SUBCLASS Py_TPFLAGS_BASETYPE Py_TPFLAGS_BYTES_SUBCLASS
    Py_TPFLAGS_DEFAULT Py_TPFLAGS_DICT_SUBCLASS Py_TPFLAGS_HAVE_GC Py_TPFLAGS_HAVE_STACKLESS_EXTENSION Py_TPFLAGS_HAVE_VERSION_TAG Py_TPFLAGS_HEAPTYPE
    Py_TPFLAGS_INT_SUBCLASS Py_TPFLAGS_IS_ABSTRACT Py_TPFLAGS_LIST_SUBCLASS Py_TPFLAGS_LONG_SUBCLASS Py_TPFLAGS_READY Py_TPFLAGS_READYING
    Py_TPFLAGS_TUPLE_SUBCLASS Py_TPFLAGS_TYPE_SUBCLASS Py_TPFLAGS_UNICODE_SUBCLASS Py_TPFLAGS_VALID_VERSION_TAG Py_TRACEBACK_H Py_TRACE_REFS
    Py_TRASHCAN_SAFE_BEGIN Py_TRASHCAN_SAFE_END Py_TUPLEOBJECT_H Py_TYPE Py_UCNHASH_H Py_ULL Py_UNBLOCK_THREADS Py_UNICODE_COPY Py_UNICODE_FILL
    Py_UNICODE_ISALNUM Py_UNICODE_ISALPHA Py_UNICODE_ISDECIMAL Py_UNICODE_ISDIGIT Py_UNICODE_ISLINEBREAK Py_UNICODE_ISLOWER Py_UNICODE_ISNUMERIC
    Py_UNICODE_ISPRINTABLE Py_UNICODE_ISSPACE Py_UNICODE_ISTITLE Py_UNICODE_ISUPPER Py_UNICODE_MATCH Py_UNICODEOBJECT_H Py_UNICODE_REPLACEMENT_CHARACTER
    Py_UNICODE_TODECIMAL Py_UNICODE_TODIGIT Py_UNICODE_TOLOWER Py_UNICODE_TONUMERIC Py_UNICODE_TOTITLE Py_UNICODE_TOUPPER Py_UNICODE_WIDE Py_USING_UNICODE
    Py_VA_COPY Py_VISIT Py_WARNINGS_H Py_WEAKREFOBJECT_H Py_XDECREF Py_XINCREF

See what I mean?    Most of them that remain tend to be things that one could
construe as compound words, like "RANGEOBJECT" or "CODEREGISTRY",  though some
people might find a few a bit on the longish side to read unaided by
underscores, like "BYTEARRAYOBJECT".

'Nuff bikeshedding. :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 14:11:22 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 12:11:22 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <26743.1313492664@chthon>
Message-ID: <4E4A5E64.3000909@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tom Christiansen wrote:
> So keeping your preamble bits, I might have considered doing it
> this way if it were me doing it:
> 
>     #define _Py_UNICODE_IS_SURROGATE
>     #define _Py_UNICODE_IS_LEAD_SURROGATE
>     #define _Py_UNICODE_IS_TRAIL_SURROGATE
>     #define _Py_UNICODE_JOIN_SURROGATES
> 
> But I also come from a culture that uses more underscores than you guys tend 
> to, as shown in some of the macro names shown below from utf8.h file.  I find
> that most projects use more underscores in uppercase names than Python does. :)

The reasoning behind e.g. "ISSURROGATE" is that those names originate
from and are consistent with the already existing ISLOWER/ISUPPER/ISTITLE
macros which in return stem from the C APIs of the same names
(see unicodeobject.h for reference).

Regarding low/high vs. lead/trail: The Unicode database uses the
terms low/high and we do in Python as well, so let's stick with
those.

What I don't understand is why those macros should be declared
private to Python (with the leading underscore). They are quite
useful for extensions implementing codecs or other transformations
as well.

BTW: I think the other issues mentioned in the discussion are more
important to get right, than the names of those macros.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 14:24:10 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Tue, 16 Aug 2011 12:24:10 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4E4A5E64.3000909@egenix.com>
Message-ID: <29086.1313497441@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote
   on Tue, 16 Aug 2011 12:11:22 -0000: 

> The reasoning behind e.g. "ISSURROGATE" is that those names originate
> from and are consistent with the already existing ISLOWER/ISUPPER/ISTITLE
> macros which in return stem from the C APIs of the same names
> (see unicodeobject.h for reference).

I eventually figured that part out in the larger context.  
Makes sense looked at that way.

> Regarding low/high vs. lead/trail: The Unicode database uses the terms
> low/high and we do in Python as well, so let's stick with those.

Yes, those are their block assignments,  Block=High_Surrogates and Block=Low_Surrogates.
I just thought I should mention that in the time since those were invented (which cannot
be changed), after using them in real code for some years, their lingo seems to have 
evolved away from those initial names and toward lead/trail as less confusing.

> What I don't understand is why those macros should be declared
> private to Python (with the leading underscore). They are quite
> useful for extensions implementing codecs or other transformations
> as well.

I was wondering about that myself.  Beyond there being a lot fewer of those
private macros in the Python *.h files, they also seem to be of rather different
character than the iswhatever() macros:

    $ perl -nle '/^\s*#\s*define\s+(_Py_[\p{Lu}_]+)\b/ and print $1' *.h | sort -dfu | fmt -160
    _Py_ANNOTATE_BARRIER_DESTROY _Py_ANNOTATE_BARRIER_INIT _Py_ANNOTATE_BARRIER_WAIT_AFTER _Py_ANNOTATE_BARRIER_WAIT_BEFORE _Py_ANNOTATE_BENIGN_RACE
    _Py_ANNOTATE_BENIGN_RACE_SIZED _Py_ANNOTATE_BENIGN_RACE_STATIC _Py_ANNOTATE_CONDVAR_LOCK_WAIT _Py_ANNOTATE_CONDVAR_SIGNAL _Py_ANNOTATE_CONDVAR_SIGNAL_ALL
    _Py_ANNOTATE_CONDVAR_WAIT _Py_ANNOTATE_ENABLE_RACE_DETECTION _Py_ANNOTATE_EXPECT_RACE _Py_ANNOTATE_FLUSH_STATE _Py_ANNOTATE_HAPPENS_AFTER
    _Py_ANNOTATE_HAPPENS_BEFORE _Py_ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN _Py_ANNOTATE_IGNORE_READS_AND_WRITES_END _Py_ANNOTATE_IGNORE_READS_BEGIN
    _Py_ANNOTATE_IGNORE_READS_END _Py_ANNOTATE_IGNORE_SYNC_BEGIN _Py_ANNOTATE_IGNORE_SYNC_END _Py_ANNOTATE_IGNORE_WRITES_BEGIN _Py_ANNOTATE_IGNORE_WRITES_END
    _Py_ANNOTATE_MUTEX_IS_USED_AS_CONDVAR _Py_ANNOTATE_NEW_MEMORY _Py_ANNOTATE_NO_OP _Py_ANNOTATE_PCQ_CREATE _Py_ANNOTATE_PCQ_DESTROY _Py_ANNOTATE_PCQ_GET
    _Py_ANNOTATE_PCQ_PUT _Py_ANNOTATE_PUBLISH_MEMORY_RANGE _Py_ANNOTATE_PURE_HAPPENS_BEFORE_MUTEX _Py_ANNOTATE_RWLOCK_ACQUIRED _Py_ANNOTATE_RWLOCK_CREATE
    _Py_ANNOTATE_RWLOCK_DESTROY _Py_ANNOTATE_RWLOCK_RELEASED _Py_ANNOTATE_SWAP_MEMORY_RANGE _Py_ANNOTATE_THREAD_NAME _Py_ANNOTATE_TRACE_MEMORY
    _Py_ANNOTATE_UNPROTECTED_READ _Py_ANNOTATE_UNPUBLISH_MEMORY_RANGE _Py_AS_GC _Py_CHECK_REFCNT _Py_COUNT_ALLOCS_COMMA _Py_DEC_REFTOTAL _Py_DEC_TPFREES
    _Py_INC_REFTOTAL _Py_INC_TPALLOCS _Py_INC_TPFREES _Py_PARSE_PID _Py_REF_DEBUG_COMMA _Py_SET_EDOM_FOR_NAN

> BTW: I think the other issues mentioned in the discussion are more
> important to get right, than the names of those macros.

Yup.  Just paint it red. :)

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 14:30:50 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Aug 2011 12:30:50 +0000
Subject: [issue12750] datetime.datetime how to correctly attach a timezone to
	an existing naive datetime
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313497850.81.0.905127083882.issue12750@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK. At a minimum there is a doc issue here, so I'm reopening.

----------
nosy: +belopolsky
resolution: invalid -> 
status: closed -> open
title: datetime.datetime timezone problems -> datetime.datetime how to correctly attach a timezone to an existing naive datetime
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:20:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 16 Aug 2011 13:20:32 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1313500832.62.0.140253658983.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file22909/70a8ccd53ade.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:22:49 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 13:22:49 +0000
Subject: [issue12751] Use macros for surrogates in unicodeobject.c
In-Reply-To: <1313402784.58.0.330366720986.issue12751@psf.upfronthosting.co.za>
Message-ID: <1313500969.78.0.237374246768.issue12751@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Py_UNICODE_NEXT and other macros for surrogates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12751>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:25:54 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 16 Aug 2011 13:25:54 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1313501154.11.0.528535210943.issue10181@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

70a8ccd53ade fixes conversion of NumPy-style arrays to a suboffset
representation. The previous representation did not work for
slicing non-contiguous arrays with backward strides.

Also, I've added long comments that hopefully explain how slicing
with arbitrary strides and suboffsets is supposed to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:27:21 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Tue, 16 Aug 2011 13:27:21 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1313501241.04.0.653468085895.issue10744@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

The array notation is useful for arrays inside structs, such as "T{(4)i(2,3)f}".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10744>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:30:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 13:30:30 +0000
Subject: [issue10744] ctypes arrays have incorrect buffer information
	(PEP-3118)
In-Reply-To: <1292882808.9.0.159361940034.issue10744@psf.upfronthosting.co.za>
Message-ID: <1313501430.45.0.000581104499684.issue10744@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10744>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:49:19 2011
From: report at bugs.python.org (David Townshend)
Date: Tue, 16 Aug 2011 13:49:19 +0000
Subject: [issue12760] Add create mode to open()
Message-ID: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>


New submission from David Townshend <aquavitae69 at gmail.com>:

Currently, opening a file with open(file, 'w') overwrites existing files.  It would be useful for open() to raise an error when the file exists.  This proposal is to add a 'c' mode to open, which has the effect to creating a file and opening it for writing, but raising an IOError if it already exists (i.e. the same as os.open(file, os.O_EXCL|os.O_CREAT).

The attached patch implements this, including tests and documentation.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib), Tests
files: open_create.patch
keywords: patch
messages: 142193
nosy: David.Townshend, docs at python
priority: normal
severity: normal
status: open
title: Add create mode to open()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22910/open_create.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Aug 16 15:57:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 13:57:33 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313503053.81.0.529575257958.issue12760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm not sure that O_EXCL is portable (exist on all platforms) because Python source code uses "#ifdef O_EXCL".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Aug 16 16:01:02 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Aug 2011 14:01:02 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313503262.58.0.0253499520071.issue12326@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/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 16:21:05 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Aug 2011 14:21:05 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313504465.88.0.704976070989.issue12326@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@Sandro:

>> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

>Luckily that has just been reverted.

No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015

On Debian Wheezy and Ubuntu 11.10:

$ python2.7 -c 'import sys; print sys.platform'
linux2
$ python3.2 -c 'import sys; print(sys.platform)'
linux2

oneiric$ uname -a
Linux resist 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
wheezy$ uname -a
Linux chemistry 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux

I agree with MvL that Python 3.3 should set sys.platform to 'linux' and all stable releases should be patched to return 'linux2' on MACHDEP='linux3' systems.  configure.in already special cases cygwin* and darwin* to the major-version-number-less platform string, so this doesn't seem like much of a stretch to me for linux.  Since applications/libraries that already test against literal sys.platform values will be broken no matter what we do (except perhaps retain 'linux2' for perpetuity, which doesn't seem like a good idea), I think we should make a clean break from the major version number in Python 3.3 and keep backward compatibility for released Pythons.  Seems like the least worst option to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 16:28:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 16 Aug 2011 14:28:35 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313504465.88.0.704976070989.issue12326@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj0t12Z0sTW1B=xFdxLfXPF5vrKZmzG+xOT0JHpZZHFGkw@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Aug 16, 2011 at 16:21, Barry A. Warsaw <report at bugs.python.org> wrote:
>
> Barry A. Warsaw <barry at python.org> added the comment:
>
> @Sandro:
>
>>> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.
>
>>Luckily that has just been reverted.
>
> No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015
>
> On Debian Wheezy and Ubuntu 11.10:
>
> $ python2.7 -c 'import sys; print sys.platform'
> linux2
> $ python3.2 -c 'import sys; print(sys.platform)'
> linux2

that's because you're on wheezy, that has 2.7.2-3, while the version
which has the change reverted is -4 (still not transition to testing,
since outdated on kbsd-i386)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 16:43:49 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Aug 2011 14:43:49 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <CAPdtAj0t12Z0sTW1B=xFdxLfXPF5vrKZmzG+xOT0JHpZZHFGkw@mail.gmail.com>
Message-ID: <20110816104342.69e6bd36@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 16, 2011, at 02:28 PM, Sandro Tosi wrote:

>that's because you're on wheezy, that has 2.7.2-3, while the version
>which has the change reverted is -4 (still not transition to testing,
>since outdated on kbsd-i386)

I think it's back in -5 though.

$ apt-cache show python2.7 | grep Version
Version: 2.7.2-5

(On Ubuntu)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 16:53:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 14:53:24 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313506404.82.0.925395838331.issue12760@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this should be brought up on python-ideas or python-dev.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Aug 16 17:13:50 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 16 Aug 2011 15:13:50 +0000
Subject: [issue12740] Add struct.Struct.nmemb
In-Reply-To: <1313148807.6.0.39228067291.issue12740@psf.upfronthosting.co.za>
Message-ID: <1313507630.85.0.330434496915.issue12740@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Stefan, it is a constructed failure (I hacked the unit test to break it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12740>
_______________________________________

From report at bugs.python.org  Tue Aug 16 17:37:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 16 Aug 2011 15:37:06 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313509026.46.0.128827885643.issue12760@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

See also issue 12105.
A couple downsides:
- O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on Windows?)
- O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up adding all other commonly-used flags, which are really OS-specific

Furthermore, you can achieve the same thing with:
os.fdopen(os.open('/etc/fstab', os.O_WRONLY|os.O_CLOEXEC|os.O_CREAT))
it's more verbose, though.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Aug 16 17:43:21 2011
From: report at bugs.python.org (David Townshend)
Date: Tue, 16 Aug 2011 15:43:21 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313509401.21.0.325489956823.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

It was discussed on python-ideas, but the subject of the thread was actually on shutils.move so it was not really discussed much. I will repost this idea separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Tue Aug 16 17:50:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Aug 2011 15:50:47 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1313509847.16.0.536944875347.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> FWIW there are still unnecessary escapes before '+' and '.', and
> possibly '-'

This is IMO cosmetic and not as ?important? as the duplicate characters already implied by the character class.  Feel free to change it.

> Why can't pipes.quote can't be moved to shlex.quote verbatim as I
> originally proposed?

I took the opportunity of changing some convoluted code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Tue Aug 16 17:54:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Aug 2011 15:54:15 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1313510055.69.0.464013905409.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> FWIW there are still unnecessary escapes before '+' and '.', and
> possibly '-'

This is IMO cosmetic and not as ?important? as the duplicate characters already implied by the character class.  Feel free to change it.

> Why can't pipes.quote can't be moved to shlex.quote verbatim as I
> originally proposed?

I took the opportunity of changing some convoluted code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Tue Aug 16 18:03:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Aug 2011 16:03:54 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <E1QtM7N-0007ox-41@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d4438001069 by Ezio Melotti in branch 'default':
#9723: refactor regex.
http://hg.python.org/cpython/rev/5d4438001069

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9723>
_______________________________________

From report at bugs.python.org  Tue Aug 16 18:41:41 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 16 Aug 2011 16:41:41 +0000
Subject: [issue12761] Typo in Doc/license.rst
Message-ID: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

"The zlib extension is built using an included copy of the zlib sources unless the zlib version found on the system is too old to be used for the build"

I believe it should be "if" rather than "unless".

----------
messages: 142205
nosy: jwilk
priority: normal
severity: normal
status: open
title: Typo in Doc/license.rst
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:03:21 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 16 Aug 2011 17:03:21 +0000
Subject: [issue12181] SIGBUS error on OpenBSD (sparc64)
In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za>
Message-ID: <1313514201.99.0.330076779932.issue12181@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,
this is the patch in OpenBSD.

Source: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Modules_selectmodule_c

Could be usefull to work together and advance on this problem.
Thanks a lot.

Remi.

----------
Added file: http://bugs.python.org/file22911/patch-Modules_selectmodule_c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12181>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:05:03 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Tue, 16 Aug 2011 17:05:03 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313514303.01.0.0310693611276.issue12761@psf.upfronthosting.co.za>


Changes by Gennadiy Zlobin <gennad.zlobin at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:09:06 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 16 Aug 2011 17:09:06 +0000
Subject: [issue12762] EnvironmentError_str contributes to unportable code
Message-ID: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

It is a surprisingly common error in 3rd party code to write something like this:

  try:
      eggs()
  except OSError, e:
      if e.errno == 17:
         ham()

This is wrong, because according to POSIX[0], ?only [?] symbolic names should be used in programs, since the actual value of the error number is unspecified.?

I was wondering why Python programmers keep writing such unportable code - e.g. I've never seen C code that would compare errno variable with a hardcoded integer. I came into conclution that the Python interpreter itself is (partially) to blame. Currently exception message generated from errno looks like this:

"[Errno 2] No such file or directory: '/punt'"

It would be better if the message was:

"[ENOENT] No such file or directory: '/punt'"

or, if the above is too hard to implement, even:

"No such file or directory: '/punt'"

----------
messages: 142207
nosy: jwilk
priority: normal
severity: normal
status: open
title: EnvironmentError_str contributes to unportable code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:09:45 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 16 Aug 2011 17:09:45 +0000
Subject: [issue12762] EnvironmentError_str contributes to unportable code
In-Reply-To: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>
Message-ID: <1313514585.38.0.892557339242.issue12762@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

And the lost footnote is:
[0] http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:26:32 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Tue, 16 Aug 2011 17:26:32 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313515592.82.0.445218032832.issue12761@psf.upfronthosting.co.za>


Changes by Gennadiy Zlobin <gennad.zlobin at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22912/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:58:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 16 Aug 2011 17:58:23 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313517503.54.0.0906087940605.issue12761@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> commit review
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 19:59:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 17:59:04 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
Message-ID: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/1826/steps/test/logs/stdio

======================================================================
ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_posix.py", line 863, in test_get_and_set_scheduler_and_param
    init = posix.sched_getscheduler(1)
OSError: [Errno 3] No such process

----------
assignee: benjamin.peterson
components: Library (Lib), Tests
messages: 142209
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: test_posix failure on OpenIndiana
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12763>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:06:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 18:06:45 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1313518005.44.0.398065169887.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file22913/524e47d8b878.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:06:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 18:06:51 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
In-Reply-To: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>
Message-ID: <1313518011.84.0.724653785164.issue12763@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12763>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:08:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 18:08:56 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1313518136.48.0.938081329817.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch with latest changes from the PEP. The implementation is now complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:10:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Aug 2011 18:10:42 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <E1QtO65-00042l-59@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 80ac94ad381e by Sandro Tosi in branch '2.7':
#12761: fix wording of zlib license section
http://hg.python.org/cpython/rev/80ac94ad381e

New changeset 16a02530fd81 by Sandro Tosi in branch '3.2':
#12761: fix wording of zlib license section
http://hg.python.org/cpython/rev/16a02530fd81

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:13:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Aug 2011 18:13:13 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313518393.5.0.794128326606.issue12672@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You are right, I suggested deleting too much. The first half of the sentence is needed to define 'type methods', which is used several more times and is the title of the next section. We need to keep "These C functions are called ?type methods?." In the context of the preceding sentence and later usages, I think this is enough.

The second half of the sentence is intended to refine the definition by contrast, but it fails to do so since we cannot agree on what the contrast is. Since none of the interpretations make complete sense and since 'object methods' is not used again, making its definition irrelevant, I suggest deleting this part: "to distinguish them from things like [].append (which we call ?object methods?).".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:13:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 16 Aug 2011 18:13:47 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313518427.39.0.6089540662.issue12761@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Jakub for the report and Gennadiy for the patch (that I applied on all the active braches).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:16:49 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 16 Aug 2011 18:16:49 +0000
Subject: [issue12756] datetime.datetime.utcnow should return a UTC timestamp
In-Reply-To: <1313477575.0.0.856648078618.issue12756@psf.upfronthosting.co.za>
Message-ID: <1313518609.06.0.322121064803.issue12756@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is for backwards-compatibility as the UTC object did not come into existence until (I believe) Python 2.7. The docs for utcnow() explicitly state that if you want a timezone-aware UTC datetime object that you should use now() w/ the UTC object passed in.

Now if you would like to have a keyword argument for utcnow() to cause it to return a UTC object (e.g., utcnow(aware=True)), that may be a patch that  could get accepted as it doesn't break backwards-compatibility if you leave the argument out.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12756>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:21:52 2011
From: report at bugs.python.org (jan matejek)
Date: Tue, 16 Aug 2011 18:21:52 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1313518912.35.0.637408824702.issue1731717@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

please check my logic here, but the patched code seems to throw away perfectly valid return codes:
in wait(), self._handle_exitstatus(sts) gets called unconditionally, and it resets self.returncode also unconditionally.
now, if a _cleanup() already did _internal_poll and set self.returncode that way, it is lost when wait() catches the ECHILD, in the one place where it actually matters, by setting sts=0 for the _handle_exitstatus call

IMHO it could be fixed by moving _handle_exitstatus to the try: section, and returning "self.returncode or 0" or something like that

----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Tue Aug 16 20:50:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 16 Aug 2011 18:50:30 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313520630.44.0.508535655346.issue11564@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 16 21:20:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 16 Aug 2011 19:20:01 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313522401.04.0.218441687324.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

pickle64.patch applies cleanly to 3.2, but not 3.3. I've attached an
adapted version that applies cleanly to 3.3.

----------
Added file: http://bugs.python.org/file22914/pickle64-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:20:33 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 16 Aug 2011 20:20:33 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1313526033.28.0.831818556644.issue12555@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,
I have tested on OpenBSD -current, and it seems to work fine:

$ ./python -E -bb Lib/test/test_mmap.py          
test_access_parameter (__main__.MmapTests) ... ok
test_anonymous (__main__.MmapTests) ... ok
test_bad_file_desc (__main__.MmapTests) ... ok
test_basic (__main__.MmapTests) ... ok
test_context_manager (__main__.MmapTests) ... ok
test_context_manager_exception (__main__.MmapTests) ... ok
test_double_close (__main__.MmapTests) ... ok
test_entire_file (__main__.MmapTests) ... ok
test_error (__main__.MmapTests) ... ok
test_extended_getslice (__main__.MmapTests) ... ok
test_extended_set_del_slice (__main__.MmapTests) ... ok
test_find_end (__main__.MmapTests) ... ok
test_io_methods (__main__.MmapTests) ... ok
test_length_0_large_offset (__main__.MmapTests) ... ok
test_length_0_offset (__main__.MmapTests) ... ok
test_move (__main__.MmapTests) ... ok
test_non_ascii_byte (__main__.MmapTests) ... ok
test_offset (__main__.MmapTests) ... ok
test_prot_readonly (__main__.MmapTests) ... ok
test_read_all (__main__.MmapTests) ... ok
test_read_invalid_arg (__main__.MmapTests) ... ok
test_rfind (__main__.MmapTests) ... ok
test_subclass (__main__.MmapTests) ... ok
test_tougher_find (__main__.MmapTests) ... ok
test_around_2GB (__main__.LargeMmapTests) ... ok
test_around_4GB (__main__.LargeMmapTests) ... ok
test_large_filesize (__main__.LargeMmapTests) ... ok
test_large_offset (__main__.LargeMmapTests) ... ok

----------------------------------------------------------------------
Ran 28 tests in 0.141s

OK
$ ./python -E -bb Lib/test/test_exceptions.py
...........................
----------------------------------------------------------------------
Ran 27 tests in 0.026s

OK
$ ./python -E -bb Lib/test/test_pep3151.py
test_blockingioerror (__main__.AttributesTest) ... ok
test_errno_translation (__main__.AttributesTest) ... skipped 'Windows-specific test'
test_posix_error (__main__.AttributesTest) ... ok
test_windows_error (__main__.AttributesTest) ... ok
test_builtin_errors (__main__.HierarchyTest) ... ok
test_errno_mapping (__main__.HierarchyTest) ... ok
test_ioerror_subclass_mapping (__main__.HierarchyTest) ... ok
test_select_error (__main__.HierarchyTest) ... ok
test_socket_errors (__main__.HierarchyTest) ... ok

----------------------------------------------------------------------
Ran 9 tests in 0.001s

OK (skipped=1)


Don't hesitate to indicate me if you need more tests, or if I did something wrong.

Cheers,
Remi.

----------
nosy: +rpointel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:21:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Aug 2011 20:21:57 +0000
Subject: [issue12764] segfault in ctypes.Struct with bad _fields_
Message-ID: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This crashes on python 3.3::

   class S(ctypes.Structure):
       _fields_ = [(b'x', ctypes.c_int)]

This also crashes on python 2.7::

   class S(ctypes.Structure):
       _fields_ = [(u'x\xe9', ctypes.c_int)]

The cause is the same: in Modules/_ctypes/stgdict.c, the assignment 
    fieldname = _PyUnicode_AsString(name);
does not check for errors.

----------
components: ctypes
keywords: easy
messages: 142218
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: segfault in ctypes.Struct with bad _fields_
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12764>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:23:10 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 16 Aug 2011 20:23:10 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313526190.95.0.939425704274.issue12326@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Another datapoint:

For Fedora 16, I haven't done any downstream patching (so far), because we hadn't run into any downstream problems.

I did some digging into why we're _not_ experiencing issues.

Currently for Fedora 16, we're shipping kernel-3.0 with python-2.7.2-4.fc16.x86_64 and python is reporting:

  $ python -c"import sys; print(sys.platform)"
  linux2

I investigated why we have this discrepancy:  "uname" with the build environment for that RPM happens to be reporting a kernel-2*, whereas we're shipping a kernel-3*:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=3187563

What's happening here is that although the chroot that the build was done in [1] has:
  kernel-3.0-0.rc6.git0.1.fc16.x86_64.rpm

running "uname" in the chroot environment is reporting the kernel that's actually running, outside the chroot, which was:
  2.6.32
and thus we have:
  checking MACHDEP... linux2
within the build log [2]

So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( )

Hope this is helpful

[1] http://koji.fedoraproject.org/koji/rpmlist?buildrootID=1096117%20&start=50&order=nvr&type=component
[2] http://kojipkgs.fedoraproject.org/packages/python/2.7.2/4.fc16/data/logs/x86_64/build.log

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:33:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 20:33:36 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
Message-ID: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x/builds/789/steps/test/logs/stdio

----------
assignee: eric.araujo
components: Library (Lib), Tests
messages: 142220
nosy: eric.araujo, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_packaging failure under Snow Leopard
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:35:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 20:35:12 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313526912.48.0.0290139710603.issue12765@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

[309/358/1] test_packaging
[70190 refs]
test_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok
test_show_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok
test_skip_build (packaging.tests.test_command_bdist.BuildTestCase) ... ok
test_finalize_options (packaging.tests.test_command_bdist_dumb.BuildDumbTestCase) ... ok
test_simple_built (packaging.tests.test_command_bdist_dumb.BuildDumbTestCase) ... copying build/lib/foo.py -> build/bdist.macosx-10.4-x86_64/dumb/usr/local/lib/python3.3/site-packages
ok
test_minimal (packaging.tests.test_command_bdist_msi.BDistMSITestCase) ... skipped 'runs only on win32'
test_get_exe_bytes (packaging.tests.test_command_bdist_wininst.BuildWinInstTestCase) ... ok
test_finalize_options (packaging.tests.test_command_build.BuildTestCase) ... ok
test_build_libraries (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok
test_check_library_dist (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok
test_finalize_options (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok
test_get_source_files (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok
test_run (packaging.tests.test_command_build_clib.BuildCLibTestCase) ... ok
test_build_ext (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_compiler_option (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_deployment_target_default (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_deployment_target_higher_ok (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_deployment_target_too_low (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_ext_fullpath (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_finalize_options (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_get_outputs (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_get_source_files (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_optional_extension (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_solaris_enable_shared (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_user_site (packaging.tests.test_command_build_ext.BuildExtTestCase) ... ok
test_dont_write_bytecode (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok
test_empty_package_dir (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok
test_package_data (packaging.tests.test_command_build_py.BuildPyTestCase) ... ok
test_build (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok
test_default_settings (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok
test_version_int (packaging.tests.test_command_build_scripts.BuildScriptsTestCase) ... ok
test_check_all (packaging.tests.test_command_check.CheckTestCase) ... ok
test_check_hooks (packaging.tests.test_command_check.CheckTestCase) ... ok
test_check_metadata (packaging.tests.test_command_check.CheckTestCase) ... ok
test_check_metadata_1_2 (packaging.tests.test_command_check.CheckTestCase) ... ok
test_check_restructuredtext (packaging.tests.test_command_check.CheckTestCase) ... skipped 'requires docutils'
test_warn (packaging.tests.test_command_check.CheckTestCase) ... ok
test_simple_run (packaging.tests.test_command_clean.cleanTestCase) ... ok
test_dump_options (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_ensure_dirname (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_ensure_filename (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_ensure_string (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_ensure_string_list (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_make_file (packaging.tests.test_command_cmd.CommandTestCase) ... ok
test_clean (packaging.tests.test_command_config.ConfigTestCase) ... ok
test_dump_file (packaging.tests.test_command_config.ConfigTestCase) ... ok
test_finalize_options (packaging.tests.test_command_config.ConfigTestCase) ... ok
test_search_cpp (packaging.tests.test_command_config.ConfigTestCase) ... ok
test_simple_run (packaging.tests.test_command_install_data.InstallDataTestCase) ... ok
test_finalize_options (packaging.tests.test_command_install_dist.InstallTestCase) ... ok
test_handle_extra_path (packaging.tests.test_command_install_dist.InstallTestCase) ... ok
test_home_installation_scheme (packaging.tests.test_command_install_dist.InstallTestCase) ... ok
test_old_record (packaging.tests.test_command_install_dist.InstallTestCase) ... ok
test_user_site (packaging.tests.test_command_install_dist.InstallTestCase) ... ok
test_empty_install (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok
test_installer (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok
test_no_record (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok
test_record (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok
test_requested (packaging.tests.test_command_install_distinfo.InstallDistinfoTestCase) ... ok
test_simple_run (packaging.tests.test_command_install_headers.InstallHeadersTestCase) ... ok
test_byte_compile (packaging.tests.test_command_install_lib.InstallLibTestCase) ... ok
test_dont_write_bytecode (packaging.tests.test_command_install_lib.InstallLibTestCase) ... ok
test_finalize_options (packaging.tests.test_command_install_lib.InstallLibTestCase) ... ok
test_get_inputs (packaging.tests.test_command_install_lib.InstallLibTestCase) ... ok
test_get_outputs (packaging.tests.test_command_install_lib.InstallLibTestCase) ... ok
test_default_settings (packaging.tests.test_command_install_scripts.InstallScriptsTestCase) ... ok
test_installation (packaging.tests.test_command_install_scripts.InstallScriptsTestCase) ... copying /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmppspwto/script1.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmpjw_97p
copying /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmppspwto/script2.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmpjw_97p
copying /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmppspwto/shell.sh -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpk4t76t/tmpjw_97p
ok
test_create_pypirc (packaging.tests.test_command_register.RegisterTestCase) ... ok
test_password_not_in_file (packaging.tests.test_command_register.RegisterTestCase) ... ok
test_password_reset (packaging.tests.test_command_register.RegisterTestCase) ... ok
test_register_pep345 (packaging.tests.test_command_register.RegisterTestCase) ... ok
test_registration (packaging.tests.test_command_register.RegisterTestCase) ... ok
test_strict (packaging.tests.test_command_register.RegisterTestCase) ... skipped 'needs docutils'
test_add_defaults (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_finalize_options (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_get_file_list (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_make_distribution (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_make_distribution_owner_group (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_manifest_builder (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_manifest_marker (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_manual_manifest (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_metadata_check_option (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_prune_file_list (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_show_formats (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_template (packaging.tests.test_command_sdist.SDistTestCase) ... ok
test_builds_before_running_tests (packaging.tests.test_command_test.TestTest) ... ok
test_calls_discover (packaging.tests.test_command_test.TestTest) ... ok
test_checks_requires (packaging.tests.test_command_test.TestTest) ... ok
test_custom_runner (packaging.tests.test_command_test.TestTest) ... ok
test_gets_unittest_discovery (packaging.tests.test_command_test.TestTest) ... ok
test_runs_unittest (packaging.tests.test_command_test.TestTest) ... ok
test_finalize_options (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_finalize_options_unsigned_identity_raises_exception (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_saved_password (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_upload (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_upload_docs (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_upload_without_files_raises_exception (packaging.tests.test_command_upload.UploadTestCase) ... ok
test_checks_index_html_presence (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_checks_upload_dir (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_default_uploaddir (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_default_uploaddir_looks_for_doc_also (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_handling_response (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_https_connection (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_reads_pypirc_data (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_show_response (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_upload (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_zip_dir (packaging.tests.test_command_upload_docs.UploadDocsTestCase) ... ok
test_customize_compiler (packaging.tests.test_compiler.CompilerTestCase) ... ok
test_gen_lib_options (packaging.tests.test_compiler.CompilerTestCase) ... ok
test_config (packaging.tests.test_config.ConfigTestCase) ... ok
test_metadata_requires_description_files (packaging.tests.test_config.ConfigTestCase) ... ok
test_metadata_requires_description_files_missing (packaging.tests.test_config.ConfigTestCase) ... ok
test_missing_setup_hook_warns (packaging.tests.test_config.ConfigTestCase) ... ok
test_multiline_description_file (packaging.tests.test_config.ConfigTestCase) ... ok
test_multiple_description_file (packaging.tests.test_config.ConfigTestCase) ... ok
test_multiple_setup_hooks (packaging.tests.test_config.ConfigTestCase) ... ok
test_parse_extensions_in_config (packaging.tests.test_config.ConfigTestCase) ... ok
test_project_setup_hook_works (packaging.tests.test_config.ConfigTestCase) ... ok
test_sub_commands (packaging.tests.test_config.ConfigTestCase) ... ok
test_ask (packaging.tests.test_create.CreateTestCase) ... ok
test_ask_yn (packaging.tests.test_create.CreateTestCase) ... ok
test_convert_setup_py_to_cfg (packaging.tests.test_create.CreateTestCase) ... ok
test_convert_setup_py_to_cfg_with_description_in_readme (packaging.tests.test_create.CreateTestCase) ... ok
test_find_files (packaging.tests.test_create.CreateTestCase) ... ok
test_set_multi (packaging.tests.test_create.CreateTestCase) ... ok
test_check_config_h (packaging.tests.test_cygwinccompiler.CygwinCCompilerTestCase) ... ok
test_get_msvcr (packaging.tests.test_cygwinccompiler.CygwinCCompilerTestCase) ... ok
test_final_exemple_glob (packaging.tests.test_database.DataFilesTestCase) ... ok
test_get_file (packaging.tests.test_database.DataFilesTestCase) ... ok
test_glob_in_base (packaging.tests.test_database.DataFilesTestCase) ... ok
test_multiple_match (packaging.tests.test_database.DataFilesTestCase) ... ok
test_recursive_glob (packaging.tests.test_database.DataFilesTestCase) ... ok
test_set_match (packaging.tests.test_database.DataFilesTestCase) ... ok
test_set_match_exclude (packaging.tests.test_database.DataFilesTestCase) ... ok
test_set_match_multiple (packaging.tests.test_database.DataFilesTestCase) ... ok
test_simple_glob (packaging.tests.test_database.DataFilesTestCase) ... ok
test_distinfo_dirname (packaging.tests.test_database.TestDatabase) ... ok
test_get_distribution (packaging.tests.test_database.TestDatabase) ... ok
test_get_distributions (packaging.tests.test_database.TestDatabase) ... FAIL
test_get_file_users (packaging.tests.test_database.TestDatabase) ... ok
test_obsoletes (packaging.tests.test_database.TestDatabase) ... ok
test_provides (packaging.tests.test_database.TestDatabase) ... ok
test_yield_distribution (packaging.tests.test_database.TestDatabase) ... FAIL
test_comparison (packaging.tests.test_database.TestDistribution) ... ok
test_get_distinfo_file (packaging.tests.test_database.TestDistribution) ... ok
test_get_resources_path (packaging.tests.test_database.TestDistribution) ... ok
test_instantiation (packaging.tests.test_database.TestDistribution) ... ok
test_list_distinfo_files (packaging.tests.test_database.TestDistribution) ... ok
test_list_installed_files (packaging.tests.test_database.TestDistribution) ... ok
test_repr (packaging.tests.test_database.TestDistribution) ... ok
test_uses (packaging.tests.test_database.TestDistribution) ... ok
test_comparison (packaging.tests.test_database.TestEggInfoDistribution) ... ok
test_instantiation (packaging.tests.test_database.TestEggInfoDistribution) ... ok
test_list_installed_files (packaging.tests.test_database.TestEggInfoDistribution) ... skipped 'not implemented yet'
test_repr (packaging.tests.test_database.TestEggInfoDistribution) ... ok
test_dependent_dists (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_dependent_dists_egg (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_generate_graph (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_generate_graph_egg (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_graph_bad_version_to_dot (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_graph_disconnected_to_dot (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_graph_to_dot (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_main (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_repr (packaging.tests.test_depgraph.DepGraphTestCase) ... ok
test_bad_attr (packaging.tests.test_dist.DistributionTestCase) ... ok
test_bad_version (packaging.tests.test_dist.DistributionTestCase) ... ok
test_debug_mode (packaging.tests.test_dist.DistributionTestCase) ... ok
test_empty_options (packaging.tests.test_dist.DistributionTestCase) ... ok
test_finalize_options (packaging.tests.test_dist.DistributionTestCase) ... ok
test_find_config_files_disable (packaging.tests.test_dist.DistributionTestCase) ... ok
test_hooks_callable (packaging.tests.test_dist.DistributionTestCase) ... ok
test_hooks_get_run (packaging.tests.test_dist.DistributionTestCase) ... ok
test_hooks_importable (packaging.tests.test_dist.DistributionTestCase) ... ok
test_non_empty_options (packaging.tests.test_dist.DistributionTestCase) ... ok
test_special_hooks_parsing (packaging.tests.test_dist.DistributionTestCase) ... ok
test_write_pkg_file (packaging.tests.test_dist.DistributionTestCase) ... ok
test_custom_pydistutils (packaging.tests.test_dist.MetadataTestCase) ... ok
test_description (packaging.tests.test_dist.MetadataTestCase) ... ok
test_obsoletes_dist (packaging.tests.test_dist.MetadataTestCase) ... ok
test_provides_dist (packaging.tests.test_dist.MetadataTestCase) ... ok
test_read_metadata (packaging.tests.test_dist.MetadataTestCase) ... ok
test_requires_dist (packaging.tests.test_dist.MetadataTestCase) ... ok
test_show_help (packaging.tests.test_dist.MetadataTestCase) ... ok
test_simple_metadata (packaging.tests.test_dist.MetadataTestCase) ... ok
test_conflicts (packaging.tests.test_install.TestInstall) ... ok
test_existing_deps (packaging.tests.test_install.TestInstall) ... ok
test_install_dists_rollback (packaging.tests.test_install.TestInstall) ... ok
test_install_dists_success (packaging.tests.test_install.TestInstall) ... ok
test_install_from_infos_conflict (packaging.tests.test_install.TestInstall) ... ok
test_install_from_infos_install_succes (packaging.tests.test_install.TestInstall) ... ok
test_install_from_infos_remove_rollback (packaging.tests.test_install.TestInstall) ... ok
test_install_from_infos_remove_success (packaging.tests.test_install.TestInstall) ... ok
test_install_permission_denied (packaging.tests.test_install.TestInstall) ... ok
test_installation_unexisting_project (packaging.tests.test_install.TestInstall) ... ok
test_move_files (packaging.tests.test_install.TestInstall) ... ok
test_update_infos (packaging.tests.test_install.TestInstall) ... ok
test_upgrade_existing_deps (packaging.tests.test_install.TestInstall) ... ok
test_default_actions (packaging.tests.test_manifest.ManifestTestCase) ... ok
test_manifest_reader (packaging.tests.test_manifest.ManifestTestCase) ... ok
test_interpret (packaging.tests.test_markers.MarkersTestCase) ... ok
test_best_choice (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_author (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_homepage (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_name (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_name_strict (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_predicates (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_version (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_check_version_strict (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_description (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_instantiation (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_mapping_api (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_metadata_markers (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_metadata_read_write (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_multiple_predicates (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_project_url (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_project_urls (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_versions (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_warnings (packaging.tests.test_metadata.MetadataTestCase) ... ok
test_additional_fixers (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... ok
test_convert_code_only (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... ok
test_doctests_only (packaging.tests.test_mixin2to3.Mixin2to3TestCase) ... ok
test_no_compiler (packaging.tests.test_msvc9compiler.msvc9compilerTestCase) ... skipped 'runs only on win32'
test_reg_class (packaging.tests.test_msvc9compiler.msvc9compilerTestCase) ... skipped 'runs only on win32'
test_remove_visual_c_ref (packaging.tests.test_msvc9compiler.msvc9compilerTestCase) ... skipped 'runs only on win32'
test_comparison (packaging.tests.test_pypi_dist.TestDistInfo) ... ok
test_download (packaging.tests.test_pypi_dist.TestDistInfo) ... ok
test_get_url (packaging.tests.test_pypi_dist.TestDistInfo) ... ok
test_hashname (packaging.tests.test_pypi_dist.TestDistInfo) ... ok
test_unpack (packaging.tests.test_pypi_dist.TestDistInfo) ... ok
test_add_dist (packaging.tests.test_pypi_dist.TestReleaseInfo) ... ok
test_get_infos_from_url (packaging.tests.test_pypi_dist.TestReleaseInfo) ... ok
test_get_unknown_distribution (packaging.tests.test_pypi_dist.TestReleaseInfo) ... ok
test_instantiation (packaging.tests.test_pypi_dist.TestReleaseInfo) ... ok
test_split_archive_name (packaging.tests.test_pypi_dist.TestReleaseInfo) ... ok
test_append (packaging.tests.test_pypi_dist.TestReleasesList) ... ok
test_filter (packaging.tests.test_pypi_dist.TestReleasesList) ... ok
test_get_last (packaging.tests.test_pypi_dist.TestReleasesList) ... ok
test_prefer_final (packaging.tests.test_pypi_dist.TestReleasesList) ... ok
test_prefer_source (packaging.tests.test_pypi_dist.TestReleasesList) ... skipped 'method not implemented yet'
test_records_requests (packaging.tests.test_pypi_server.PyPIServerTest) ... ok
test_serve_static_content (packaging.tests.test_pypi_server.PyPIServerTest) ... ok
test_bad_urls (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_browse_local_files (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_default_link_matcher (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_follow_externals (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_found_links (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_get_link_matcher (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_is_browsable (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_links_priority (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_not_scan_all_links (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_restrict_hosts (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_search_projects (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_simple_link_matcher (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... ok
test_uses_mirrors (packaging.tests.test_pypi_simple.SimpleCrawlerTestCase) ... /Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/packaging/pypi/simple.py:88: ResourceWarning: unclosed <socket.socket object, fd=13, family=2, type=1, proto=6>
  return wrapped(self, *args, **kwargs)
ok
test_get_distributions (packaging.tests.test_pypi_xmlrpc.TestXMLRPCClient) ... ok
test_get_metadata (packaging.tests.test_pypi_xmlrpc.TestXMLRPCClient) ... ok
test_get_releases (packaging.tests.test_pypi_xmlrpc.TestXMLRPCClient) ... ok
test_search_projects (packaging.tests.test_pypi_xmlrpc.TestXMLRPCClient) ... ok
test_search_projects_bad_fields (packaging.tests.test_pypi_xmlrpc.TestXMLRPCClient) ... ok
test_install (packaging.tests.test_run.CoreTestCase) ... ok
test_remove_issue (packaging.tests.test_uninstall.UninstallTestCase) ... copying build/lib/meh/__init__.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpmz9640/tmp7m0cmx/lib/python3.3/site-packages/meh
copying build/lib/meh/meh_utils.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpmz9640/tmp7m0cmx/lib/python3.3/site-packages/meh
copying build/lib/meh/sub/__init__.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpmz9640/tmp7m0cmx/lib/python3.3/site-packages/meh/sub
copying build/lib/meh/sub/meh_utils.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpmz9640/tmp7m0cmx/lib/python3.3/site-packages/meh/sub
ok
test_uninstall (packaging.tests.test_uninstall.UninstallTestCase) ... copying build/lib/foo/__init__.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpz7hfs6/tmpr7yb4_/lib/python3.3/site-packages/foo
copying build/lib/foo/foo_utils.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpz7hfs6/tmpr7yb4_/lib/python3.3/site-packages/foo
copying build/lib/foo/sub/__init__.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpz7hfs6/tmpr7yb4_/lib/python3.3/site-packages/foo/sub
copying build/lib/foo/sub/foo_utils.py -> /var/folders/3M/3MMiDEqmEiGyT5q5zPW31++++TM/-Tmp-/tmpz7hfs6/tmpr7yb4_/lib/python3.3/site-packages/foo/sub
ok
test_uninstall_unknow_distribution (packaging.tests.test_uninstall.UninstallTestCase) ... ok
test_runtime_libdir_option (packaging.tests.test_unixccompiler.UnixCCompilerTestCase) ... ok
test_egginfo_to_distinfo_distutils (packaging.tests.test_util.EggInfoToDistInfoTestCase) ... ok
test_egginfo_to_distinfo_setuptools (packaging.tests.test_util.EggInfoToDistInfoTestCase) ... ok
test_glob_all (packaging.tests.test_util.GlobTestCase) ... ok
test_glob_set_head (packaging.tests.test_util.GlobTestCase) ... ok
test_glob_set_middle (packaging.tests.test_util.GlobTestCase) ... ok
test_glob_set_tail (packaging.tests.test_util.GlobTestCase) ... ok
test_invalid_glob_pattern (packaging.tests.test_util.GlobTestCase) ... ok
test_recursive_glob_head (packaging.tests.test_util.GlobTestCase) ... ok
test_recursive_glob_middle (packaging.tests.test_util.GlobTestCase) ... ok
test_recursive_glob_tail (packaging.tests.test_util.GlobTestCase) ... ok
test_regex_rich_glob (packaging.tests.test_util.GlobTestCase) ... ok
test_simple_glob (packaging.tests.test_util.GlobTestCase) ... ok
test_simple_glob_in_dir (packaging.tests.test_util.GlobTestCase) ... ok
test_egg_info_and_non_setuptools_setup_py_is_setuptools_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_egg_info_dir_and_setup_py_is_setuptools_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_empty_package_is_not_based_on_anything (packaging.tests.test_util.PackagingLibChecks) ... ok
test_get_install_method_with_distutils_pkg (packaging.tests.test_util.PackagingLibChecks) ... ok
test_get_install_method_with_packaging_pkg (packaging.tests.test_util.PackagingLibChecks) ... ok
test_get_install_method_with_setuptools_pkg (packaging.tests.test_util.PackagingLibChecks) ... ok
test_get_install_method_with_unknown_pkg (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_distutils_logs_pkg_info_file_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_distutils_logs_setup_py_text_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_distutils_logs_setup_py_text_not_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_packaging_logs_setup_cfg_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_packaging_logs_setup_cfg_not_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_setuptools_logs_egg_info_dir_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_setuptools_logs_setup_py_text_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_is_setuptools_logs_setup_py_text_not_found (packaging.tests.test_util.PackagingLibChecks) ... ok
test_pkg_info_and_non_distutils_setup_py_is_distutils_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_pkg_info_file_and_setup_py_is_distutils_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_cfg_and_invalid_setup_cfg_is_not_packaging_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_cfg_with_no_metadata_section_is_not_packaging_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_cfg_with_valid_metadata_section_is_packaging_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_py_importing_distutils_is_distutils_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_py_importing_setuptools_is_setuptools_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_py_not_importing_distutils_is_not_distutils_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_setup_py_not_importing_setuptools_is_not_setuptools_based (packaging.tests.test_util.PackagingLibChecks) ... ok
test_cfg_to_args (packaging.tests.test_util.UtilTestCase) ... ok
test_change_root (packaging.tests.test_util.UtilTestCase) ... ok
test_convert_path (packaging.tests.test_util.UtilTestCase) ... ok
test_dont_write_bytecode (packaging.tests.test_util.UtilTestCase) ... ok
test_encode_multipart (packaging.tests.test_util.UtilTestCase) ... ok
test_find_exe_version (packaging.tests.test_util.UtilTestCase) ... ok
test_find_packages (packaging.tests.test_util.UtilTestCase) ... ok
test_get_compiler_versions (packaging.tests.test_util.UtilTestCase) ... ok
test_import_nested_first_time (packaging.tests.test_util.UtilTestCase) ... ok
test_newer (packaging.tests.test_util.UtilTestCase) ... ok
test_resolve_name (packaging.tests.test_util.UtilTestCase) ... ok
test_rfc822_escape (packaging.tests.test_util.UtilTestCase) ... ok
test_run_2to3_on_code (packaging.tests.test_util.UtilTestCase) ... ok
test_run_2to3_on_doctests (packaging.tests.test_util.UtilTestCase) ... ok
test_server_empty_registration (packaging.tests.test_util.UtilTestCase) ... ok
test_server_registration (packaging.tests.test_util.UtilTestCase) ... ok
test_spawn (packaging.tests.test_util.UtilTestCase) ... ok
test_split_quoted (packaging.tests.test_util.UtilTestCase) ... ok
test_strtobool (packaging.tests.test_util.UtilTestCase) ... ok
test_basic_versions (packaging.tests.test_version.VersionTestCase) ... ok
test_comparison (packaging.tests.test_version.VersionTestCase) ... ok
test_from_parts (packaging.tests.test_version.VersionTestCase) ... ok
test_hash (packaging.tests.test_version.VersionTestCase) ... ok
test_huge_version (packaging.tests.test_version.VersionTestCase) ... ok
test_irrational_versions (packaging.tests.test_version.VersionTestCase) ... ok
test_is_final (packaging.tests.test_version.VersionTestCase) ... ok
test_predicate (packaging.tests.test_version.VersionTestCase) ... ok
test_predicate_name (packaging.tests.test_version.VersionTestCase) ... ok
test_repr (packaging.tests.test_version.VersionTestCase) ... ok
test_suggest_normalized_version (packaging.tests.test_version.VersionTestCase) ... ok
test_parse_numdots (packaging.tests.test_version.VersionWhiteBoxTestCase) ... ok

======================================================================
FAIL: test_get_distributions (packaging.tests.test_database.TestDatabase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/packaging/tests/test_database.py", line 320, in test_get_distributions
    self.assertEqual(sorted(found_dists), sorted(fake_dists))
AssertionError: Lists differ: [] != [('babar', '0.1'), ('choxie', ...

Second list contains 4 additional elements.
First extra element 0:
('babar', '0.1')

- []
+ [('babar', '0.1'),
+  ('choxie', '2.0.0.9'),
+  ('grammar', '1.0a4'),
+  ('towel-stuff', '0.1')]

======================================================================
FAIL: test_yield_distribution (packaging.tests.test_database.TestDatabase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/packaging/tests/test_database.py", line 503, in test_yield_distribution
    checkLists(eggs, found)
  File "/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build/Lib/packaging/tests/test_database.py", line 490, in <lambda>
    checkLists = lambda x, y: self.assertEqual(sorted(x), sorted(y))
AssertionError: Lists differ: [('bacon', '0.1'), ('banana', ... != []

First list contains 7 additional elements.
First extra element 0:
('bacon', '0.1')

+ []
- [('bacon', '0.1'),
-  ('banana', '0.4'),
-  ('cheese', '2.0.2'),
-  ('coconuts-aster', '10.3'),
-  ('nut', 'funkyversion'),
-  ('strawberry', '0.6'),
-  ('truffles', '5.0')]

----------------------------------------------------------------------
Ran 332 tests in 39.249s

FAILED (failures=2, skipped=8)
Warning -- os.environ was modified by test_packaging
Warning -- threading._dangling was modified by test_packaging
test test_packaging failed

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Tue Aug 16 22:48:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 20:48:39 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313527719.96.0.686337799751.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code.

I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c.

Copy/paste of the initial message of my issue #12751 (msg142108):
---------------
A lot of code is duplicated in unicodeobject.c to manipulate ("encode/decode") surrogates. Each function has from one to three different implementations. The new decode_ucs4() function adds a new implementation. Attached patch replaces this code by macros.

I think that only the implementations of IS_HIGH_SURROGATE and IS_LOW_SURROGATE are important for speed. ((ch & 0xFFFFFC00UL) == 0xD800) (from decode_ucs4) is *a little bit* faster than (0xD800 <= ch && ch <= 0xDBFF) on my CPU (Atom Z520 @ 1.3 GHz): running test_unicode 4 times takes ~54 sec instead of ~57 sec (-3%).

These 3 macros have to be checked, I wrote the first one:

#define IS_SURROGATE(ch) (((ch) & 0xFFFFF800UL) == 0xD800)
#define IS_HIGH_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xD800)
#define IS_LOW_SURROGATE(ch) (((ch) & 0xFFFFFC00UL) == 0xDC00)

I added cast to Py_UCS4 in COMBINE_SURROGATES to avoid integer overflow if Py_UNICODE is 16 bits (narrow build). It's maybe useless.

#define COMBINE_SURROGATES(ch1, ch2) \
 (((((Py_UCS4)(ch1) & 0x3FF) << 10) | ((Py_UCS4)(ch2) & 0x3FF)) + 0x10000)

HIGH_SURROGATE and LOW_SURROGATE require that their ordinal argument has been preproceed to fit in [0; 0xFFFF]. I added this requirement in the comment of these macros. It would be better to have only one macro to do the two operations, but because "*p++" (dereference and increment) is usually used, I prefer to avoid one unique macro (I don't like passing *p++ in a macro using its argument more than once).

Or we may add a third macro using HIGH_SURROGATE and LOW_SURROGATE.

I rewrote the main loop of PyUnicode_EncodeUTF16() to avoid an useless test on ch2 on narrow build.

I also added a IS_NONBMP macro just because I prefer macro over hardcoded constants.
---------------

----------
Added file: http://bugs.python.org/file22915/unicode_macros.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:07:47 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 21:07:47 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313527719.96.0.686337799751.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4ADC1E.80704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code.
> 
> I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c.

PEP 393 is an optional feature for extension writers. If they don't
need PEP 393 style stable ABIs and want to use the macros, they
should be able to. I'm therefore -1 on making them private.

Regarding separating adding the various surrogate macros and
the next-macros: I don't see a problem with adding both in
Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:12:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 21:12:49 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4E4ADC1E.80704@egenix.com>
Message-ID: <4E4ADD4B.8080205@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> STINNER Victor wrote:
>>
>> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>>
>> I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code.
>>
>> I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c.
> 
> PEP 393 is an optional feature for extension writers. If they don't
> need PEP 393 style stable ABIs and want to use the macros, they
> should be able to. I'm therefore -1 on making them private.

Sorry, I mean PEP 384, not PEP 393. Whether PEP 393 will turn out
to be a workable solution has yet to be seen, but that's a
different subject. In any case, Py_UNICODE and access macros
for PyUnicodeObject are in wide-spread use, so trying to hide
them won't work until we reach Py4k.

> Regarding separating adding the various surrogate macros and
> the next-macros: I don't see a problem with adding both in
> Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:35:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:35:20 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313530520.61.0.483350187757.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py.

----------
Added file: http://bugs.python.org/file22916/linux3-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:36:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:36:16 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313530576.03.0.206582955487.issue10542@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22916/linux3-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:37:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:37:59 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313530679.98.0.931703401747.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py.

----------
Added file: http://bugs.python.org/file22917/linux3-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:38:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:38:09 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313530689.77.0.134165509471.issue10542@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg142225

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:38:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:38:40 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313530720.3.0.125632449705.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

(oops, msg142225 was for issue #12326)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:39:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 21:39:10 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313530750.99.0.424248880426.issue12326@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file22613/linux3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:45:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Aug 2011 21:45:49 +0000
Subject: [issue12730] Python's casemapping functions are incorrect for non-BMP
	chars due to narrow/wide build issues
In-Reply-To: <1313089805.52.0.0622189579022.issue12730@psf.upfronthosting.co.za>
Message-ID: <1313531149.24.0.211722289349.issue12730@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python's casemapping functions are not at all untrustworthy or unreliable. They are entirely deterministic - just limited to the BMP in some builds (in a way that has already been discussed). Changing the title of the issue.

----------
title: Python's casemapping functions are untrustworthy due to narrow/wide build issues -> Python's casemapping functions are incorrect for non-BMP chars due to narrow/wide build issues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12730>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:58:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Aug 2011 21:58:34 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313531914.1.0.41950919777.issue12755@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that Python 2.5 is not supported for bug fixes anymore, so if you truly believe that there is a bug in Python that needs to be fixed, it would be better if you could reproduce it in 2.7.

That said, the kind of information you provided really does suggest that the bug is in your application, and not in Python. Without having the full source of your application, it will be impossible to do anything meaningful about it.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Tue Aug 16 23:59:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Aug 2011 21:59:20 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313531960.45.0.171379272648.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The code review links point to something weird.  Victor, can you upload your patch for review?

My first impression is that your patch does not accomplish much beyond replacing some literal expressions with macros.  What I wanted to achieve with this issue was to enable writing code without #ifdef Py_UNICODE_WIDE branches.  In your patch these branches seem to still be there and in fact it appears that new code is longer than the old one (I am not sure why, but I see more '+' than '-'s in your patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 00:10:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 22:10:11 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313532611.37.0.673492554481.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The code review links point to something weird.

That's because I posted a patch for another issue. It's the patch set 5, not the patch set 6 :-)

Direct link:
http://bugs.python.org/review/10542/patch/3174/9874

> My first impression is that your patch does not accomplish much beyond
> replacing some literal expressions with macros.

Yes, and it avoids the duplication of some code patterns, as explained in my message. I would like to avoid constants in the code. Some macros are *a little bit* faster than the current code.

> What I wanted to achieve with this issue was to enable writing code
> without #ifdef Py_UNICODE_WIDE branches.

Yes, and I think that it's better to split this issue in two steps:

 1- add macros for the surrogates (test, join, ...)
 2- Py_UNICODE_NEXT()

> In your patch these branches seem to still be there
> and in fact it appears that new code is longer than the old one

Yes, the code adds more lines than it removes. Is it a problem? My goal is to have more readable code (easier to maintain).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 00:44:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 22:44:42 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
Message-ID: <1313534682.05.0.56196463174.issue12766@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

>>> class Foo:
...    __slots__ = ['foo']
...    foo = None
... 
>>> x = Foo()
>>> x.foo
>>> x.foo = 5
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Foo' object attribute 'foo' is read-only

----------
components: Interpreter Core
messages: 142232
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: strange interaction between __slots__ and class-level attributes
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 00:46:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Aug 2011 22:46:55 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
In-Reply-To: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>
Message-ID: <E1QtSPN-0002zG-R0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 09f2ddd3d15a by Benjamin Peterson in branch 'default':
some *nixes decided not to call init process 1 (closes #12763)
http://hg.python.org/cpython/rev/09f2ddd3d15a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12763>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:09:33 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 23:09:33 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313534682.05.0.56196463174.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313536173.74.0.884942372339.issue12766@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This sort of thing is true of any slotted class with class attributes:

>>> class X:
...     __slots__ = ()
...     foo = None
... 
>>> X().foo = "hello"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'X' object attribute 'foo' is read-only

I think what needs to happen is the error message needs to be improved in both cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:13:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 23:13:13 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313536173.74.0.884942372339.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313536266.3531.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This sort of thing is true of any slotted class with class attributes:
> 
> >>> class X:
> ...     __slots__ = ()
> ...     foo = None
> ... 
> >>> X().foo = "hello"
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: 'X' object attribute 'foo' is read-only

But that's quite different. In your example, the attribute can't be set
on the instance, while it should be in mine (since 'foo' is amongst the
__slots__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:16:48 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 23:16:48 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313534682.05.0.56196463174.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313536608.32.0.534168910193.issue12766@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

So would you prefer to see

>>> x.foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: foo
>>> x.foo = 5
>>> x.foo
5
?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:20:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 23:20:01 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313536608.32.0.534168910193.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313536674.3531.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So would you prefer to see
> 
> >>> x.foo
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> AttributeError: foo
> >>> x.foo = 5
> >>> x.foo
> 5
> ?

No, I would prefer to see

True
>>> x.foo = 5
>>> x.foo
5

... exactly as in the same class without a __slots__

(the whole point of class attributes being to set default values without
complicating the constructor)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:29:45 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 23:29:45 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313534682.05.0.56196463174.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313537385.33.0.73710514572.issue12766@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm afraid that's not (easily) possible. Using __slots__ implicitly gives classes attributes, so what you are seeing is the effect of toying with that. It's not really possible to pretend there are different attributes on the class than the descriptors. We can:

- Silently override slot descrs with attributes (as currently done).
- Warn or error out on conflicts.
- Just override other class attributes with the descrs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:32:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 23:32:05 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313537385.33.0.73710514572.issue12766@psf.upfronthosting.co.za>
Message-ID: <1313537397.3531.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm afraid that's not (easily) possible. Using __slots__ implicitly
> gives classes attributes, so what you are seeing is the effect of
> toying with that. It's not really possible to pretend there are
> different attributes on the class than the descriptors. We can:
> 
> - Silently override slot descrs with attributes (as currently done).
> - Warn or error out on conflicts.
> - Just override other class attributes with the descrs.

Erroring on conflicts would seem reasonable. If that threatens to break
existing code, at least improving the current error message would be
nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:53:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Aug 2011 23:53:38 +0000
Subject: [issue12766] strange interaction between __slots__ and class-level
	attributes
In-Reply-To: <1313534682.05.0.56196463174.issue12766@psf.upfronthosting.co.za>
Message-ID: <E1QtTRx-0007Wc-0i@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 45b63a8a76c9 by Benjamin Peterson in branch 'default':
complain when a class variable shadows a name in __slots__ (closes #12766)
http://hg.python.org/cpython/rev/45b63a8a76c9

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12766>
_______________________________________

From report at bugs.python.org  Wed Aug 17 01:55:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 23:55:09 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313538909.25.0.666130265171.issue12754@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't know if it would help you, but I wrote a C library offering a simple API and supporting various RNG (cryptographic, hardware, pseudo, ...). It reuses existing libraries like GSL, OpenSSL, glib, gcrypt, etc. It supports UNIX/BSD /dev/*random devices and the Windows CryptGen API. It has many tests and reuses external tools to test the RNG.

I added recently RAND_bytes to the Python ssl module, you may reuse it.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Wed Aug 17 02:00:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 00:00:31 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313539231.32.0.450754688073.issue12754@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"On my laptop, KISS4691 could produce about 110 million random numbers per second (148 millon if inlined), whereas MT19937 produced 118 million random numbers per second."

The problem is that the Python API can only produce one number per call and a function call in Python is really slow (it creates a Python frame). If you want to speed it Python, it would be better to add methods to generate arrays to limit the overhead of Python function calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Wed Aug 17 02:42:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Aug 2011 00:42:02 +0000
Subject: [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313541722.75.0.00986554464106.issue12758@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Return the local time as a floating point number
> expressed in seconds since the epoch.

No.  Seconds since the epoch is neither local nor UTC.  It is just an elapsed number of seconds since an agreed upon time called the "epoch".  

I would say: "Return the current time as a floating point number representing the number of seconds elapsed since the epoch."  Suggestions for a shorter formulation that would not change the meaning are welcome.  Maybe "Return the number of seconds elapsed since the epoch as a floating point number."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12758>
_______________________________________

From report at bugs.python.org  Wed Aug 17 03:00:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Aug 2011 01:00:56 +0000
Subject: [issue12750] datetime.datetime how to correctly attach a timezone to
	an existing naive datetime
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313542856.12.0.640782643332.issue12750@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> i.e. it appears that replace() applies the TZ offset to a naive datetime
> object effectively assuming it is local time rather than un-timezoned
> (which is what the docs imply to me)

I don't understand your issue.  The replace method does not assume anything, it just replaces whatever fields you specify with new values.  You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields.  I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST.  However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Wed Aug 17 03:55:54 2011
From: report at bugs.python.org (Daniel O'Connor)
Date: Wed, 17 Aug 2011 01:55:54 +0000
Subject: [issue12750] datetime.datetime how to correctly attach a timezone to
	an existing naive datetime
In-Reply-To: <1313542856.12.0.640782643332.issue12750@psf.upfronthosting.co.za>
Message-ID: <7F47C978-4DA8-4DC3-B029-20E35204A7CB@dons.net.au>


Daniel O'Connor <darius at dons.net.au> added the comment:

On 17/08/2011, at 10:30, Alexander Belopolsky wrote:
> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
> 
>> i.e. it appears that replace() applies the TZ offset to a naive datetime
>> object effectively assuming it is local time rather than un-timezoned
>> (which is what the docs imply to me)
> 
> I don't understand your issue.  The replace method does not assume anything, it just replaces whatever fields you specify with new values.  You can replace tzinfo just like any other field, year, month, day, etc while preserving the other fields.  I think this is fairly well documented. I think what you are looking for is the astimezone() method which, however may not work well on naive datetime instances simply because a naive instance may be ambiguous in presence of DST.  However, if you start with an aware UTC datetime, you should be able to use astimezone() to convert to any local TZ.

Hmm I see, it would appear the problem lies with strftime().

[ur 10:34] ~ >ipython-2.7 
Python 2.7.2 (default, Aug  6 2011, 23:46:16) 
Type "copyright", "credits" or "license" for more information.
IPython 0.10.2 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [48]: now = datetime.datetime.utcnow()
In [49]: nowtz = now.replace(tzinfo = pytz.utc)
In [50]: nowadl = now.replace(tzinfo = pytz.timezone('Australia/Adelaide'))
In [51]: now
Out[51]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118)
In [52]: nowtz
Out[52]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=<UTC>)
In [53]: nowadl
Out[53]: datetime.datetime(2011, 8, 17, 1, 53, 51, 451118, tzinfo=<DstTzInfo 'Australia/Adelaide' CST+9:30:00 STD>)
In [54]: now.strftime("%F %r %s")
Out[54]: '2011-08-17 01:53:51 AM 1313511831'
In [55]: nowtz.strftime("%F %r %s")
Out[55]: '2011-08-17 01:53:51 AM 1313511831'
In [56]: nowadl.strftime("%F %r %s")
Out[56]: '2011-08-17 01:53:51 AM 1313511831'

Wed 17 Aug 2011 01:54:52 UTC
[ur 11:24] ~ >date +%s
1313546093
[ur 11:24] ~ >date -ujr `date +%s`
Wed 17 Aug 2011 01:54:59 UTC
[ur 11:24] ~ >date -ujr 1313511831
Tue 16 Aug 2011 16:23:51 UTC

i.e. strftime disregards tzinfo and seems to treat the time as LT (I think).

It certainly doesn't behave the way I'd expect after using strftime(3) et al :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Wed Aug 17 04:37:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:37:09 +0000
Subject: [issue12767] document threading.Condition.notify
Message-ID: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User report (Jiachang Xu) from the docs mailing list:

The theading.Condition.notify method has a parameter - n, which isn't documented in the the documentation of the threading module.

1. The parameter should be documented
2. notify() is mentioned multiple times in the docs of threading - perhaps the parameter should be mentioned in more than one place as well
3. The parameter should also be documented in the doc-string of notify in Lib/theading.py - however, this may be a separate issue since currently none of the methods of Condition has docstrings.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142246
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: document threading.Condition.notify
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Wed Aug 17 04:43:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:43:09 +0000
Subject: [issue12768] docstrings for the threading module
Message-ID: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The threading module has very few methods with docstrings. Docstrings should be added to all public methods (contents can be borrowed from the documentation).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142247
nosy: docs at python, eli.bendersky
priority: low
severity: normal
stage: needs patch
status: open
title: docstrings for the threading module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Wed Aug 17 04:43:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:43:45 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313549025.49.0.478611707029.issue12767@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Opened Issue 12768 on the general lack of docstrings in the threading module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Wed Aug 17 05:12:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Aug 2011 03:12:26 +0000
Subject: [issue12750] datetime.strftime('%s') should respect tzinfo
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313550746.49.0.4144872823.issue12750@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> it would appear the problem lies with strftime()

Yes, strftime('%s') ignores tzinfo at the moment.  This is not a bug. Support for '%s' format code is incidental and not documented in Python.

Nevertheless I think this is a good feature request.  I am changing the title to make it more explicit.

----------
components: +Extension Modules
keywords: +easy
stage: committed/rejected -> needs patch
title: datetime.datetime how to correctly attach a timezone to an existing naive datetime -> datetime.strftime('%s') should respect tzinfo
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Wed Aug 17 05:17:00 2011
From: report at bugs.python.org (Daniel O'Connor)
Date: Wed, 17 Aug 2011 03:17:00 +0000
Subject: [issue12750] datetime.strftime('%s') should respect tzinfo
In-Reply-To: <1313550746.49.0.4144872823.issue12750@psf.upfronthosting.co.za>
Message-ID: <8EB898DF-6D93-497F-A68F-10832BB249BB@dons.net.au>


Daniel O'Connor <darius at dons.net.au> added the comment:

On 17/08/2011, at 12:42, Alexander Belopolsky wrote:
> Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:
> 
>> it would appear the problem lies with strftime()
> 
> Yes, strftime('%s') ignores tzinfo at the moment.  This is not a bug. Support for '%s' format code is incidental and not documented in Python.
> 
> Nevertheless I think this is a good feature request.  I am changing the title to make it more explicit.

OK thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Wed Aug 17 05:59:14 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Aug 2011 03:59:14 +0000
Subject: [issue1559549] ImportError needs attributes for module and file name
Message-ID: <1313553554.68.0.646004217152.issue1559549@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have a use for this in my bootstrapping for importlib, so I am assigning this to myself in order to make sure that at least ImportError grows the needed keyboard argument and attribute. I will probably not bother with tweaking import.c, though.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1559549>
_______________________________________

From report at bugs.python.org  Wed Aug 17 06:01:50 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Aug 2011 04:01:50 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1313553710.06.0.306302167058.issue9893@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I like Eric's idea of the README.vim file explaining where to grab the community-maintained files and how to get set up. Anyone care to take a stab at writing the file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Wed Aug 17 06:01:57 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 17 Aug 2011 04:01:57 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1313553717.47.0.748405274957.issue9893@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Wed Aug 17 07:04:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Aug 2011 05:04:07 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313557447.24.0.77234115752.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and Py_UNICODE_JOIN_SURROGATES can be committed without trailing _ in 3.3 and with trailing _ in 2.7/3.2.  They should go in unicodeobject.h and be public in 3.3+.

Regarding the name, it would be fine with me to use PyUNICODE_IS_HIGH_SURROGATE.  Other IS* macros don't use spaces, but JOIN_SURROGATES and other proposed macros (e.g. PUT_NEXT/WRITE_NEXT) do.  Also these macros are not related to any existing API like e.g. isalpha.  I think HIGH/LOW are fine, we can mention lead/trail in the doc.

Regarding the implementation, we could use Victor's one if it's faster and it has no other side effects.

Regarding the other macros:
 * _Py_UNICODE_NEXT and _Py_UNICODE_PUT_NEXT are useful, so once we have agreed about the name they can go in.  They can be private in all the 3 branches and made public in 3.4 if they work well;
 * IS_NONBMP doesn't simplify much the code but makes it more readable.  ICU has U_IS_BMP, but in most of the cases we want to check for non-BMP, so if we add this macro it might be ok to check for non-BMP;
 * I'm not sure HIGH_SURROGATE/LOW_SURROGATE are useful with _Py_UNICODE_NEXT.  If they are they should get a better name because the current one is not clear about what they do.


Unless someone disagrees I'll prepare a patch with PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for unicodeobject.h, using them where necessary, using with Victor implementation and commit it (after a review).

We can think about the rest later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 09:02:29 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 17 Aug 2011 07:02:29 +0000
Subject: [issue12750] datetime.strftime('%s') should respect tzinfo
In-Reply-To: <1313375473.21.0.352014190788.issue12750@psf.upfronthosting.co.za>
Message-ID: <1313564549.88.0.905624591915.issue12750@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12750>
_______________________________________

From report at bugs.python.org  Wed Aug 17 09:27:11 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Wed, 17 Aug 2011 07:27:11 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313566031.7.0.923657447703.issue12755@psf.upfronthosting.co.za>


Chandra Sekhar Reddy <sanch09 at ca.com> added the comment:

Hi,

Thanks for your valuable feedback, 

As per your suggestion I have re-verified the code for the possibility of NULL values, intrestingly I have observed that buffer overrun is happening in our application, where there is a character array declared with size 200 and a string is being copied without considering the null terminating character.

static PyObject	*eError;
char errorString[200];
_snprintf(errorString, 200, "some message content");
PyErr_SetString(eError, errorString);

I am not 100% sure if this may cause the PyObject_Malloc to fail.

Thanks,
-Chandra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Wed Aug 17 09:55:58 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Aug 2011 07:55:58 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313567758.79.0.977251870807.issue12755@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With a buffer overrun anything can happen...  Here, I would recommend PyErr_Format() instead.
But it also may be some other corruption happening before!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Wed Aug 17 11:56:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 09:56:17 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313557447.24.0.77234115752.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4B903D.8090205@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 17/08/2011 07:04, Ezio Melotti a ?crit :
> As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and Py_UNICODE_JOIN_SURROGATES can be committed without trailing _ in 3.3 and with trailing _ in 2.7/3.2.  They should go in unicodeobject.h

For Python 2.7 and 3.2, I would prefer to not touch a public header, and 
so add the macros in unicodeobject.c.

> and be public in 3.3+.

If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros public, 
they will use to substract 0x10000 themself (whereas my macros require 
the ordinal to be preproceed).

>   * _Py_UNICODE_NEXT and _Py_UNICODE_PUT_NEXT are useful, so once we have agreed about the name they can go in.  They can be private in all the 3 branches and made public in 3.4 if they work well;

Note: I don't think that _Py_UNICODE*NEXT should go into Python 2.7 or 3.2.

>   * IS_NONBMP doesn't simplify much the code but makes it more readable.  ICU has U_IS_BMP, but in most of the cases we want to check for non-BMP, so if we add this macro it might be ok to check for non-BMP;

If you want to make it public, it's better to call it PyUNICODE_IS_BMP() 
(check if the argument is in U+0000-U+FFFF).

>   * I'm not sure HIGH_SURROGATE/LOW_SURROGATE are useful with _Py_UNICODE_NEXT.  If they are they should get a better name because the current one is not clear about what they do.

They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit 
wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in 
unicodeobject.c.

> Unless someone disagrees I'll prepare a patch with PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for unicodeobject.h, using them where necessary, using with Victor implementation and commit it (after a review).

Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not 
Py_UNICODE_JOIN_SURROGATES). I used the verb "combine", taken from a 
comment in unicodeobject.c. "combine" is maybe better than "join"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 11:57:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 09:57:31 +0000
Subject: [issue12755] Service application crash in python25!PyObject_Malloc
In-Reply-To: <1313476004.8.0.0440038961742.issue12755@psf.upfronthosting.co.za>
Message-ID: <1313575051.59.0.504965755051.issue12755@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I close this issue because it looks like a bug in your application (you say that there is a least a buffer overrun). If it's really a bug in Python and you use a usecase to reproduce it, please reopen the issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12755>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:07:22 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Aug 2011 10:07:22 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <4E4B903D.8090205@haypocalc.com>
Message-ID: <4E4B92D3.80303@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le 17/08/2011 07:04, Ezio Melotti a ?crit :
>> As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and Py_UNICODE_JOIN_SURROGATES can be committed without trailing _ in 3.3 and with trailing _ in 2.7/3.2.  They should go in unicodeobject.h

Ezio used two different naming schemes in his email. Please always
use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).

> For Python 2.7 and 3.2, I would prefer to not touch a public header, and 
> so add the macros in unicodeobject.c.

Why would you want to touch Python 2.7 at all ?

>> and be public in 3.3+.
> 
> If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros public, 
> they will use to substract 0x10000 themself (whereas my macros require 
> the ordinal to be preproceed).

This can be done by having two definitions of the macros: one set for
UCS2 builds and one for UCS4.

>>   * _Py_UNICODE_NEXT and _Py_UNICODE_PUT_NEXT are useful, so once we have agreed about the name they can go in.  They can be private in all the 3 branches and made public in 3.4 if they work well;
> 
> Note: I don't think that _Py_UNICODE*NEXT should go into Python 2.7 or 3.2.

Certainly not into Python 2.7. Adding macros in patch level releases is
also not such a good idea.

>>   * IS_NONBMP doesn't simplify much the code but makes it more readable.  ICU has U_IS_BMP, but in most of the cases we want to check for non-BMP, so if we add this macro it might be ok to check for non-BMP;
> 
> If you want to make it public, it's better to call it PyUNICODE_IS_BMP() 
> (check if the argument is in U+0000-U+FFFF).

Py_UNICODE_IS_BMP() please.

>>   * I'm not sure HIGH_SURROGATE/LOW_SURROGATE are useful with _Py_UNICODE_NEXT.  If they are they should get a better name because the current one is not clear about what they do.
> 
> They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit 
> wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in 
> unicodeobject.c.
>
>> Unless someone disagrees I'll prepare a patch with PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for unicodeobject.h, using them where necessary, using with Victor implementation and commit it (after a review).
> 
> Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not 
> Py_UNICODE_JOIN_SURROGATES). I used the verb "combine", taken from a 
> comment in unicodeobject.c. "combine" is maybe better than "join"?

No, Py_UNICODE_... please !

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                48 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:08:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Aug 2011 10:08:09 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313575689.69.0.748445535815.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> For Python 2.7 and 3.2, I would prefer to not touch a public header, 
> and so add the macros in unicodeobject.c.

Is there some reason for this?  I think it's better if we have them in the same place rather than renaming and moving them in another file between 3.2 and 3.3.

> If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros 
> public, they will use to substract 0x10000 themself (whereas my 
> macros require the ordinal to be preproceed).

If they turn out to be useful and we find a clearer name we can even make them public in 3.3, but we'll have to see about that.

> Note: I don't think that _Py_UNICODE*NEXT should go into
> Python 2.7 or 3.2.

If they don't it won't be possible to fix #9200 in those branches (unless we decide that the bug shouldn't be fixed there, but I would rather fix it).

> If you want to make it public, it's better to call it 
> PyUNICODE_IS_BMP() (check if the argument is in U+0000-U+FFFF).

Yes, public APIs will follow the naming conventions.  Not sure if it's better to check if it's a BMP char, or if it's not.

> They are still useful for UTF-16 encoders (to UTF-16-LE/BE and 16-bit 
> wchar_t*). We can keep HIGH_SURROGATE and LOW_SURROGATE private in 
> unicodeobject.c.

What are the naming convention for private macros in the same .c file where they are used?  Shouldn't they get at least a trailing _?

> Unless someone disagrees I'll prepare a patch with PyUNICODE_IS_{HIGH_|LOW_|}SURROGATE and Py_UNICODE_JOIN_SURROGATES for unicodeobject.h, using them where necessary, using with Victor implementation and commit it (after a review).

> Cool. I suppose that you mean PyUNICODE_JOIN_SURROGATES (not 
> Py_UNICODE_JOIN_SURROGATES).

All the other macros use PyUNICODE_*.

> I used the verb "combine", taken from a  comment in unicodeobject.c. 
> "combine" is maybe better than "join"?

I like join, it's clear enough and shorter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:15:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 10:15:59 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313575689.69.0.748445535815.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4B94DB.4090601@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah yes, the correct prefix for functions working on Py_UNICODE 
characters/strings is "Py_UNICODE", not "PyUNICODE", sorry.

>> For Python 2.7 and 3.2, I would prefer to not touch a public header,
>> and so add the macros in unicodeobject.c.
>
> Is there some reason for this?

We don't add new features to stable releases.

>> If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros
>> public, they will use to substract 0x10000 themself (whereas my
>> macros require the ordinal to be preproceed).
>
> If they turn out to be useful and we find a clearer name we can even make them public in 3.3, but we'll have to see about that.

I don't think that they are useful outside unicodeobject.c.

>> Note: I don't think that _Py_UNICODE*NEXT should go into
>> Python 2.7 or 3.2.
>
> If they don't it won't be possible to fix #9200 in those branches

I don't think that #9200 is a bug, but more a feature request.

> Not sure if it's better to check if it's a BMP char, or if it's not.

I prefer a shorter name and avoiding double negation: 
!Py_UNICODE_IS_NON_BMP(ch).

> What are the naming convention for private macros in the same .c file where they are used?

Hopefully, there is no convention for private macros :-)

>  Shouldn't they get at least a trailing _?

Nope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:16:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Aug 2011 10:16:42 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313576202.02.0.987512440149.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Ezio used two different naming schemes in his email. Please always
> use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).

Indeed, that was a typo + copy/paste.  I meant to say Py_UNICODE_* and _Py_UNICODE_*.  Sorry about the confusion.

> Why would you want to touch Python 2.7 at all ?
> [...]
> Certainly not into Python 2.7. Adding macros in patch level releases
> is also not such a good idea.

Because it has the bug and we can fix it (the macros will be private so that we don't add any feature).
Also what about 3.2?  Are you saying that we should fix the bug in 3.2/3.3 only and leave 2.x alone or that you don't want the bug to be fixed in all the bug-fix releases (i.e. 2.7/3.2)?
My idea is to fix the bug in 2.7/3.2/3.3 using the macros, but only make them public in 3.3 so that new features are exposed only in 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:22:53 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Aug 2011 10:22:53 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313576202.02.0.987512440149.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4B9677.6040906@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>> Ezio used two different naming schemes in his email. Please always
>> use Py_UNICODE_... or _Py_UNICODE (not PyUNICODE_ or _PyUNICODE_).
> 
> Indeed, that was a typo + copy/paste.  I meant to say Py_UNICODE_* and _Py_UNICODE_*.  Sorry about the confusion.

Good :-)

>> Why would you want to touch Python 2.7 at all ?
>> [...]
>> Certainly not into Python 2.7. Adding macros in patch level releases
>> is also not such a good idea.
> 
> Because it has the bug and we can fix it (the macros will be private so that we don't add any feature).
> Also what about 3.2?  Are you saying that we should fix the bug in 3.2/3.3 only and leave 2.x alone or that you don't want the bug to be fixed in all the bug-fix releases (i.e. 2.7/3.2)?
> My idea is to fix the bug in 2.7/3.2/3.3 using the macros, but only make them public in 3.3 so that new features are exposed only in 3.3.

For bug fixes, you can put the macros straight into unicodeobject.c,
but please leave unicodeobject.h untouched - otherwise people will
mess around with these macros (even if they are private) and users
will start to wonder about linker errors if they use old patch
level releases of Python 2.7/3.2.

Also note that some of these macros change the behavior of Python
- that's good if it fixes a bug (obviously :-)), but bad if it changes
areas that are correctly implemented and then suddenly expose
new behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 12:30:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Aug 2011 10:30:43 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313577043.74.0.265762921074.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> For bug fixes, you can put the macros straight into unicodeobject.c,
> but please leave unicodeobject.h untouched - otherwise people will
> mess around with these macros (even if they are private) and users
> will start to wonder about linker errors if they use old patch
> level releases of Python 2.7/3.2.

OK, so in 2.7/3.2 I'll put them in unicodeobject.c, and in 3.3 I'll move them in unicodeobject.c.

Regarding the name, other macros in unicodeobject.c don't have any prefix, so we can do the same (e.g. IS_SURROGATE) for 2.7/3.2 if that's fine.

> Also note that some of these macros change the behavior of Python
> - that's good if it fixes a bug (obviously :-)), but bad if it
> changes areas that are correctly implemented and then suddenly expose
> new behavior.

After this we can fix #9200 and make narrow builds behave correctly (i.e. like wide ones) with non-BMP chars (at least in some places).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 13:09:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Aug 2011 11:09:12 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313579352.91.0.225034148845.issue12767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

>From a quick look at the code and docs I suspect that 'n' is an internal implementation detail and not meant to be exposed.  Is there an use case for notifying waiters where n!=1 and n!=len(waiters)?  If my speculation is correct it might be a good idea to refactor this so that notify itself does not take an argument but instead both it an notify_all call an explicitly internal routine _notify.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Wed Aug 17 13:18:08 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Aug 2011 11:18:08 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313577043.74.0.265762921074.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4BA36A.7090501@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
>> For bug fixes, you can put the macros straight into unicodeobject.c,
>> but please leave unicodeobject.h untouched - otherwise people will
>> mess around with these macros (even if they are private) and users
>> will start to wonder about linker errors if they use old patch
>> level releases of Python 2.7/3.2.
> 
> OK, so in 2.7/3.2 I'll put them in unicodeobject.c, and in 3.3 I'll move them in unicodeobject.c.
> 
> Regarding the name, other macros in unicodeobject.c don't have any prefix, so we can do the same (e.g. IS_SURROGATE) for 2.7/3.2 if that's fine.

Sure.

>> Also note that some of these macros change the behavior of Python
>> - that's good if it fixes a bug (obviously :-)), but bad if it
>> changes areas that are correctly implemented and then suddenly expose
>> new behavior.
> 
> After this we can fix #9200 and make narrow builds behave correctly (i.e. like wide ones) with non-BMP chars (at least in some places).

Ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 13:21:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 11:21:19 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313580079.08.0.648427432308.issue12767@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

David, while you make a valid point, consider that 'n' is part of the public API of the threading module (although not documented) and it's conceivable that there is existing code "in the wild" using it. To do what you suggest we should maybe go through a normal deprecation process for this argument first?

Adding Antoine as the listed threading expert.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Wed Aug 17 13:42:18 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Aug 2011 11:42:18 +0000
Subject: [issue12757] undefined name in doctest.py
In-Reply-To: <1313479086.68.0.065111934389.issue12757@psf.upfronthosting.co.za>
Message-ID: <1313581338.24.0.567258985304.issue12757@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/issue12757>
_______________________________________

From report at bugs.python.org  Wed Aug 17 13:57:55 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 17 Aug 2011 11:57:55 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313577043.74.0.265762921074.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4BACD3.8030509@trueblade.com>


Eric V. Smith <eric at trueblade.com> added the comment:

On 8/17/2011 6:30 AM, Ezio Melotti wrote:
> OK, so in 2.7/3.2 I'll put them in unicodeobject.c, and in 3.3 I'll move them in unicodeobject.c.

I believe the second file should be unicodeobject.h, correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 14:03:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Aug 2011 12:03:52 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313582632.28.0.821180068094.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 14:17:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 17 Aug 2011 12:17:10 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1313576202.02.0.987512440149.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E4BB144.3040000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Also what about 3.2?  Are you saying that we should fix the bug in
> 3.2/3.3 only and leave 2.x alone or that you don't want the bug to be
> fixed in all the bug-fix releases (i.e. 2.7/3.2)?

Notice that the macros themselves don't fix any bugs. As for the bugs
you apparently want to fix using these macros: they should be considered
on a case-by-case basis. Some of your planned bug fixes may introduce
incompatibilities that rule out fixing them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 14:22:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 12:22:36 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313583756.93.0.465453510204.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> OK, so in 2.7/3.2 I'll put them in unicodeobject.c

It looks like #9200 only needs Py_UNICODE_NEXT, which can be implemented without the other Py_UNICODE_*SURROGATE* macros.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Wed Aug 17 14:36:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Aug 2011 12:36:07 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313584567.25.0.58501169057.issue12767@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Good point.  Probably, then, we should just put a comment in the code that 'n' is an internal implementation detail and leave it at that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Wed Aug 17 14:39:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 17 Aug 2011 12:39:27 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313526190.95.0.939425704274.issue12326@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3GoEaVZV7-RRd9M=NhF3X79jD94iPe-5pCJwrzf+4j5g@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

2011/8/16 Dave Malcolm <report at bugs.python.org>:
> So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( )
>
> Hope this is helpful

Thanks Dave.
To me, this sounds like yet another reason not to use sys.platform (C) (TM) (R).

> My patch version 2

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:04:06 2011
From: report at bugs.python.org (xavierd)
Date: Wed, 17 Aug 2011 13:04:06 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313586246.02.0.0374856901592.issue12515@psf.upfronthosting.co.za>


xavierd <xdelannoy at cloudmark.com> added the comment:

I also noticed that 'email' modifies the message structure when the header/body separator is missing. And nothing is added to the defect list.
In the attachment, you'll find : 
 - email.patch: this patch add the following error to the defects list :
   - the error 'email.errors.CloseBoundaryNotFoundDefect' when a boundary isn't closed.
   - the error 'email.errors.MissingHeaderBodySeparator' when the header/body isn't found
(patch for python 2.7.2)
 - orig.email: a email without a header/body separator

----------
Added file: http://bugs.python.org/file22918/email.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12515>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:04:20 2011
From: report at bugs.python.org (xavierd)
Date: Wed, 17 Aug 2011 13:04:20 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313586260.23.0.254769263597.issue12515@psf.upfronthosting.co.za>


Changes by xavierd <xdelannoy at cloudmark.com>:


Removed file: http://bugs.python.org/file22887/email.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12515>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:05:43 2011
From: report at bugs.python.org (xavierd)
Date: Wed, 17 Aug 2011 13:05:43 +0000
Subject: [issue12515] email modifies the message structure when the parsed
	email is invalid
In-Reply-To: <1310056642.88.0.39667287194.issue12515@psf.upfronthosting.co.za>
Message-ID: <1313586343.94.0.471731255357.issue12515@psf.upfronthosting.co.za>


Changes by xavierd <xdelannoy at cloudmark.com>:


Added file: http://bugs.python.org/file22919/orig.eml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12515>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:06:12 2011
From: report at bugs.python.org (=?utf-8?q?Rafa=C5=82_Dowgird?=)
Date: Wed, 17 Aug 2011 13:06:12 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
Message-ID: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>


New submission from Rafa? Dowgird <dowgird at gmail.com>:

The ctypes module seems to truncate NUL-containing strings when assigning to structure fields of type c_char*1024. Reproduced on a 2.7.2 compiled from tarball. Script to reproduce attached.

----------
components: ctypes
files: reproduce.py
messages: 142274
nosy: Rafal.Dowgird
priority: normal
severity: normal
status: open
title: String with NUL characters truncated by ctypes when assigning to a char array
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file22920/reproduce.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:07:50 2011
From: report at bugs.python.org (=?utf-8?q?Rafa=C5=82_Dowgird?=)
Date: Wed, 17 Aug 2011 13:07:50 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1313586470.22.0.551962506609.issue12769@psf.upfronthosting.co.za>


Rafa? Dowgird <dowgird at gmail.com> added the comment:

Attaching output of the script. 'x\000y\000' becomes 'x' after assigning to a char array.

----------
Added file: http://bugs.python.org/file22921/output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:16:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 13:16:23 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1313586983.83.0.116425424219.issue12769@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't think that it's a bug, but a feature.

Example:

buffer=ctypes.create_string_buffer(4)
buffer.value='a\0bc'
print("buffer.value=%r" % buffer.value)
print("buffer.raw=%r" % buffer.raw)

displays

buffer.value='a'
buffer.raw='a\x00bc'

Sorry, I don't know how to get the raw value of a c_char array in a structure. You should maybe use another type.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Wed Aug 17 15:19:08 2011
From: report at bugs.python.org (=?utf-8?q?Rafa=C5=82_Dowgird?=)
Date: Wed, 17 Aug 2011 13:19:08 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1313587148.5.0.565698324907.issue12769@psf.upfronthosting.co.za>


Rafa? Dowgird <dowgird at gmail.com> added the comment:

The buffer output of the script suggests that the part after the '\000' has not been copied into the array at all. If that's the case, then the 'raw' output wouldn't print it anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Wed Aug 17 16:39:45 2011
From: report at bugs.python.org (Marcelo)
Date: Wed, 17 Aug 2011 14:39:45 +0000
Subject: [issue12770] Email problem on Windows XP SP3 32bits
Message-ID: <1313591985.48.0.510577538993.issue12770@psf.upfronthosting.co.za>


New submission from Marcelo <dapdapbr at yahoo.com.br>:

I use Emesene 2.11.7 on Windows XP SP3, 32Bits. When I clic on the Email botom, Emesene don?t open my email aconunt in Internet Explorer, or Mozilla Firefox or any other browser.

----------
messages: 142278
nosy: butuntu
priority: normal
severity: normal
status: open
title: Email problem on Windows XP SP3 32bits

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12770>
_______________________________________

From report at bugs.python.org  Wed Aug 17 16:41:37 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 17 Aug 2011 14:41:37 +0000
Subject: [issue12770] Email problem on Windows XP SP3 32bits
In-Reply-To: <1313591985.48.0.510577538993.issue12770@psf.upfronthosting.co.za>
Message-ID: <1313592097.67.0.222376733154.issue12770@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

This is a bug tracker for the Python programming language and interpreter. You should contact Emesene for help with their product.

----------
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12770>
_______________________________________

From report at bugs.python.org  Wed Aug 17 16:50:16 2011
From: report at bugs.python.org (Sturla Molden)
Date: Wed, 17 Aug 2011 14:50:16 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1313592616.66.0.558487940984.issue12754@psf.upfronthosting.co.za>


Sturla Molden <sturla at molden.no> added the comment:

"The problem is that the Python API can only produce one number per call and a function call in Python is really slow (it creates a Python frame). If you want to speed it Python, it would be better to add methods to generate arrays to limit the overhead of Python function calls."


That is why I suggested an option to return a raw buffer (e.g. bytearray or memory_view). 

My experience with NumPy and MATLAB tells me that random numbers are nearly always needed in arrays with scripting languages.

But I cannot focus my thoughts...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Wed Aug 17 16:59:48 2011
From: report at bugs.python.org (Vlada Peric)
Date: Wed, 17 Aug 2011 14:59:48 +0000
Subject: [issue12771] 2to3 -d adds extra whitespace
Message-ID: <1313593187.97.0.649094225681.issue12771@psf.upfronthosting.co.za>


New submission from Vlada Peric <vlada.peric at gmail.com>:

When running 2to3 -d on this doctest (from this file[0] in SymPy):

        >>> class SzUpKet(Ket):
        ...     def _represent_SzOp(self, basis, **options):
        ...         return Matrix([1,0])
        ...

2to3 adds an extra space in the last line. This then raises an error for our automated whitespace tests (and is generally annoying). I haven't seen this happen anywhere else (and SymPy is a big codebase). 

It's really a minor issue, though (I can't set the priority myself, though).

[0] https://github.com/sympy/sympy/blob/master/sympy/physics/quantum/represent.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 142281
nosy: Aaron.Meurer, VPeric
priority: normal
severity: normal
status: open
title: 2to3 -d adds extra whitespace
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12771>
_______________________________________

From report at bugs.python.org  Wed Aug 17 17:04:08 2011
From: report at bugs.python.org (higery)
Date: Wed, 17 Aug 2011 15:04:08 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313593448.14.0.619981026117.issue12394@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file22922/4be1917b2a9e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Wed Aug 17 17:22:51 2011
From: report at bugs.python.org (higery)
Date: Wed, 17 Aug 2011 15:22:51 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313594571.23.0.195225079919.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Current patch has removed old-style scripts support and just retain new-style wrapper scripts generation support. 

Now, it uses only dotted path string to support kind of 'console_scripts' of setuptools, and uses dotted path with a 'window' or 'win' option to support kind of 'gui_scripts' of setuptools.

Here is a simple example to show these usecases, in setup.cfg:

scripts = 
    foo = a.b.c.main
    foowin = a.b.c.winmain -window

Then a executable 'foo' file will be generated for Posix platform, console programm 'foo.exe' and window programm 'foowin.exe' files are generated for Windows platform. The 'window' option is just used to show that this entry is a kind of 'gui_scripts' entry to support gui programm wrappers generation.

Now, there is an issue to consider when we make this change:

'scripts' belongs to the 'files' section in setup.cfg, it's still ok now to place it in 'files'? Still take the above example to say, 'foo=a.b.c.main' and 'foowin=a.b.c.winmain -window' are just dotted path strings to show main executable entry function, they are not existed files and are only just used to generate files.

In addition, there are two kinds of configuration files supported in packaing - setup.py and setup.cfg, and both of them can exist in a project at the same time , and have different purposes for usage. setup.cfg just offers users a way to change the default configuration, so I think we should write the dotted strings in setup.py, do anyone agree with me? Then the above writting way of 'scripts' maybe changed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Wed Aug 17 17:49:38 2011
From: report at bugs.python.org (Nicholas Cole)
Date: Wed, 17 Aug 2011 15:49:38 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1313596178.64.0.141477246019.issue12567@psf.upfronthosting.co.za>


Nicholas Cole <nicholas.cole at gmail.com> added the comment:

There are now several bugs dealing with related issues here.  Are we any closer to a solution to any of them?  The suggested patches look like a good idea - what needs to happen for them to move forward?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Wed Aug 17 18:02:02 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 17 Aug 2011 16:02:02 +0000
Subject: [issue12764] segfault in ctypes.Struct with bad _fields_
In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za>
Message-ID: <1313596922.26.0.485615057287.issue12764@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached patch for 3.3 with unittest

----------
keywords: +patch
nosy: +vladris
Added file: http://bugs.python.org/file22923/issue12764_patch3x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12764>
_______________________________________

From report at bugs.python.org  Wed Aug 17 18:02:39 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 17 Aug 2011 16:02:39 +0000
Subject: [issue12764] segfault in ctypes.Struct with bad _fields_
In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za>
Message-ID: <1313596959.59.0.274448956374.issue12764@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Also patch for 2.7 with unittest. BTW, b"x" works on 2.7.

----------
Added file: http://bugs.python.org/file22924/issue12764_patch2x.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12764>
_______________________________________

From report at bugs.python.org  Wed Aug 17 18:15:03 2011
From: report at bugs.python.org (Miguel de Val Borro)
Date: Wed, 17 Aug 2011 16:15:03 +0000
Subject: [issue12772] fractional day attribute in datetime class
Message-ID: <1313597703.11.0.0103584159949.issue12772@psf.upfronthosting.co.za>


New submission from Miguel de Val Borro <miguel.deval at gmail.com>:

It would be useful to have a fractional day method in datetime.datetime
that returns a float object calculated from the day, hour, minute, second, and microseconds. Fractional days in UTC are often used in science, in particular to record astronomical observations.

----------
messages: 142286
nosy: Miguel.de.Val.Borro
priority: normal
severity: normal
status: open
title: fractional day attribute in datetime class
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12772>
_______________________________________

From report at bugs.python.org  Wed Aug 17 18:32:38 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 17 Aug 2011 16:32:38 +0000
Subject: [issue12773] classes should have mutable docstrings
Message-ID: <1313598758.7.0.99280982801.issue12773@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Apparently docstrings for classes are immutable:

>>> class X:
...     "some doc"
...
>>> X.__doc__
'some doc'
>>> X.__doc__ = "another doc"
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: attribute '__doc__' of 'type' objects is not writable

That is on 3.3, but apparently it's the case all the way back to 2.2.
I mentioned this on python-list and several people indicated that it
should be an unnecessary restriction [1].  I also found that this only impacts classes that do not have a custom metaclass.

Regardless, it looks like this is something that no one has take the time to address but would be nice to have done [2][3].  I found that the type_getset for __doc__ does not have a getter:

http://hg.python.org/cpython/file/default/Objects/typeobject.c#l634

I have attached a patch that adds one and fixes the problem.  "make test" passed after the fix.


[1] http://mail.python.org/pipermail/python-list/2011-June/1274079.html
[2] http://mail.python.org/pipermail/python-ideas/2011-June/010462.html
[3] http://mail.python.org/pipermail/python-ideas/2011-August/011185.html

----------
components: Interpreter Core
files: mutable_class_docstrings.diff
keywords: patch
messages: 142287
nosy: eric.snow, michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: classes should have mutable docstrings
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22925/mutable_class_docstrings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12773>
_______________________________________

From report at bugs.python.org  Wed Aug 17 19:04:29 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Aug 2011 17:04:29 +0000
Subject: [issue12773] classes should have mutable docstrings
In-Reply-To: <1313598758.7.0.99280982801.issue12773@psf.upfronthosting.co.za>
Message-ID: <E1QtjXY-0002f7-Ar@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ed2511c23dae by Benjamin Peterson in branch 'default':
make __doc__ mutable on heaptypes (closes #12773)
http://hg.python.org/cpython/rev/ed2511c23dae

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12773>
_______________________________________

From report at bugs.python.org  Wed Aug 17 20:35:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 18:35:01 +0000
Subject: [issue12567] curses implementation of Unicode is wrong in Python 3
In-Reply-To: <1310682817.11.0.980195084883.issue12567@psf.upfronthosting.co.za>
Message-ID: <1313606101.34.0.755473865482.issue12567@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> what needs to happen for them to move forward?

I would like a review of curses_unicode.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12567>
_______________________________________

From report at bugs.python.org  Wed Aug 17 20:52:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Aug 2011 18:52:00 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QtlDb-00079U-3d@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 50f1922bc1d5 by Victor Stinner in branch 'default':
Issue #12326: don't test the major version of sys.platform
http://hg.python.org/cpython/rev/50f1922bc1d5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Aug 17 20:56:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Aug 2011 18:56:03 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313607363.9.0.487106156438.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset 50f1922bc1d5 by Victor Stinner in branch 'default':

I will backport the fix to 2.7 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Wed Aug 17 23:06:08 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Aug 2011 21:06:08 +0000
Subject: =?utf-8?q?=5Bissue12748=5D_Problems_using_IDLE_accelerators_with_OS_X_Dvo?=
	=?utf-8?q?rak_-_Qwerty_=E2=8C=98_input_method?=
In-Reply-To: <1313296841.65.0.536180727284.issue12748@psf.upfronthosting.co.za>
Message-ID: <1313615168.26.0.300479984689.issue12748@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

A footnote: I brought this issue up on the Mac Tcl mailing list and it was demonstrated that the problem with mishandling of the menu accelerators with the Dvorak - Qwerty Cmd input method is a general Cocoa Tk problem, and not unique to IDLE or Tkinter.  I've opened a Tk issue for it:

https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&atid=112997

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12748>
_______________________________________

From report at bugs.python.org  Thu Aug 18 00:04:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Aug 2011 22:04:21 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1313618661.89.0.946127810392.issue12720@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the functions should:
- accept both str and bytes for keys and values; when it's an str, encoding it using the FS encoding
- return str for attribute names, using the FS encoding
- return bytes for attribute values, although returning str might be reasonable as well

I also get the following test failures:

======================================================================
FAIL: test_fds (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1579, in test_fds
    self._check_xattrs(getxattr, setxattr, removexattr, listxattr)
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1542, in _check_xattrs
    setxattr(fn, b"user.test", b"bye", os.XATTR_CREATE)
AssertionError: OSError not raised

======================================================================
FAIL: test_lpath (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1564, in test_lpath
    os.llistxattr)
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1542, in _check_xattrs
    setxattr(fn, b"user.test", b"bye", os.XATTR_CREATE)
AssertionError: OSError not raised

======================================================================
FAIL: test_simple (test.test_os.ExtendedAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1560, in test_simple
    os.listxattr)
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 1542, in _check_xattrs
    setxattr(fn, b"user.test", b"bye", os.XATTR_CREATE)
AssertionError: OSError not raised

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Thu Aug 18 00:29:17 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 17 Aug 2011 22:29:17 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1313620157.2.0.952811272981.issue12720@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/issue12720>
_______________________________________

From report at bugs.python.org  Thu Aug 18 00:42:10 2011
From: report at bugs.python.org (Christian)
Date: Wed, 17 Aug 2011 22:42:10 +0000
Subject: [issue10015] Creating a multiproccess.pool.ThreadPool from a child
	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1313620930.61.0.210565534351.issue10015@psf.upfronthosting.co.za>


Christian <brugger.chr at googlemail.com> added the comment:

A workaround would be to call the following in the thread you want to use ThreadPool:

if not hasattr(threading.current_process(), "_children"):
    threading.current_process()._children = weakref.WeakKeyDictionary()

(putting this in Process could be a very simple patch)

----------
nosy: +chris-

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10015>
_______________________________________

From report at bugs.python.org  Thu Aug 18 02:21:17 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 00:21:17 +0000
Subject: [issue12774] Warning -- multiprocessing.process._dangling was
	modified by test_multiprocessing
Message-ID: <1313626877.54.0.853743115284.issue12774@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[188/352] test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing

----------
components: Tests
messages: 142295
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12774>
_______________________________________

From report at bugs.python.org  Thu Aug 18 02:28:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 00:28:03 +0000
Subject: [issue12774] Warning -- multiprocessing.process._dangling was
	modified by test_multiprocessing
In-Reply-To: <1313626877.54.0.853743115284.issue12774@psf.upfronthosting.co.za>
Message-ID: <1313627283.51.0.155264687442.issue12774@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This warning is a regression in 3.2.2 from previous 3.2 releases due to the dangling Thread and Process checks added to 3.2 by 64e35f3bcda5 for Issue12573; the same checks introduce a new warning in 3.2.2 for test_threaded_import which has already been fixed in default but not backported to 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12774>
_______________________________________

From report at bugs.python.org  Thu Aug 18 02:29:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 00:29:32 +0000
Subject: [issue12774] Warning -- multiprocessing.process._dangling was
	modified by test_multiprocessing
In-Reply-To: <1313626877.54.0.853743115284.issue12774@psf.upfronthosting.co.za>
Message-ID: <1313627372.73.0.577437381868.issue12774@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12774>
_______________________________________

From report at bugs.python.org  Thu Aug 18 03:20:27 2011
From: report at bugs.python.org (James Y Knight)
Date: Thu, 18 Aug 2011 01:20:27 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313630427.79.0.0198358341014.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

> I will backport the fix to 2.7 and 3.2.

Uh, wait, so does that mean you're *not* going to do the compatibility-preserving thing and force sys.platform to stay linux2 even when python is built (BUILT! not run!) on a machine where the active kernel is linux 3.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 03:31:04 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Aug 2011 01:31:04 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313630427.79.0.0198358341014.issue12326@psf.upfronthosting.co.za>
Message-ID: <20110817200658.7a9c7129@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 01:20 AM, James Y Knight wrote:

>James Y Knight <foom at users.sourceforge.net> added the comment:
>
>> I will backport the fix to 2.7 and 3.2.
>
>Uh, wait, so does that mean you're *not* going to do the
>compatibility-preserving thing and force sys.platform to stay linux2 even
>when python is built (BUILT! not run!) on a machine where the active kernel
>is linux 3.x?

My question too!  I would say that stable releases should probably not get
this change, but should force sys.platform to linux2 on 3.x kernels.

BTW, does anybody think sys.platform should use a more dynamic approach for
calculating its value?  Well, maybe not necessary if Python 3.3 will just say
'linux'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 04:14:50 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 18 Aug 2011 02:14:50 +0000
Subject: [issue10320] printf %qd is nonstandard
In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>
Message-ID: <1313633690.65.0.476290908476.issue10320@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I agree that this violates C99, but is this actually causing any real world problems with the platforms Python supports?  If so, then we need a test case.  This seems low priority

----------
assignee: theller -> 
nosy: +amaury.forgeotdarc, belopolsky, meador.inge -theller
priority: normal -> low
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10320>
_______________________________________

From report at bugs.python.org  Thu Aug 18 04:25:37 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 18 Aug 2011 02:25:37 +0000
Subject: [issue9651] ctypes crash when writing zerolength string buffer to file
In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za>
Message-ID: <1313634337.6.0.129775268616.issue9651@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Ping.  I think this one is OK to commit.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9651>
_______________________________________

From report at bugs.python.org  Thu Aug 18 04:30:55 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 18 Aug 2011 02:30:55 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313634655.22.0.407945055817.issue12767@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I asked the user who reported this documentation omission what he's using the 'n' argument for. His reply:

    "Yes I am using the n parameter, it is mainly to implement a subclass of Queue that supports "bulk" get and put operations. This enhances the performance of repeated get/put calls when the Queue is created using multiprocessing.Manager."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Thu Aug 18 06:49:46 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Aug 2011 04:49:46 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313642986.96.0.915381826833.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

IIUC the support for setup.py is transitional, i.e. "legacy support", for existing packages transitioning from distutils/setuptools/Distribute to packaging. New features should not rely on the existence of setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 06:54:29 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Aug 2011 04:54:29 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313643269.19.0.79259979729.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

BTW higery, did you use any of the build-scripts functionality I developed in the pythonv branch?

Ref. https://bitbucket.org/vinay.sajip/pythonv/changeset/d2453f281baf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 09:09:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 18 Aug 2011 07:09:49 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1313651389.0.0.265213391291.issue11715@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my netbook and updating to the latest Py3k code, I got a lot of test errors, even after a make distclean and ./configure.

The errors went away after manually tweaking LDFLAGS as Christian describes here:
http://lipyrary.blogspot.com/2011/05/how-to-compile-python-on-ubuntu-1104.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:00:55 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 08:00:55 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
Message-ID: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>


New submission from Daniel Svensson <dsvensson at gmail.com>:

I've noticed problems with the GC in two applications. In one case the application did not respond to SOAP-requests for 9 seconds, every couple of minutes, when it really shouldn't have taken more than 20ms. In another case we had one operation executed by 20 threads that ought to have taken 0.5 seconds, but instead took about 90 seconds.

Both cases were solved by disabling the garbage collector and hunting down possible circular references. Once this was done, the first example went down to its expected 20ms max latency, and the second one to its 0.5s processing time.


Here is a short python script that demonstrates the issue, the JSON file in this case is 1.2GB large:

> import cjson, time, gc

> def read_json_blob():
>   t0 = time.time()
>   fd = file("mytestfile")
>   data = fd.read()
>   fd.close()
>   t1 = time.time()
>   parsed = cjson.decode(data)
>   t2 = time.time()
>   print "read file in %.2fs, parsed json in %.2fs, total of %.2fs" % \
>                                                   (t1-t0, t2-t1, t2-t0)

> read_json_blob()
read file in 10.57s, parsed json in 531.10s, total of 541.67s

> gc.disable()
> read_json_blob()
read file in 0.59s, parsed json in 15.13s, total of 15.72s

> gc.collect()
0

I don't understand how Python can work like this default, at least not without a warning, to me it looks like a joke gone too far. All documentation ought to recommend people to disable the garbage collector at the first sign of performance problems, or the garbage collector problem should be fixed, this the "Documentation" or "Interpreter Core" Components in the ticket classification.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 142305
nosy: docs at python, dsvensson
priority: normal
severity: normal
status: open
title: immense performance problems related to the garbage collector
type: performance
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/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:05:23 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 18 Aug 2011 08:05:23 +0000
Subject: [issue12772] fractional day attribute in datetime class
In-Reply-To: <1313597703.11.0.0103584159949.issue12772@psf.upfronthosting.co.za>
Message-ID: <1313654723.85.0.0990636525884.issue12772@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12772>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:05:48 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 18 Aug 2011 08:05:48 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313654748.45.0.955385372173.issue12775@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:57:58 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 18 Aug 2011 08:57:58 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
Message-ID: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>


New submission from Arnaud Fontaine <arnau at debian.org>:

When specifying a function to be called in type keyword argument of add_argument(), the function is actually called twice (when a default value is set and then when the argument is given).

While this may not be a problem in most cases (such as converting to an int for example), it is an issue for example when trying to open a file whose filename is given as a default value but is not accessible for whatever reason because the first call will fail whereas only the second should be done. I know this may sound like a twisted example but the type function should not be called twice anyhow IMHO.

I tested with Python 2.7 and 3.2 from Debian packages only but the bug seems to be present in py3k and 2.7 hg branches as well.

I have attached a small script showing the issue and two patches (for 2.7 and tip (py3k) hg branches), including an additional test case. All argparse tests pass well with 2.7 and 3.2. Hope that's ok.

----------
components: Library (Lib)
files: example-argparse-type-function-called-twice.py
messages: 142306
nosy: arnau
priority: normal
severity: normal
status: open
title: argparse: type conversion function should be called only once
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22926/example-argparse-type-function-called-twice.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:59:22 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 18 Aug 2011 08:59:22 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313657962.05.0.380476556551.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Aug 18 10:59:47 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 18 Aug 2011 08:59:47 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313657987.84.0.772896300485.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Aug 18 11:26:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 09:26:03 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313634655.22.0.407945055817.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313659433.3602.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I asked the user who reported this documentation omission what he's
> using the 'n' argument for. His reply:
> 
>     "Yes I am using the n parameter, it is mainly to implement a
> subclass of Queue that supports "bulk" get and put operations. This
> enhances the performance of repeated get/put calls when the Queue is
> created using multiprocessing.Manager."

I think it's fine to document it. It's been there for a long time.
Besides, if we know how to notify one thread, we are certainly able to
notify n of them :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Thu Aug 18 11:40:13 2011
From: report at bugs.python.org (Kalev Lember)
Date: Thu, 18 Aug 2011 09:40:13 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1313660413.13.0.940387941667.issue3871@psf.upfronthosting.co.za>


Changes by Kalev Lember <kalevlember at gmail.com>:


----------
nosy: +kalev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Aug 18 11:40:20 2011
From: report at bugs.python.org (Kalev Lember)
Date: Thu, 18 Aug 2011 09:40:20 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1313660420.23.0.216969959884.issue3754@psf.upfronthosting.co.za>


Changes by Kalev Lember <kalevlember at gmail.com>:


----------
nosy: +kalev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu Aug 18 13:33:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 11:33:56 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas:

O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for file I/O).

Probably there are very old systems which don't support it, and perhaps
new systems that don't implement it *correctly* (meaning not
atomically); for the former I'd say we just don't care (who's gonna run
Python 3 on a 1995 system?) and for the latter, well, if the OS
designers think it's fine, let's just expose it as it is.

As for NFS, there's an interesting comment from 2007 here:
http://lwn.net/Articles/251971/

?My NFS tester shows that it at least appears to work with Linux,
Solaris and FreeBSD:
http://www.dovecot.org/list/dovecot/2007-July/024102.html. Looking at
Linux 2.6 sources it doesn't look like it tries to implement a racy
O_EXCL check in client side (fs/nfs/nfs3proc.c nfs3_proc_create()), so
the test's results should be correct. I don't know if other OSes do
that. I guess it would be nice to have a better O_EXCL tester which
tries to catch race conditions.?

----------
assignee: docs at python -> 
components:  -Documentation, Tests
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 13:56:53 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 11:56:53 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313668613.93.0.73423824885.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

My aim isn't to add all the commonly used flags, that would be pointless since its already possible using os.open.  The aim is to add a missing feature to the builtin open(), i.e. file creation.  At the moment open() implements read, write, and append, and creation is only implied by write. But in many cases, an explicit creation is desired (i.e, specifically create a new file, with an exception on failure).  It is true that this is possible with os.open, but it is somewhat obscure, especially for beginners, and is not as easy to read as "open(file, 'c')"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 14:08:51 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 18 Aug 2011 12:08:51 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1313669331.05.0.842365942606.issue9850@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

I fully agree with Ronald?s proposal. And for a start, here is a trivial patch that fixes macpath.join('', ...) [at the moment it just returns its last argument]. By the way, this fix is probably eligible for inclusion in Python?2.7 too.

I also have ?implement macpath.relpath? in my to-do list, although in practice this means nothing.

----------
keywords: +patch
nosy: +chortos
Added file: http://bugs.python.org/file22929/macpath_join_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Thu Aug 18 14:11:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Aug 2011 12:11:27 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669487.29.0.062520649955.issue12775@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Which version of Python did you test with?
Can you try with version 3.2?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 14:12:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 12:12:46 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669566.7.0.524263014301.issue12775@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 14:13:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 12:13:46 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669626.75.0.669972652722.issue12775@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you try to write a short example to reproduce the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:15:56 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 13:15:56 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <20110817200658.7a9c7129@resist.wooz.org>
Message-ID: <CAH_1eM2d4cOEC17P6O9qBmTj4iCPAXjPYONpK0DGUuCbBX=qqg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> My question too! ?I would say that stable releases should probably not get
> this change, but should force sys.platform to linux2 on 3.x kernels.
>

The point is precisely that we don't change anything: applications
checking against sys.platform are already broken, there's no reason to
comfort them into using this defective check.
The applications that encountered the problem (chromium, matplotlib
and probably others) already performed the change to
sys.platform.startswith(), so it's really the only way to go.

> BTW, does anybody think sys.platform should use a more dynamic approach for
> calculating its value? ?Well, maybe not necessary if Python 3.3 will just say
> 'linux'.

There's already platform.system() for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:24:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 13:24:53 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3tWTZeWEMPQQqh8X7ykezhjOw-_dU5UgPgdtVMwX3ZKg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas:
>
> O_EXCL is a POSIX standard. It is also supported
> under Windows by the _open/_wopen compatibility functions (which we use
> for file I/O).
>

If it's supported by Windows then I'm OK (not that I personaly care
about Windows :-).

> and is not as easy to read as "open(file, 'c')"

Well, I'd rather have this flag called 'x', to be consistent with
glibc's fopen():

"""
       c (since glibc 2.3.3)
              Do not make the open operation, or subsequent read and write
              operations, thread cancellation points.

       x      Open the file exclusively (like the O_EXCL flag of
open(2)).  If the
              file already exists, fopen() fails, and sets errno to
EEXIST.  This
              flag is ignored for fdopen().
"""

By the way, could you submit your patch as a mercurial diff ("hg diff")?
It makes it easier to review under Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:28:44 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 13:28:44 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313674124.9.0.556755804215.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

Changing form 'c' to 'x' is easy enough, and if there is already a convention it makes sense to stick to it.

I thought I had done a mercurial diff! I'll try again and resubmit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:49:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 13:49:53 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313675393.1.0.787833126343.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch fixes all the str.is* methods and makes them work on narrow builds with non-BMP chars.  It also includes the _Py_UNICODE_NEXT macro proposed in #10542.

----------
Added file: http://bugs.python.org/file22930/issue9200.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:52:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 13:52:06 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1313675526.73.0.962094986501.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I attached a patch to fix the str.is* methods on #9200 that also includes the macro.

Since they are not public there, I don't see a reason to do 2 separate commits on 2.7/3.2 (one for the feature and one for the fix).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:57:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 13:57:54 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313675874.52.0.885486233864.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

(Note: I copied the macros from the other patch without changing the name.  If the approach is good I'll get rid of the prefixes and separate the words in IS{HIGH|LOW}SURROGATE with an _.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:58:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 13:58:54 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313675934.84.0.349984876183.issue9200@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file22930/issue9200.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 15:59:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 13:59:04 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313675944.71.0.525913771099.issue9200@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file22931/issue9200.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:02:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 14:02:28 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313676148.95.0.290979143574.issue12775@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this.

> Here is a short python script that demonstrates the issue, the JSON
> file in this case is 1.2GB large:

A couple remarks:
- please indicate the Python version you're using
- you should put your test in a script, one with gc.disable() at the top, to avoid using any cache that might be used internally by cjson
- you should perform "echo 3 > /proc/sys/vm/drop_cache" before each run to make sure you start with a cold page/buffer cache (see how fast your file got read the second time you called read_json_blob()?)

----------
nosy: +loewis, neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:15:59 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 18 Aug 2011 14:15:59 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313676959.01.0.662829286001.issue12760@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

A minor documentation error in io.rst line 475 which was changed to:

+   The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading
+   (default), writing, or appending.

and should have "creating" at the front I assume, like you have it later.

----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:19:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:19:17 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <CAH_1eM3tWTZeWEMPQQqh8X7ykezhjOw-_dU5UgPgdtVMwX3ZKg@mail.gmail.com>
Message-ID: <1313677026.3602.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, I'd rather have this flag called 'x', to be consistent with
> glibc's fopen():
> 
> """
>        c (since glibc 2.3.3)
>               Do not make the open operation, or subsequent read and write
>               operations, thread cancellation points.
> 
>        x      Open the file exclusively (like the O_EXCL flag of
> open(2)).  If the
>               file already exists, fopen() fails, and sets errno to
> EEXIST.  This
>               flag is ignored for fdopen().

Yeah, but I think "exclusively" is quite misleading since it does not
perform any locking of any kind. Also, I don't think we'll ever
integrate the glibc's "c" option in io.open().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:21:23 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 14:21:23 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313677283.06.0.0345198775128.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>IIUC the support for setup.py is transitional, i.e. "legacy support", for existing packages transitioning from distutils/setuptools/Distribute to packaging. New features should not rely on the existence of setup.py.

I know, the implementation way of scripts has nothing to do with the setup.cfg or setup.py, these two files are just different ways to offer configuration values. So just don't worry about that.

What the I try to express here is :
There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from  distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal. Just visit /Doc/build/html/packaging/configfile.html to know more about the different roles of these two configuration files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:27:36 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 14:27:36 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313677656.15.0.899275544816.issue12394@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>BTW higery, did you use any of the build-scripts functionality I developed in the pythonv branch?

NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:29:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:29:23 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313677763.6.0.701906187158.issue12775@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Charles-Fran?ois said: it would be nice to know which Python version you are using. Also, if you could test with 2.7 or 3.2 and the standard json module (or the latest simplejson if you prefer).

Also, while Python's performance is not always excellent, it is quite rare for it to be GC-limited, so the advice you are suggesting we give would be misleading for most use cases.

Note that instead of disabling the GC, you can tune its parameters by calling set_threshold. For example:

  u, v, w = gc.get_threshold()
  gc.set_threshold(u, v * 10, w * 50)

(this will make full collections occur 500 times less often)

Or you could disable the GC only when decoding JSON data and reenable it afterwards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:30:38 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 14:30:38 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313677838.33.0.207966712221.issue8668@psf.upfronthosting.co.za>


Changes by higery <shoulderhigher at gmail.com>:


Added file: http://bugs.python.org/file22932/af7d14ff129b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:32:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:32:27 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
	GetFinalPathNameByHandle
Message-ID: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In the implementation of nt._getfinalpathname() (in posixmodule.c) we have:

    /* We have a good handle to the target, use it to determine the
       target path name. */
    buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT);

[...]

    result_length = Py_GetFinalPathNameByHandleW(hFile, target_path,
                                                 buf_size, VOLUME_NAME_DOS);


There doesn't seem to be a good reason to use VOLUME_NAME_NT in the first call and VOLUME_NAME_DOS in the second. Especially given the second call might require more characters than the first call, and therefore return a truncated path.

----------
components: Library (Lib)
messages: 142325
nosy: brian.curtin, pitrou, tim.golden
priority: low
severity: normal
status: open
title: Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:37:12 2011
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 18 Aug 2011 14:37:12 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
	GetFinalPathNameByHandle
In-Reply-To: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>
Message-ID: <1313678232.64.0.504698215888.issue12777@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Adding Jason - I'll dig around for it, but I think I brought this up in the past and I seem to remember him having a justification for it. (apologies if I'm thinking of something else)

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:42:35 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 14:42:35 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313678555.84.0.166217975022.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

The bug note contains a test script. You just have to generate a huge JSON-blob, or allocate 1 GB or so and pickle it down to file and replace the cjson.decode to pickle.loads, pickle is about 20 times faster without GC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:46:38 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 14:46:38 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313678798.0.0.366084090214.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

"Or you could disable the GC only when decoding JSON data and reenable it afterwards."

JSON was just an example, and disabling/enabling the GC is not safe in a multithreaded environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:51:43 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 14:51:43 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313679103.3.0.359074375004.issue8668@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Through discussing inside or outside the mailing list on this bug tracker, current 'develop' has been made a kind of command other than an action. But there still isn't a consensus of the concrete implemention way, so I keep this command name as 'develop' and the simple usage of this command is :

pysetup run develop

BTW, most developers in this list have agreed that 'develop' is a kind of install command, so I also add an entry funtion 'install_editable' for it, like 'install_local_project' for the 'install_dist' command. In addition, current patch also supports several ways to run the 'develop' which is learned from the source code of install.py. When installing, there are three ways, '_run_packaging_install', '_run_setuptools_install', and '_run_distutils_install', so here for develop command, there are two ways, '_run_packaging_develop' and '_run_setuptools_develop'. You can know more through the source code and docs in this patch.

BTW, should way convert the .egg-info directory to .dist-info directory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 16:56:25 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 18 Aug 2011 14:56:25 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
	GetFinalPathNameByHandle
In-Reply-To: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>
Message-ID: <1313679385.51.0.149765023342.issue12777@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I agree the two calls should probably be consistent, though I also suspect that VOLUME_NAME_NT is always longer than VOLUME_NAME_DOS.

My justification for using VOLUME_NAME_NT is that the final name might not be located on a DOS-accessible name. My suspicion was that VOLUME_NAME_NT was more general purpose (though somewhat less user-friendly), so preferable in the case that the name isn't exposed to the user. It's been a while since I've investigated it, but I think you can have symlinks to UNC paths as well as \\?\ paths, so my concern is VOLUME_NAME_DOS might not work with those paths. Some tests are probably called for.

In the case of nt._getfinalpathname(), it's not obvious to me how it might be used, so VOLUME_NAME_DOS may be more appropriate. Or perhaps _getfinalpathname should pass that parameter through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:07:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 15:07:40 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313678555.84.0.166217975022.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313679930.3602.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The bug note contains a test script. You just have to generate a huge
> JSON-blob, or allocate 1 GB or so and pickle it down to file and
> replace the cjson.decode to pickle.loads, pickle is about 20 times
> faster without GC.

You can't say that any "huge JSON blob" will exhibit the same
performance characteristics as yours. I just tested json.loads() with a
rather trivial 300MB JSON string, and it took a couple of seconds (on
2.7). Does it reproduce your workload? I don't know.

> disabling/enabling the GC is not safe in a multithreaded environment?

You are right that disabling/enabling the GC is a global setting. But
that still leaves the option of tuning the parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:12:23 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 18 Aug 2011 15:12:23 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313680343.95.0.836244097046.issue8668@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

_run_setuptools_install is only intended to support setuptools setup.py, converting .egg-info to .dist-info, internally. IMO, you should not care about the differences between setuptools/distutils1/setuptools at this level, as it should be taken care at the install level.

When installing old setuptools-based setup.py, the .egg-info should be gone, replaced by a shiny new .dist-info folder. I'm not sure why you're talking about it in the context of develop, can you clarify this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:14:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 15:14:16 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313680456.87.0.302575181883.issue12760@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Yeah, but I think "exclusively" is quite misleading since it does not
> perform any locking of any kind.

It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX.

Furthermore, there's an added bonus: actually, with the old I/O layer, one can already pass an 'x' flag to open, since it just calls fopen:
"""
cf at neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0666) = 3
cf at neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/usr/lib/pymodules/python2.6/<string>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
IOError: [Errno 17] File exists: '/tmp/foo'
"""

I don't know if it's documented behavior, but the OP in issue 12105 was using it with python 2.
Changing it to 'x' would make such code backward-compatible.

Finally, when I read open('/tmp/foo', 'wx'), it's immediately clear to me what's going on, while I'd have to look at open()'s documentation to find out what the 'c' flag does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:14:24 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 18 Aug 2011 15:14:24 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313680464.61.0.562733217619.issue8668@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

IOW, in my opinion, support for setuptools develop command is not needed in packaging core, and still be taken care directly be the users wanting to run python setup.py develop: I don't see any reason to make it avaible on the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:16:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 15:16:34 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313680594.46.0.591277806052.issue12760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't know if it's documented behavior

See #12103: it is not documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:16:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 15:16:49 +0000
Subject: [issue12777] Inconsistent use of VOLUME_NAME_* with
	GetFinalPathNameByHandle
In-Reply-To: <1313677947.11.0.030758892383.issue12777@psf.upfronthosting.co.za>
Message-ID: <1313680609.42.0.256257688635.issue12777@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's slightly off-topic, but is it enough to strip the leading '\\?\' (and replace 'UNC' with '\'), or are there other things to watch out for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12777>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:18:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Aug 2011 15:18:12 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <E1Qu4ME-0004qb-Su@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9ee802642d86 by Charles-Fran?ois Natali in branch '2.7':
Issue #12650: Fix a race condition where a subprocess.Popen could leak
http://hg.python.org/cpython/rev/9ee802642d86

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:23:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 15:23:16 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
Message-ID: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

On a 8GB RAM box (more than 6GB free), serializing many small objects can eat all memory, while the end result would take around 600MB on an UCS2 build:

$ LANG=C time opt/python -c "import json; l = [1] * (100*1024*1024); encoded = json.dumps(l)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/antoine/cpython/opt/Lib/json/__init__.py", line 224, in dumps
    return _default_encoder.encode(obj)
  File "/home/antoine/cpython/opt/Lib/json/encoder.py", line 188, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/home/antoine/cpython/opt/Lib/json/encoder.py", line 246, in iterencode
    return _iterencode(o, 0)
MemoryError
Command exited with non-zero status 1
11.25user 2.43system 0:13.72elapsed 99%CPU (0avgtext+0avgdata 27820320maxresident)k
2920inputs+0outputs (12major+1261388minor)pagefaults 0swaps


I suppose the encoder internally builds a large list of very small unicode objects, and only joins them at the end. Probably we could join it by chunks so as to avoid this behaviour.

----------
messages: 142338
nosy: ezio.melotti, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: JSON-serializing a large container takes too much memory
type: resource usage
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:25:19 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 18 Aug 2011 15:25:19 +0000
Subject: [issue12757] undefined name in doctest.py
In-Reply-To: <1313479086.68.0.065111934389.issue12757@psf.upfronthosting.co.za>
Message-ID: <1313681119.33.0.222155420959.issue12757@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

It is possible to retrieve the current module using _normalize_module(None), or instead use the test name (dt_test.name) just like in DocTestCase.shortDescription.

Since there is no doc about it, IMHO we should use unittest's standard as guideline, which is: 
shortDescription()
 Returns a description of the test, or None if no description has been   
 provided. The default implementation of this method returns the first 
 line of the test method?s docstring, if available, or None.
(i.e., DocTestCase._dt_test.name)

What's your opinion?

----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12757>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:30:02 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 15:30:02 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313681402.06.0.583845761914.issue8668@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

Alexis Metaireau <alexis at notmyidea.org> added the comment:
>>I'm not sure why you're talking about it in the context of develop, can you clarify this?

My consideration is : if in Packaging we always convert .egg-info directory to .dist-info directory, then my two different kinds of ways(setuptools' develop or packaging's develop) for the 'develop' command are unnecessary, we can just retain the new-style packaging's develop, which mean '_run_packaging_develop' function here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:34:34 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 18 Aug 2011 15:34:34 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313681674.09.0.505893638017.issue8668@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Yep, packaging is not keeping the .egginfo directories, or at least does not plan to keep them (It should be the case currently but I haven't checked recently) in the upcoming release, so I would go on removing support for setuptools' develop command here :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:38:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Aug 2011 15:38:00 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313681877.6867.YahooMailNeo@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from? distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal.
>
>I think I understand that much. The point of setup.cfg is to do away with the completely ad-hoc nature of code that developers can put into setup.py, which prevents playing nicely with distro package managers. I'm fairly sure I've seen Tarek say that "for developers, no more setup.py" - in fact, I've just found where he said it:

http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib/

and also

http://pycon.tv/#/video/57 (at around 6:55 into the video, and at 8:30 - "there is no more setup.py" - meaning in the new way of doing things)

So the role of setup.py is historical, and the way developers customise installations is through using hooks. These work well enough, and I am currently using them in the nemo project which is a companion to the pythonv branch - see http://www.red-dove.com/screencasts/pythonv/pythonv.html

----------
Added file: http://bugs.python.org/file22933/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________
-------------- next part --------------
<html><body><div style="color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10pt"><div id="yiv159912332"><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: tahoma,new york,times,serif; font-size: 10pt;"><div id="yiv159912332yui_3_2_0_14_131367940402095"><br><blockquote id="yiv159912332yui_3_2_0_14_131367940402054" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div id="yiv159912332yui_3_2_0_14_131367940402094" class="yiv159912332yui_3_2_0_14_131367940402057" style="font-family: tahoma,new york,times,serif; font-size: 10pt;"><div id="yiv159912332yui_3_2_0_14_131367940402093" class="yiv159912332yui_3_2_0_14_131367940402059" style="font-family: times new roman,new york,times,serif; font-size: 12pt;">There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from&nbsp; distutils/setuptools to
 Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place
 different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal.<br><span></span></div></div></blockquote>I think I understand that much. The point of setup.cfg is to do away with the completely ad-hoc nature of code that developers can put into setup.py, which prevents playing nicely with distro package managers. I'm fairly sure I've seen Tarek say that "for developers, no more setup.py" - in fact, I've just found where he said it:</div><div id="yiv159912332yui_3_2_0_14_131367940402095"><br></div><div id="yiv159912332yui_3_2_0_14_131367940402095">http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib/</div><div id="yiv159912332yui_3_2_0_14_131367940402095"><br></div><div id="yiv159912332yui_3_2_0_14_131367940402095">and also<br></div><div
 id="yiv159912332yui_3_2_0_14_131367940402095"><br></div><div id="yiv159912332yui_3_2_0_14_131367940402095">http://pycon.tv/#/video/57 (at around 6:55
 into the video, and at 8:30 - "there is no more setup.py" - meaning in the new way of doing things)<br></div><div id="yiv159912332yui_3_2_0_14_131367940402095"><br></div><div id="yiv159912332yui_3_2_0_14_131367940402095">So the role of setup.py is historical, and the way developers customise installations is through using hooks. These work well enough, and I am currently using them in the nemo project which is a companion to the pythonv branch - see http://www.red-dove.com/screencasts/pythonv/pythonv.html</div><div id="yiv159912332yui_3_2_0_14_131367940402095"><br></div><div id="yiv159912332yui_3_2_0_14_131367940402095"><br><div id="yiv159912332yui_3_2_0_14_131367940402094" class="yiv159912332yui_3_2_0_14_131367940402057" style="font-family: tahoma,new york,times,serif; font-size: 10pt;"><div id="yiv159912332yui_3_2_0_14_131367940402093" class="yiv159912332yui_3_2_0_14_131367940402059" style="font-family: times new roman,new york,times,serif; font-size:
 12pt;"><br></div></div></div></div></div></div></body></html>

From report at bugs.python.org  Thu Aug 18 17:40:30 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 15:40:30 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313682030.9.0.605692997639.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

Working on getting a reasonable large file to test with on my laptop where I have 2.6, 2.7, 3.2. The Python version where the problem became apparent was 2.5.2 as the software is deployed on Debian Lenny.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:40:56 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Aug 2011 15:40:56 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <CAH_1eM2d4cOEC17P6O9qBmTj4iCPAXjPYONpK0DGUuCbBX=qqg@mail.gmail.com>
Message-ID: <20110818114050.6a3ee84c@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 01:15 PM, Charles-Fran?ois Natali wrote:

>Charles-Fran?ois Natali <neologix at free.fr> added the comment:
>
>> My question too! ?I would say that stable releases should probably not get
>> this change, but should force sys.platform to linux2 on 3.x kernels.
>
>The point is precisely that we don't change anything: applications
>checking against sys.platform are already broken, there's no reason to
>comfort them into using this defective check.
>The applications that encountered the problem (chromium, matplotlib
>and probably others) already performed the change to
>sys.platform.startswith(), so it's really the only way to go.

I still think that sys.platform for the stable releases should never report
'linux3'.  Updating the various conditionals *probably* has low risk of
regression, but I think you have to check that very carefully.

>> BTW, does anybody think sys.platform should use a more dynamic approach for
>> calculating its value? ?Well, maybe not necessary if Python 3.3 will just
>> say 'linux'.
>
>There's already platform.system() for that.

TOOWTDI

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:45:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 15:45:45 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313682345.76.0.223700410288.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I still think that sys.platform for the stable releases should 
> never report 'linux3'

I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of:

 * FreeBSD
 * OpenBSD
 * NetBSD
 * unixware
 * openunix
 * sco_sv
 * sunos
 * hp-ux

(Ok, some of them are dead and you cannot expect new major versions :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:52:21 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Aug 2011 15:52:21 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313682345.76.0.223700410288.issue12326@psf.upfronthosting.co.za>
Message-ID: <20110818115214.467fc63c@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 03:45 PM, STINNER Victor wrote:

>I don't understand why do you want to have a special case for
>Linux. sys.platform is already different for each major version of:

We already have special cases for cygwin, darwin, and irix (okay, the latter
is dead too :).  I'm just suggesting one more special case for linux*

(see configure.in and search for MACHDEP)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:54:16 2011
From: report at bugs.python.org (higery)
Date: Thu, 18 Aug 2011 15:54:16 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313682856.8.0.712545465963.issue8668@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>IOW, in my opinion, support for setuptools develop command is not needed in packaging core

Then do you also mean support that for setuptools install is also not necessary in packaging core?

>>and still be taken care directly be the users wanting to run python setup.py develop: I don't see any reason to make it avaible on the stdlib.

I think the current implemention way of Packaging 'install' command just offers an executing router to run a proper 'install', which users doesn't need to know. It also the same to 'develop'. BTW, I think it's ok if setuptools is already installed when a user try to run 'python setup.py develop', if not, python will report error. In addition, Packaging use a different way to issue commands - cd to the source directory, and use 'pysetup run develop' to do the job. Old setup.py will be supported only by issuing commands under the source directory containing the setup.py, and if setuptools exists, Packaging will dispatch the job to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:54:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Aug 2011 15:54:50 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <E1Qu4vh-0008Hi-Fy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7d358379c5fb by Charles-Fran?ois Natali in branch '2.7':
Issue #12650: only run the tests on Unix.
http://hg.python.org/cpython/rev/7d358379c5fb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 17:56:53 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Aug 2011 15:56:53 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313683011.68691.YahooMailNeo@web25808.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

>________________________________
>NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system.
>
>Not just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. This is particularly important in virtualenvs where there could be any number of Python executables (of different versions) represented. But how will we know which .py files mentioned in resources are data, and which are actually scripts?

To me, it actually makes more sense to keep those scripts in the [scripts] section, and have some way of recognising which scripts need to be copied/amended and which ones need to be generated from callables.

----------
Added file: http://bugs.python.org/file22934/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________
-------------- next part --------------
<html><body><div style="color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10pt"><div id="yiv1385342022"><div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: tahoma,new york,times,serif; font-size: 10pt;"><div id="yiv1385342022yui_3_2_0_14_131368247675778"><br><blockquote id="yiv1385342022yui_3_2_0_14_131368247675754" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><div id="yiv1385342022yui_3_2_0_14_131368247675785" class="yiv1385342022yui_3_2_0_14_131368247675757" style="font-family: tahoma,new york,times,serif; font-size: 10pt;"><div id="yiv1385342022yui_3_2_0_14_131368247675784" class="yiv1385342022yui_3_2_0_14_131368247675759" style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><font id="yiv1385342022yui_3_2_0_14_131368247675783" face="Arial" size="2"><hr size="1"><b id="yiv1385342022yui_3_2_0_14_131368247675782"><span
 id="yiv1385342022yui_3_2_0_14_131368247675781" style="font-weight: bold;"></span></b></font>NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts
 will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system.<br><span></span></div></div></blockquote>Not just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. This is particularly important in virtualenvs where there could be any number of Python executables (of different versions) represented. But how will we know which .py files mentioned in resources are data, and which are actually scripts?<br><br>To me, it actually makes more sense to keep those scripts in the [scripts] section, and have some way of recognising which scripts need to be copied/amended and which ones need to be generated from callables.<br><br></div></div></div></div></body></html>

From report at bugs.python.org  Thu Aug 18 17:58:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 15:58:16 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313683096.4.0.325094642429.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm just suggesting one more special case for linux*

You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:01:15 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 16:01:15 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313683275.39.0.779502386289.issue12776@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:05:22 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 18 Aug 2011 16:05:22 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1313682856.8.0.712545465963.issue8668@psf.upfronthosting.co.za>
Message-ID: <4E4D37F1.9080401@notmyidea.org>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

On 08/18/2011 05:54 PM, higery wrote:
> Then do you also mean support that for setuptools install is also not necessary in packaging core?

setuptools install is only supported in packaging because it's a widely 
used thing, and many python distributions are currently packaged using 
setuptools features in their setup.py

 > I think the current implemention way of Packaging 'install' command 
just offers an executing router to run a proper 'install', which users 
doesn't need to know.

What packaging.install does is, if the project has been packaged using 
setuptools, relying on it to install the projects, while not letting it 
take care of the dependencies. Then, the .egginfo is converted to a 
.distinfo, so the way setuptools distributions are installed is *not* 
compatible with setuptools installation procedure.

It is important to note that setuptools will *not* be a dependency for 
packaging, but rather the end user will be prompted to install it if 
it's not present and he wants to install a setuptools based project (or 
if what he's trying to install relies on setuptools based projects).

The problem with the develop command seems different to my eyes: develop 
is used by developers, not by end users. Thus, proposing them to keep 
using the "old" setuptools develop command in packaging may seem like 
encouraging them to continue using setuptools.

Rather, I would prefer to say: "well, if you want to use setuptools' 
develop command, you can continue to do so, but the way to go would 
probably to repackage your project using shiny new standards". That's 
one of the handles we have to help the transition to packaging, so 
taking this occasion seems important to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:06:35 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 16:06:35 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313683595.52.0.268324784337.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

I hope this patch suits you better :-)

I've updated the documentation typo (thanks for pointing that out). I've also changed 'c' to 'x', since I think that if there is a convention we should stick to it.  I don't think that it matters if the glibc docs say 'exclusive', as long it its clear in the python docs what it does, which I think it is. Having said that, I don't really have a strong opinion either way, so I'll happily change it back to 'c' if its preferred.

----------
Added file: http://bugs.python.org/file22935/open_create_x-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:09:56 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Aug 2011 16:09:56 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313683096.4.0.325094642429.issue12326@psf.upfronthosting.co.za>
Message-ID: <20110818120951.11463316@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote:

>
>STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> I'm just suggesting one more special case for linux*
>
>You suggest to have a special case in Python 2.7 and 3.2, but not in Python
>3.3 (3.1, 2.6, etc.)?

Correct.  We can't touch Python 3.1, 2.6, or earlier because those are all in
security-only mode, and unless a specific security related issue is
identified, the change should not be made there.  That's just life (a recent
similar example is support for multiarch in newer Debian and Ubuntu releases -
we just don't support that in security-only Pythons).

We can and should change Python 3.2 and 2.7 to only report 'linux2' for
backward compatibility.

For Python 3.3, we should do the right thing, which IMO is to set sys.platform
to 'linux' without the version number.  In parallel we can change the stdlib
tests to use .startswith() and encourage third party developers to use
.startswith() also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:13:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 16:13:52 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <20110818120951.11463316@resist.wooz.org>
Message-ID: <1313683902.3602.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Correct.  We can't touch Python 3.1, 2.6, or earlier because those are all in
> security-only mode, and unless a specific security related issue is
> identified, the change should not be made there.  That's just life (a recent
> similar example is support for multiarch in newer Debian and Ubuntu releases -
> we just don't support that in security-only Pythons).
> 
> We can and should change Python 3.2 and 2.7 to only report 'linux2' for
> backward compatibility.

It means someone upgrading from 2.6 to 2.7 will see sys.platform change
from "linux3" to "linux2". That breaks compatibility.

> For Python 3.3, we should do the right thing, which IMO is to set sys.platform
> to 'linux' without the version number.  In parallel we can change the stdlib
> tests to use .startswith() and encourage third party developers to use
> .startswith() also.

The latter is already done in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:15:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 16:15:17 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313684117.99.0.596178240952.issue12326@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy:  -neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:18:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 16:18:45 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313684325.66.0.786214903877.issue9200@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it NEXT_CHARACTER().

_Py_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and _Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them inlined in _Py_UNICODE_NEXT.

The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless.

It looks like the macro can be simplified to something like:

#define _Py_UNICODE_NEXT(ptr, end)                                      \
    (_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) && (ptr) < (end)) && _Py_UNICODE_ISLOWSURROGATE((ptr)[1] ?           \
     ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) :  \
     (Py_UCS4)*(ptr)++)

(you don't need two "a?b:c")

I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro because it has border effect (ptr++ or ptr += 2). You cannot write Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because Py_UNICODE_ISALNUM is defined as:

#define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || Py_UNICODE_ISNUMERIC(ch))

And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a program having such long macro. If you really want to keep it as a macro, please add a least a big warning.

It's also confusing to have two attachments with the same name :-/

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:21:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 16:21:00 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313684460.36.0.395534600584.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For Python 3.3, (...) In parallel we can change the stdlib
> tests to use .startswith()

done, see my changeset 50f1922bc1d5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:23:23 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:23:23 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313684603.6.0.954302955841.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

using: (except in python2.5 case where simplejson is used, which ought to be the same thing right?)
import time, gc, json, sys

def read_json_blob():
	t0 = time.time()
	fd = open("datatest1.json")
	data = fd.read()
	fd.close()
	t1 = time.time()
	parsed = json.loads(data)
	t2 = time.time()
	print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % (t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
	gc.disable()

read_json_blob()
print(gc.collect())

daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python3.2 gc.py nogc
read file in 1.34s, parsed json in 2.74s, total of 4.07s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python3.2 gc.py
read file in 1.33s, parsed json in 2.71s, total of 4.05s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 56.03s, total of 56.92s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 56.38s, total of 57.27s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py
read file in 0.89s, parsed json in 3.87s, total of 4.75s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py nogc
read file in 0.89s, parsed json in 3.91s, total of 4.80s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.11s, parsed json in 53.00s, total of 53.11s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.14s, parsed json in 53.13s, total of 53.28s
0

Everything is equally slow.. no weird things there, except that Python 3.2 seems to take more time to load the file. Nice performance improvement of the json module in 3.2 compared to older Python versions.


Next up. Trying with cjson which decodes via a binary module:

import time, gc, cjson, sys

def read_json_blob():
	t0 = time.time()
	fd = open("datatest1.json")
	data = fd.read()
	fd.close()
	t1 = time.time()
	parsed = cjson.decode(data)
	t2 = time.time()
	print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % (t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
	gc.disable()

read_json_blob()
print(gc.collect())

daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.46s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py nogc
read file in 0.89s, parsed json in 1.53s, total of 2.42s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py
read file in 0.89s, parsed json in 1.54s, total of 2.43s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.43s, total of 2.32s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.73s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.16s, parsed json in 1.07s, total of 1.23s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.72s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.14s, parsed json in 1.06s, total of 1.20s

The file is actually a bit too small for good measurement when using cjson, but interesting point here is obviously the huge difference between GC and no GC in Python 2.5, and quite a bit win in 2.6 too, which becomes a lot more apparent with larger files.

Another interesting thing is that Python 2.6 is consistently faster than 2.7 when the GC is disabled in 2.6, compared to both enabled and disabled in 2.7. The cjson isn't compatible with Python 3.2 so I cannot verify how things work there.

So overall it looks like it's less of a problem in newer versions of Python. We are phasing out the software that is deployed on Debian Lenny so it's a problem that will go away. I don't think I have any objections with closing this ticket again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:26:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 16:26:51 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313684811.69.0.750186706718.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If we change Python 2.7.3 and 3.2.2 to force sys.platform to linux2 (instead of linux3) and use "linux" in Python 3.3, we will have 3 differents values of sys.platform if Python is built on Linux 3:

 - "linux3" on Python <= 2.7.2 or Python <= 3.2.1
 - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3
 - "linux" on Python >= 3.3

I don't see how it will help backward or forward compatibility... It's exactly as the current state (sys.platform == 'linux3' on all Python versions): applications have to use sys.platform.startswith() to work correctly on any Linux version.

Well, except maybe if you plan to write applications working only on Python >= 2.7.3? ... this version is not released yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:29:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 16:29:15 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313684955.66.0.399949559381.issue12775@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

IIRC the C acceleration for json were added in 2.7/3.2, and are used automatically when you import json.  In the previous releases the json module was implemented in pure Python.  That explains why it's much slower on Python 2.5/6.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:33:23 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:33:23 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685203.42.0.089160892539.issue12775@psf.upfronthosting.co.za>


Changes by Daniel Svensson <dsvensson at gmail.com>:


----------
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:35:01 2011
From: report at bugs.python.org (poq)
Date: Thu, 18 Aug 2011 16:35:01 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313685301.93.0.0781202777777.issue12778@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

I think this is because dumps() uses the C encoder. Making the C encoder incremental (i.e. iterator-based) like the Python encoder would solve this.

I actually looked into doing this for issue #12134, but it didn't seem so simple; Since C has no yield, I think the iterator would need to maintain its own stack to keep track of where it is in the object tree it's encoding...

If there is interest though, I may be able to write a patch when I have some time off again...

----------
nosy: +poq

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:35:55 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:35:55 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685355.72.0.404659725785.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

Yes, but this ticket was only opened due to time delta between no-gc and gc, not as much absolute time, but that's a nice improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:36:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 16:36:42 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313684603.6.0.954302955841.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685272.3602.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So overall it looks like it's less of a problem in newer versions of
> Python. We are phasing out the software that is deployed on Debian
> Lenny so it's a problem that will go away. I don't think I have any
> objections with closing this ticket again.

Thanks for the comprehensive measurements. Indeed I think it doesn't
seem it is a problem in 2.7/3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:38:12 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 18 Aug 2011 16:38:12 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1313684325.66.0.786214903877.issue9200@psf.upfronthosting.co.za>
Message-ID: <4E4D3FEC.5040406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it NEXT_CHARACTER().

Can we please stick to the things we discussed on issue10542.

The macros are intended to be public starting with 3.3, not private
and they are meant to be used outside the interpreter as well.
They will only be private for patch level release patches. For those
you don't need the Py-prefix, but it also doesn't hurt having it
there.

> _Py_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and _Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them inlined in _Py_UNICODE_NEXT.
> 
> The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless.
> 
> It looks like the macro can be simplified to something like:
> 
> #define _Py_UNICODE_NEXT(ptr, end)                                      \
>     (_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) && (ptr) < (end)) && _Py_UNICODE_ISLOWSURROGATE((ptr)[1] ?           \
>      ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) :  \
>      (Py_UCS4)*(ptr)++)
> 
> (you don't need two "a?b:c")
> 
> I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro because it has border effect (ptr++ or ptr += 2). You cannot write Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because Py_UNICODE_ISALNUM is defined as:

> #define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || Py_UNICODE_ISNUMERIC(ch))
> 
> And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a program having such long macro. If you really want to keep it as a macro, please add a least a big warning.

Having it as function would kill the performance advantage, so that's not
really an option. The use case you mention is also not really realistic.

Adding an extra warning to the macro version is still a good idea, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:43:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:43:28 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313685808.21.0.120768586807.issue12765@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is it possible to run the test suite with -vv on the buildbot to see the changes made to os.environ?  On a related note, is it possible to get SSH access to a similar machine?  If not, I will add debugging info in a commit and watch the buildbot; it will be more tedious and also make noise for python-checkins, but well.

----------
components: +Distutils2, Macintosh -Library (Lib), Tests
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:44:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:44:50 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1313685890.33.0.487662116557.issue9850@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Is the function already tested or does someone need to add a test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:48:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Aug 2011 16:48:50 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <E1Qu5lu-0004l8-LE@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8ca7f109ce79 by Charles-Fran?ois Natali in branch '3.2':
Issue #12650: Fix a race condition where a subprocess.Popen could leak
http://hg.python.org/cpython/rev/8ca7f109ce79

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:49:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:49:29 +0000
Subject: [issue12779] Update packaging documentation
Message-ID: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The documentation for packaging is outdated: it refers to setup.py instead of setup.cfg or pysetup, it talks about removed parts like compress (.Z) archives or bdist_rpm, and needs a good read-through.  I have started to work on this, so I?m opening this report to prevent someone else from duplicating efforts.

----------
assignee: eric.araujo
components: Distutils2, Documentation
messages: 142367
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Update packaging documentation
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:50:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:50:17 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1313686217.61.0.791036143758.issue12779@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Replying to myself so that this report doesn?t show up in the ?Issues without reply? section of the weekly email)

----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12779>
_______________________________________

From report at bugs.python.org  Thu Aug 18 18:51:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:51:31 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1313686291.53.0.861371159209.issue11553@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, I have updated the site module and distutils/packaging docs to document the PEP 370 features.  There has been no feedback, so I will backport to 2.7 and close the reports.  See linked bugs to read the changesets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:01:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 18 Aug 2011 17:01:57 +0000
Subject: [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313686917.84.0.938989970481.issue12761@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After a closer look (thanks Ezio), the proper patch should be something like:


diff --git a/Doc/license.rst b/Doc/license.rst
--- a/Doc/license.rst
+++ b/Doc/license.rst
@@ -874,9 +874,8 @@
 zlib
 ----
 
-The :mod:`zlib` extension is built using an included copy of the zlib
-sources if the zlib version found on the system is too old to be
-used for the build::
+The :mod:`zlib` extension is built using the zlib version found on the system,
+but an included copy of the zlib sources is shipped for the Windows build::
 
   Copyright (C) 1995-2011 Jean-loup Gailly and Mark Adler


because the embedded zlib is not used in the linux build (but always the system one, and if absent, no zlib module is built) while we have several references of Modules/zlib/ files in PC/VC* and PCbuild/*.vcproj (that I can't read); adding to nosy the windows expert to have their opinion.

----------
nosy: +brian.curtin, tim.golden
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12761>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:04:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:04:40 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1313687080.44.0.192966172559.issue5845@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21399/fix-5845.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:05:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:05:24 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1313687124.81.0.0770352701255.issue5845@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Updated patch (not using Mercurial, looks like I haven?t enough bandwidth to push all those changesets).

----------
Added file: http://bugs.python.org/file22936/fix-5845.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:08:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Aug 2011 17:08:26 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1313687306.61.0.675055989712.issue12720@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here is a new patch, implementing Antoine's suggestions.

----------
Added file: http://bugs.python.org/file22937/xattrs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:09:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:09:47 +0000
Subject: [issue11599] Useless error message when distutils fails compiling
In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za>
Message-ID: <1313687387.57.0.847765168019.issue11599@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file21316/fix-compile-error-messages.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11599>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:10:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:10:10 +0000
Subject: [issue11599] Useless error message when distutils fails compiling
In-Reply-To: <1300473236.84.0.248517729635.issue11599@psf.upfronthosting.co.za>
Message-ID: <1313687410.33.0.500058320421.issue11599@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22938/fix-11599.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11599>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:12:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Aug 2011 17:12:59 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <E1Qu69H-00076t-Ec@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 148d75d106f1 by Charles-Fran?ois Natali in branch 'default':
Issue #12650: Fix a race condition where a subprocess.Popen could leak
http://hg.python.org/cpython/rev/148d75d106f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:12:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:12:59 +0000
Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need
	better error message
In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za>
Message-ID: <1313687579.46.0.161038364736.issue8286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you test with this patch?

----------
keywords: +patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file22939/sdist-no-traceback-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8286>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:14:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:14:41 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
Message-ID: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

After PEP 3147, __file__ always points to the py file, not pyc/pyo.  I found two instances of obsolete code.

----------
files: fix-11599.diff
keywords: patch
messages: 142375
nosy: benjamin.peterson, eric.araujo, vinay.sajip
priority: normal
severity: normal
stage: commit review
status: open
title: Clean up tests for pyc/pyo in __file__
versions: Python 3.3
Added file: http://bugs.python.org/file22940/fix-11599.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:19:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:19:01 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313687941.93.0.904908673272.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22933/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:19:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:19:03 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313687943.49.0.297685640741.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22934/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:22:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 17:22:41 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313688161.11.0.633868309496.issue12765@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Bill is the owner of that buildbot.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:34:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:34:15 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313688855.14.0.704007520391.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> scripts = 
>    foo = a.b.c.main
>    foowin = a.b.c.winmain -window

This is great.  About -window: I don?t think using a fake option style (leading -) is useful, and I?d reuse the setuptools name, ?gui?.  I also think this good idea of yours can solve our other feature requests:

unit2 = unittest2.main.main
unit2-tk = unittest2.gui.main window
spamd = spamlib.daemon.main sbin

The first example is a regular script; the second one will use pythonw on Windows and Mac OS X; the third one would install to /usr/sbin instead of /usr/bin on POSIX.  What do you think?

> 'scripts' belongs to the 'files' section in setup.cfg, it's still ok
> now to place it in 'files'?
As I said in private email, I don?t think it?s a concern at all, but maybe other people disagree.  An alternate idea: using a new section:

[scripts]
sphinx-build = sphinx.build.main

You should ask on the fellowship ML.

About setup.cfg and setup.py.  In general, packaging totally ignores setup.py.  However, one goal is to support generated setup.py that take all the info from the setup.cfg file, thanks to pysetup generate-setup.  In that case, there?s a compatibility question, as you said: what do we do with scripts as dotted paths?  It would be too much pain to use inspect.getsource to copy our functions that generate scripts into the setup.py file.  I think our documentation should just advise people to create an old-style script file and manually add it in their setup.py.

>> To support the old-style scripts generated by d*/s* in p*, we can use
>> the resource system.
> Not just as is, I believe. When scripts are installed (as opposed to
> other resources), it's not enough to copy them across to the
> configured destination: you also need to change their shebang lines
> to point to the appropriate Python executable.
That is true.  I see too possible solutions: tell people to use a hook, or have special handling for resources registered in the scripts category (IOW a built-in hook).  I prefer the second option.

> But how will we know which .py files mentioned in resources are data,
> and which are actually scripts?
Distutils scripts are not actually restricted to Python scripts.  The shebang updating only happens if a regex matches.  To answer your question: the resources system uses categories, one of which is ?scripts?.

I?m -1 on using heuristics to handle both distutils-style files and packaging-style dotted paths (Vinay?s latest message).  It?s much cleaner to have separate fields or sections.

(BTW Vinay, remember that Roundup creates attachments when someone sends HTML email)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:34:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:34:39 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <1313688879.88.0.29533613692.issue12780@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file22940/fix-11599.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:34:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:34:49 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <1313688889.36.0.592093794568.issue12780@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file22941/__file__-cant-contain-pyc-in-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:36:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:36:32 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313688992.04.0.402677286116.issue12394@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Heh, I messed up my example:

unit2-tk = unittest2.gui.main gui

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:43:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 17:43:34 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <CAH_1eM2d4cOEC17P6O9qBmTj4iCPAXjPYONpK0DGUuCbBX=qqg@mail.gmail.com>
Message-ID: <4E4D4F44.9060502@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The point is precisely that we don't change anything: applications
> checking against sys.platform are already broken, there's no reason to
> comfort them into using this defective check.

You grossly misunderstand the concept of "backwards compatibility".
At times, features get added to allow even buggy (or perceived-buggy)
applications to continue to work under a change.

> The applications that encountered the problem (chromium, matplotlib
> and probably others) already performed the change to
> sys.platform.startswith(), so it's really the only way to go.

I'm very certain that not all applications have been changed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:45:43 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 17:45:43 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313682345.76.0.223700410288.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4D4FC6.5090604@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't understand why do you want to have a special case for Linux. 
> sys.platform is already different for each major version of:

That's because Linux uses major version numbers in an entirely different
way than these systems. There is a traditional usage of major versions
(to indicate significant changes), and the systems you list follow this
practice. And then there are systems that break with that tradition, and
use the major version for marketing and other purposes, and Linux is one
of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:46:50 2011
From: report at bugs.python.org (James Y Knight)
Date: Thu, 18 Aug 2011 17:46:50 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313689610.38.0.0941303072395.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

> Well, except maybe if you plan to write applications working only on Python >= 2.7.3? ... this version is not released yet.

No, of course I don't plan on writing new code that checks sys.platform == 'linux2'. That's ridiculous.

I plan to use *already written* applications on Python<2.7.3 binaries that have already been built (and thus were built on a 2.x kernel and report linux2), on Python>=2.7.3 which will be fixed to continue reporting linux2, and on Python<2.7.3 which have had the same fix backported to them by distros, since Python upstream won't do it for earlier branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:48:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 17:48:03 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313683902.3602.13.camel@localhost.localdomain>
Message-ID: <4E4D5051.1050407@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> from "linux3" to "linux2". That breaks compatibility.

No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
both linux2 and linux3, so it will continue just fine on 2.7.

I'd rather phrase this differently: Python 2.6 does not support Linux 3.
Tough luck, since Linux 3 was released long after Python 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:48:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:48:19 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1313689699.97.0.619268474073.issue8668@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [...] so I keep this command name as 'develop' and the simple usage
> of this command is :
> pysetup run develop
So far, so good.

> BTW, most developers in this list have agreed that 'develop' is a
> kind of install command, so I also add an entry funtion
> 'install_editable' for it,
That can be useful.  On the other hand, pip uses subprocesses instead of calling Python functions, to make sure an error in the called code does not stop pip.  I still think it?s a nice function to have.  The name should be changed: ?editable? is not used in our current terminology, so install_develop would be IMO better.

I also think that ?pysetup install --develop path/to/project? would be a nice high-level way to use develop, in the future.

About supporting setup.py develop: I think too that it is not needed.  Supporting setup.py install is a needed feature for *users*, as Alexis said; conversely, having a packaging-only develop feature can help seduce *developers* to use the new standards and tools.  My vote is for removing setup.py develop support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:54:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 17:54:09 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313684811.69.0.750186706718.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4D51C0.9070001@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> - "linux3" on Python <= 2.7.2 or Python <= 3.2.1
> - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3
> - "linux" on Python >= 3.3
> 
> I don't see how it will help backward or forward compatibility...

It's very easy to see. In the long term (ten years) Python 2 will
be gone, and so will be Linux 2. Linux 4 may be released.

If we continue with the current approach, we will have the same
problems again (as we already did when Linux 2 was released). If
we change to just "linux" now, it will have no effect when Linux 4
is released.

As for the cases where "linux3" is reported: I don't care that
they break. Python 2.6 and Python 2.7.2 is incompatible with
Linux 3. Users should be advised to a) not upgrade to Linux 3, or
b) simultaneously upgrade to a newer Python release, or
c) work-around in their applications.

I expect that most users chose a) for some time to come (until
the Linux distributions ship the new kernels), and that the Linux
distributions chose b) and c).

> Well, except maybe if you plan to write applications working only on
> Python >= 2.7.3? ... this version is not released yet.

With Python 2.7.3, people don't have the change their applications at
all. They just have to wait for the Linux upgrade until Python 2.7.3
is released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:58:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 17:58:26 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4D5051.1050407@v.loewis.de>
Message-ID: <1313690175.3602.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> > from "linux3" to "linux2". That breaks compatibility.
> 
> No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
> both linux2 and linux3, so it will continue just fine on 2.7.

Then, let's just advise that all code follow the same path and use
sys.platform.startswith() (which is really not a difficult change to
make).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 19:58:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 17:58:27 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313690307.35.0.358746698235.issue12765@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I can reproduce this.  With -vv, the only difference in os.environ is HOME:
  Before: 'HOME': '/Users/nad'
  After:  'HOME': '/tmp/tmpqryo48/tmpt_mcrw'

Also, Warning -- threading._dangling was modified by test_packaging
  Before: <_weakrefset.WeakSet object at 0x1019f0610>
  After:  <_weakrefset.WeakSet object at 0x1019f05a0>

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:00:35 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 18:00:35 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313690175.3602.17.camel@localhost.localdomain>
Message-ID: <4E4D5342.8030400@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Then, let's just advise that all code follow the same path and use
> sys.platform.startswith() (which is really not a difficult change to
> make).

Antoine, please accept that people want better backwards compatibility
than just recommendations how to rewrite applications. They want the
code to continue to work *unmodified*.

The proposed mechanism achieves this for the bug fix releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:07:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 18:07:46 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313690866.44.0.432299430137.issue12765@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  I?m not sure if it?s possible to use for example -vvG to stop regrtest right after the test that fails to restore HOME; when I fixed similar environ changes, I had to edit regrtest to make it fail early.

The culprit may be packaging.tests.test_database.TestDatabase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:12:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:12:25 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4D5342.8030400@v.loewis.de>
Message-ID: <1313691006.3602.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Then, let's just advise that all code follow the same path and use
> > sys.platform.startswith() (which is really not a difficult change to
> > make).
> 
> Antoine, please accept that people want better backwards compatibility
> than just recommendations how to rewrite applications.

You just said that "we" already had the same problem when Linux 2 was
released. So hopefully "people want better backwards compatibility"
would have learnt from that experience, and stopped hard-coding version
numbers.

Really, it's not difficult to understand that code testing for "linux2"
will stop working when "linux3" gets released. It's an obvious bug which
is also obvious to fix. Whether or not the Linux version numbering
scheme makes sense is a totally separate concern (which I agree may be
addressed by returning "linux" in 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:14:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:14:49 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313691289.14.0.909035831332.issue12778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch does the trick.

----------
keywords: +patch
Added file: http://bugs.python.org/file22942/jsonacc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:22:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 18:22:00 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1313691720.11.0.544874017336.issue12650@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
This should also fix the original problem.
Gabriele, thanks for the report.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:31:12 2011
From: report at bugs.python.org (Matthew Schwickerath)
Date: Thu, 18 Aug 2011 18:31:12 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
	GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1313692272.7.0.684733416036.issue7105@psf.upfronthosting.co.za>


Matthew Schwickerath <matthews at wilkeglobal.com> added the comment:

Any plans on actually patching this in 2.7 any time soon?  This is affecting our software and hanging it on random occasions.

----------
nosy: +qelan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7105>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:32:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:32:08 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1313687124.81.0.0770352701255.issue5845@psf.upfronthosting.co.za>
Message-ID: <1313692197.3602.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Updated patch (not using Mercurial, looks like I haven?t enough
> bandwidth to push all those changesets).

I think there's a bug in the way you are detecting interactive mode:

$ ./python -c "import sys; print(sys.stdin.isatty())"
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:34:19 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 18:34:19 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313691006.3602.26.camel@localhost.localdomain>
Message-ID: <4E4D5B2A.4040700@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You just said that "we" already had the same problem when Linux 2 was
> released. So hopefully "people want better backwards compatibility"
> would have learnt from that experience, and stopped hard-coding version
> numbers.

No, when Linux 2 was released (1996), Python didn't have the relevance
it has today. Most of the code referring to linux2 was probably written
after that date, and with the assumption that it may well be the final
major version Linux will ever get.

> Really, it's not difficult to understand that code testing for "linux2"
> will stop working when "linux3" gets released.

This doesn't matter. People will still complain. And, as there is an
obvious work-around, why not make people's lives easier?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:37:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:37:54 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1313692674.05.0.0224326448436.issue5845@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interestingly, there's already the following code in Modules/main.c:

    if ((Py_InspectFlag || (command == NULL && filename == NULL && module == NULL)) &&
        isatty(fileno(stdin))) {
        PyObject *v;
        v = PyImport_ImportModule("readline");
        if (v == NULL)
            PyErr_Clear();
        else
            Py_DECREF(v);
    }


...meaning readline already gets imported automatically when desired. And indeed:

$ ./python -S
Python 3.3.0a0 (default:50f1922bc1d5, Aug 18 2011, 00:09:47) 
[GCC 4.5.2] on linux2
>>> import sys
>>> sys.modules['readline']
<module 'readline' from '/home/antoine/cpython/default/build/lib.linux-x86_64-3.3-pydebug/readline.cpython-33dm.so'>


So perhaps we could simply change this code to import another, private module (e.g. "_setupinteractive.py") which would setup readline and rlcompleter?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:38:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:38:59 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4D5B2A.4040700@v.loewis.de>
Message-ID: <1313692608.3602.29.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Really, it's not difficult to understand that code testing for "linux2"
> > will stop working when "linux3" gets released.
> 
> This doesn't matter. People will still complain. And, as there is an
> obvious work-around, why not make people's lives easier?

At the cost of some additional confusion, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:41:19 2011
From: report at bugs.python.org (Oleg Oshmyan)
Date: Thu, 18 Aug 2011 18:41:19 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
	removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1313692879.97.0.304934195386.issue9850@psf.upfronthosting.co.za>


Oleg Oshmyan <chortos at inbox.lv> added the comment:

It is already tested but here is a new version of the patch that expands the existing test to cover the situation that was broken (plus another one).

----------
Added file: http://bugs.python.org/file22943/macpath_join_fix_with_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9850>
_______________________________________

From report at bugs.python.org  Thu Aug 18 20:43:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 18:43:11 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1313692991.24.0.630872501785.issue12720@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/issue12720>
_______________________________________

From report at bugs.python.org  Thu Aug 18 21:03:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Aug 2011 19:03:03 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313692608.3602.29.camel@localhost.localdomain>
Message-ID: <4E4D61E5.7010608@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>> Really, it's not difficult to understand that code testing for "linux2"
>>> will stop working when "linux3" gets released.
>>
>> This doesn't matter. People will still complain. And, as there is an
>> obvious work-around, why not make people's lives easier?
> 
> At the cost of some additional confusion, though.

As you can see, the compile-time nature of the current implementation
causes similar confusion (even to experienced users). With the proposed
solution, most people won't even notice that there is an issue, so they
won't be confused. When they migrate to 3.3, they notice the change, and
accept it as a new feature - and they notice the change regardless of
whether they run a 2.x or 3.x kernel.

With the alternative approach (linux3), people may continue to release
buggy applications for years and not even notice during testing as they
use a Python binary compiled on linux2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 21:45:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 18 Aug 2011 19:45:42 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313696742.62.0.924121922405.issue12765@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The culrpit is test_custom_pydistutils (packaging.tests.test_dist.MetadataTestCase)

Lib/packaging/tests/test_dist.py:379 & 386

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Thu Aug 18 23:19:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Aug 2011 21:19:33 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1313702373.81.0.646651533279.issue12394@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Just to clarify: I'm -1 on heuristics too; it's better to have some way of explicitly declaring the intention. I've no problem with e.g. the [scripts] section being used just for generated scripts, as long as there is a clear way of designating arbitrary .py/.pyw files as scripts in the [resources] section, which would have the shebang line transmutation applied during installation.

Re. the unwanted attachments - sorry, I don't normally use HTML email - I need to change the settings I was using.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Thu Aug 18 23:36:56 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 18 Aug 2011 21:36:56 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4D61E5.7010608@v.loewis.de>
Message-ID: <4E4D85EF.5000403@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Some thoughts:

 * We can't change the value of a system variable in a patch level
   release. It's not a bug and the change is not motivated by
   Python, but by the OS vendor. So changes to released versions
   are not possible. They are also not necessary - see the next bullet.

 * Porting to a new OS version is always an application level problem,
   not a programming language one; you cannot expect applications
   written for Linux 2.x to run without problems on 3.x - much like you
   cannot expect Python 2.x applications to run without problems
   on Python 3.x.

 * Removing the version number from the platform string should only
   be done in case a new variable gets introduced that provides the
   full version. Using the platform module would be possible, but
   can be expensive, so having this value as standard sys module
   variable is a better approach.

   Otherwise, removing the version is a good thing to do for
   Python 3.3 onwards.

 * The same change should be applied to *all* other platform strings,
   not only Linux, but the *BSDs and the others as well.

 * Application writers need to be made aware of the change, since
   sys.platform is not only used in Python programs, but also
   to build e.g. path names, file names, log ids, etc. etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Thu Aug 18 23:43:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 21:43:04 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1313703784.55.0.731642609103.issue12650@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Reopening.
The new tests are failing on solaris and Debian parallel buildbots:
http://www.python.org/dev/buildbot/all/builders/x86 debian parallel 3.x/builds/2734/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/sparc solaris10 gcc 3.x/builds/3528/steps/test/logs/stdio
"""
======================================================================
FAIL: test_zombie_fast_process_del (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 1519, in test_zombie_fast_process_del
    self.assertRaises(OSError, os.waitpid, pid, 0)
AssertionError: OSError not raised by waitpid
"""

I've no idea what's going on here...
This means that the child process didn't get reaped by _cleanup().
It could also maybe be due to the first child's PID being reused immediately by the second.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Thu Aug 18 23:46:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 18 Aug 2011 21:46:28 +0000
Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples
Message-ID: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004025.html here's a patch to add a notice about SO_REUSEADDR after the examples, so even re-running several times and getting that error, wont scare anyone.

----------
assignee: docs at python
components: Documentation
files: socket_resueaddr.patch
keywords: patch
messages: 142403
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Mention SO_REUSEADDR near socket doc examples
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22944/socket_resueaddr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12781>
_______________________________________

From report at bugs.python.org  Fri Aug 19 00:25:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Aug 2011 22:25:43 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <E1QuB1r-0008OQ-N3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 122f952add3c by Charles-Fran?ois Natali in branch '3.2':
Issue #12650: fix failures on some buildbots, when a subprocess takes a long
http://hg.python.org/cpython/rev/122f952add3c

New changeset a32ae2749cd1 by Charles-Fran?ois Natali in branch 'default':
Issue #12650: fix failures on some buildbots, when a subprocess takes a long
http://hg.python.org/cpython/rev/a32ae2749cd1

New changeset 5333ed548257 by Charles-Fran?ois Natali in branch '2.7':
Issue #12650: fix failures on some buildbots, when a subprocess takes a long
http://hg.python.org/cpython/rev/5333ed548257

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Fri Aug 19 00:32:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 22:32:06 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1313706726.54.0.502742353387.issue12650@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This means that the child process didn't get reaped by _cleanup().

The most likely cause is that when _cleanup() calls waitpid(pid, WNOHANG), the child process hasn't exited yet.
Since I had already set a rather high timeout to avoid this problem and we're only interested in checking that the child is correctly added to the _active list, I've removed the part of test_zombie_fast_process_del which checked that the child got collected when the next Popen instance is allocated (I added this check in test_leak_fast_process_del_killed, which doesn't have this timeout problem because the process gets killed).
I'll watch the buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Fri Aug 19 00:47:15 2011
From: report at bugs.python.org (James Y Knight)
Date: Thu, 18 Aug 2011 22:47:15 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313707635.65.0.525269972829.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which included a value which is completely irrelevant on Linux, and has now changed.

The bug here that should be fixed in release branches is that Python put the build-time linux major kernel version in sys.platform in the first place, instead of making it just be "linux". If anyone had a time machine, the right thing would be to go back in time and make Python never put the "2" there. But, since they're hard to come by (rumors to the contrary aside...), the best fix at this point is to retain consistency with earlier patch releases and force it to remain "linux2" no matter what.

Again, the number provides literally *no* useful information. You can compile Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will be "linux2" in that case). You can also compile python on a 3.x kernel and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than the 2 vs 3 encoded into a bunch of places inside Python, the two copies of python should be 100% identical.

So, there is also no need to provide this useless value under a different variable name.

BTW, all the above goes for everywhere Python uses "linux[23]" right now, such as pathnames, not just literally the value of sys.platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 00:55:49 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Aug 2011 22:55:49 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4D51C0.9070001@v.loewis.de>
Message-ID: <20110818185544.1950b20f@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 05:54 PM, Martin v. L?wis wrote:

>As for the cases where "linux3" is reported: I don't care that
>they break. Python 2.6 and Python 2.7.2 is incompatible with
>Linux 3. Users should be advised to a) not upgrade to Linux 3, or
>b) simultaneously upgrade to a newer Python release, or
>c) work-around in their applications.
>
>I expect that most users chose a) for some time to come (until
>the Linux distributions ship the new kernels), and that the Linux
>distributions chose b) and c).

In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
== 'linux3' so for all Pythons we still support, we're going to force it back
to 'linux2'.  This fixed all those broken packages without any of them needing
to be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 01:15:21 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 18 Aug 2011 23:15:21 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313707635.65.0.525269972829.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4D9CFC.9030602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

James Y Knight wrote:
> 
> James Y Knight <foom at users.sourceforge.net> added the comment:
> 
> M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which included a value which is completely irrelevant on Linux, and has now changed.

That's a details of how Linux is managed. In terms of releases,
it's a new major release.

> The bug here that should be fixed in release branches is that Python put the build-time linux major kernel version in sys.platform in the first place, instead of making it just be "linux". If anyone had a time machine, the right thing would be to go back in time and make Python never put the "2" there. But, since they're hard to come by (rumors to the contrary aside...), the best fix at this point is to retain consistency with earlier patch releases and force it to remain "linux2" no matter what.
> 
> Again, the number provides literally *no* useful information. You can compile Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will be "linux2" in that case). You can also compile python on a 3.x kernel and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than the 2 vs 3 encoded into a bunch of places inside Python, the two copies of python should be 100% identical.
> 
> So, there is also no need to provide this useless value under a different variable name.
>
> BTW, all the above goes for everywhere Python uses "linux[23]" right now, such as pathnames, not just literally the value of sys.platform.

Sure, you can compile and run Python on both versions of Linux, but what
if your application uses features that are only present in Linux 3.0
and later ?

BTW: The new attribute should contain the complete version number,
not just the major version. `uname -r` would provide a good start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 01:17:24 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 18 Aug 2011 23:17:24 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <20110818185544.1950b20f@resist.wooz.org>
Message-ID: <4E4D9D7C.8070701@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Barry A. Warsaw wrote:
> 
> Barry A. Warsaw <barry at python.org> added the comment:
> 
> On Aug 18, 2011, at 05:54 PM, Martin v. L?wis wrote:
> 
>> As for the cases where "linux3" is reported: I don't care that
>> they break. Python 2.6 and Python 2.7.2 is incompatible with
>> Linux 3. Users should be advised to a) not upgrade to Linux 3, or
>> b) simultaneously upgrade to a newer Python release, or
>> c) work-around in their applications.
>>
>> I expect that most users chose a) for some time to come (until
>> the Linux distributions ship the new kernels), and that the Linux
>> distributions chose b) and c).
> 
> In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
> == 'linux3' so for all Pythons we still support, we're going to force it back
> to 'linux2'.  This fixed all those broken packages without any of them needing
> to be changed.

Ah, those lazy Debian/Ubuntu folks again ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 02:51:00 2011
From: report at bugs.python.org (James Y Knight)
Date: Fri, 19 Aug 2011 00:51:00 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313715060.55.0.59098261673.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

> Sure, you can compile and run Python on both versions of Linux, but
> what if your application uses features that are only present in Linux
> 3.0 and later ?

This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39?two months earlier, 2.6.38 two months before that, 2.6.37?two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004.

> BTW: The new attribute should contain the complete version number,
> not just the major version. `uname -r` would provide a good start.

To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 03:33:19 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 19 Aug 2011 01:33:19 +0000
Subject: [issue8743] set() operators don't work with collections.Set instances
In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za>
Message-ID: <1313717599.06.0.924525065588.issue8743@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution: accepted -> 
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Fri Aug 19 03:36:40 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 19 Aug 2011 01:36:40 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1313717800.73.0.756777830145.issue2651@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Fri Aug 19 03:47:48 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 19 Aug 2011 01:47:48 +0000
Subject: [issue7433] MemoryView memory_getbuf causes segfaults,
	double call to tp_releasebuffer
In-Reply-To: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za>
Message-ID: <1313718468.65.0.789307351227.issue7433@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7433>
_______________________________________

From report at bugs.python.org  Fri Aug 19 03:51:11 2011
From: report at bugs.python.org (Julian Berman)
Date: Fri, 19 Aug 2011 01:51:11 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1313718671.59.0.975582141756.issue2651@psf.upfronthosting.co.za>


Changes by Julian Berman <Julian+Python.org at GrayVines.com>:


----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Fri Aug 19 04:10:17 2011
From: report at bugs.python.org (Julian Berman)
Date: Fri, 19 Aug 2011 02:10:17 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
Message-ID: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

Using multiple `with` statements across multiple lines does not support using parens to break them up:


with (open("a_really_long_foo") as foo,
      open("a_really_long_bar") as bar):
    pass

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "demo.py", line 19
    with (open("a_really_long_foo") as foo,
                                    ^
SyntaxError: invalid syntax


Also, without convoluting things, import also does not support doing so, and is the only other example I can think of of a compound statement that forces you to either be redundant or bite your teeth and use \, despite the fact that PEP 328 gave us parens for from imports.

(I did not find a discussion as to why import didn't grow it as well, so please correct me as I'm sure it must have been discussed before).

It's understandably a lot rarer to need multiple lines when importing, but it'd be nice if all compound statements uniformly allowed the same continuation syntax.

----------
components: Interpreter Core
messages: 142411
nosy: Julian
priority: normal
severity: normal
status: open
title: Multiple context expressions do not support parentheses for continuation across lines
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Aug 19 05:32:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 03:32:13 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QuFoa-0003xu-7g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d062d482642c by Eli Bendersky in branch '3.2':
Issue #12672: remove confusing part of sentence in documentation
http://hg.python.org/cpython/rev/d062d482642c

New changeset 558f2270cba8 by Eli Bendersky in branch 'default':
Merge from 3.2
http://hg.python.org/cpython/rev/558f2270cba8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Fri Aug 19 05:34:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 03:34:25 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QuFqi-00043X-AD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 893f858c600e by Eli Bendersky in branch '2.7':
Issue #12672: remove confusing part of sentence in documentation
http://hg.python.org/cpython/rev/893f858c600e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Fri Aug 19 05:34:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 19 Aug 2011 03:34:57 +0000
Subject: [issue12672] Some problems in documentation extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313724897.78.0.622910804311.issue12672@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12672>
_______________________________________

From report at bugs.python.org  Fri Aug 19 05:37:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 19 Aug 2011 03:37:19 +0000
Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313725039.34.0.193763705265.issue12781@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Wouldn't it be better to just add the flag to the example and then explain it in a few sentences?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12781>
_______________________________________

From report at bugs.python.org  Fri Aug 19 05:39:36 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 19 Aug 2011 03:39:36 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313725176.92.0.154184830871.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I have tried running the tests on a machine with 12GB of RAM, but when I do so,
the new tests get skipped saying "not enough memory", even when I specify "-M 11G"
on the command-line. The problem seems to be the change to the precisionbigmemtest
decorator in test.support. I don't understand what the purpose of the "dryrun"
flag is, but the modified condition for skipping doesn't look right to me.

(Now that I think about it, I should be able to get the tests to run by undoing
that one part of the change. I'll get back to you about the results later today.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 08:15:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 06:15:55 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <E1QuIN0-0006zy-3K@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 98d13885a574 by Vinay Sajip in branch '3.2':
Issue #12780: Removed checks in logging for .pyc/.pyo in __file__.
http://hg.python.org/cpython/rev/98d13885a574

New changeset ac0c04d8eafb by Vinay Sajip in branch 'default':
Issue #12780: Merged fix from 3.2.
http://hg.python.org/cpython/rev/ac0c04d8eafb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Fri Aug 19 09:50:16 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 07:50:16 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313715060.55.0.59098261673.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4E15AE.5060000@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

James Y Knight wrote:
> 
> James Y Knight <foom at users.sourceforge.net> added the comment:
> 
>> Sure, you can compile and run Python on both versions of Linux, but
>> what if your application uses features that are only present in Linux
>> 3.0 and later ?
> 
> This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39 two months earlier, 2.6.38 two months before that, 2.6.37 two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004.

I am aware of the history behind that version number change. The
difference between Linux 2.x and 3.x may be small nowadays, but
another 20 kernel releases down the road, the difference will show.

>> BTW: The new attribute should contain the complete version number,
>> not just the major version. `uname -r` would provide a good start.
> 
> To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name.

There are two aspects to consider:

1. The platform Python (and presumably the application) was
   compiled on.

2. The platform Python and the application are currently
   running on.

Both Python and the application will make certain assumptions about
the platform depending on the compile time environment. If the
deployment platform is too different from that environment, it
won't run or not as expected. So you need both the compile and the
runtime version information.

The suggested change removes the compile time information from
the platform string, so that information needs to be preserved
in a new attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 10:04:26 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 19 Aug 2011 08:04:26 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313741066.06.0.139876530965.issue12326@psf.upfronthosting.co.za>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

As people keep stating how easy the change from sys.platform == 'linux2' to sys.platform.startswith('linux') is, e.g. msg142385, please also keep in mind cases like someDict.get(sys.platform) where the comparison is implicit and therefore a simple change to startswith won't do the trick. Seen that in the wild.

Besides that, I can only wholeheartedly agree to the points so eloquently described by Martin v. L?wis and James Y Knight. Thanks!

Let's please force it to 'linux2' for the next 2.7 and 3.2 releases, so people can use recent kernels without breaking (or having to rewrite) third-party apps. Let's also encourage distros to do the same for older releases, perhaps even suggesting patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 10:14:12 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 19 Aug 2011 08:14:12 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4E15AE.5060000@egenix.com>
Message-ID: <4E4E1B51.3040602@gmx.net>


Martin von Gagern <Martin.vGagern at gmx.net> added the comment:

Marc-Andre Lemburg wrote:
> Both Python and the application will make certain assumptions about
> the platform depending on the compile time environment.

Can you give examples for this?

> So you need both the compile and the runtime version information.

I very much doubt that any feature in Python is actually enabled if
compiled under Linux 3. If so that's probably a bug in Python, due to
the small number of features added from 2.6.39 to 3.0. Either the
feature was introduced into Linux before 3.0, in which case Python
should use it as early as possible, or the feature was introduced in
some 3.x release, in which case not all Linux 3 builds will have it.

So the single digit major number will not be enough for this kind of
checks, and the safest way is to check for the feature itself, e.g. by
simply using it and handling NotImplementedException appropriately. That
approach is more portable for new platforms as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 11:09:40 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 09:09:40 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4E1B51.3040602@gmx.net>
Message-ID: <4E4E284B.7060504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin von Gagern wrote:
> 
> Martin von Gagern <Martin.vGagern at gmx.net> added the comment:
> 
> Marc-Andre Lemburg wrote:
>> Both Python and the application will make certain assumptions about
>> the platform depending on the compile time environment.
> 
> Can you give examples for this?

Sure, just have a look at how different the various minor release
Mac OS X versions are. They even changed the default architecture
without bumping the major version of the OS.

A configure run on one OS version will pick up different
environment settings than on a later one. As a result Python
and application extensions use different libs/packages/tools
or even create completely different runtimes (e.g. one for PPC,
the other for i386).

>> So you need both the compile and the runtime version information.
> 
> I very much doubt that any feature in Python is actually enabled if
> compiled under Linux 3. If so that's probably a bug in Python, due to
> the small number of features added from 2.6.39 to 3.0. Either the
> feature was introduced into Linux before 3.0, in which case Python
> should use it as early as possible, or the feature was introduced in
> some 3.x release, in which case not all Linux 3 builds will have it.
> 
> So the single digit major number will not be enough for this kind of
> checks, and the safest way is to check for the feature itself, e.g. by
> simply using it and handling NotImplementedException appropriately. That
> approach is more portable for new platforms as well.

That works fine for features that you can programmatically
control. It doesn't work well for static data that you provide
externally depending on the platform OS version. Take e.g.
the plat-freebsdN directories with the OS dependent
constants/functions as example.

As already mentioned, the diff between Linux 2.x and 3.x will
grow over time and while there may not be much to see now,
things will change in the coming years.

Just look at the differences between plat-linux1 and plat-linux2
(plat-linux1 was phased out in Python 2.4 so you have to go back
to Python 2.3 or earlier).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 11:31:42 2011
From: report at bugs.python.org (Kalev Lember)
Date: Fri, 19 Aug 2011 09:31:42 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1313746302.08.0.443959904586.issue10504@psf.upfronthosting.co.za>


Changes by Kalev Lember <kalevlember at gmail.com>:


----------
nosy: +kalev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Fri Aug 19 12:00:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 19 Aug 2011 10:00:21 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1313748021.32.0.452990897567.issue10293@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think PyBUF_SHADOW was the renamed version of PyBUF_UPDATEIFCOPY
from the PEP. :)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10293>
_______________________________________

From report at bugs.python.org  Fri Aug 19 12:27:04 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 19 Aug 2011 10:27:04 +0000
Subject: [issue12650] Subprocess leaks fd upon kill()
In-Reply-To: <1311861540.35.0.103521770573.issue12650@psf.upfronthosting.co.za>
Message-ID: <1313749624.22.0.215291954573.issue12650@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test now passes on the buildbots, closing.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12650>
_______________________________________

From report at bugs.python.org  Fri Aug 19 12:55:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 19 Aug 2011 10:55:28 +0000
Subject: [issue12783] test_posix failure on FreeBSD 6.4:
	test_get_and_set_scheduler_and_param
Message-ID: <1313751328.54.0.186872494969.issue12783@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1734/steps/test/logs/stdio

"""
======================================================================
ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_posix.py", line 878, in test_get_and_set_scheduler_and_param
    posix.sched_setparam(0, param)
OSError: [Errno 22] Invalid argument

----------------------------------------------------------------------
"""

The reason is quite simple:

http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/posix4/ksched.c.html

"""
/*
 * XXX About priorities
 *
 *	POSIX 1003.1b requires that numerically higher priorities be of
 *	higher priority.  It also permits sched_setparam to be
 *	implementation defined for SCHED_OTHER.  I don't like
 *	the notion of inverted priorites for normal processes when
 *  you can use "setpriority" for that.
 *
 *	I'm rejecting sched_setparam for SCHED_OTHER with EINVAL.
 */

[...]
int ksched_setparam(register_t *ret, struct ksched *ksched,
	struct proc *p, const struct sched_param *param)
{
	register_t policy;
	int e;

	e = getscheduler(&policy, ksched, p);

	if (e == 0)
	{
		if (policy == SCHED_OTHER)
			e = EINVAL;
		else
			e = ksched_setscheduler(ret, ksched, p, policy, param);
	}

	return e;
}

"""

And indeed, sched_setparam is implementation-defined if the process' scheduling policy is SCHED_OTHER, see http://pubs.opengroup.org/onlinepubs/007908799/xsh/sched_setparam.html
"""
If the current scheduling policy for the process specified by pid is not SCHED_FIFO or SCHED_RR, including SCHED_OTHER, the result is implementation-dependent.
"""

It seems that FreeBSD made the choice of returning EINVAL, but it changed in recent versions (the test passes on FreeBSD 8).

I'm not sure about the best solution though:
1) don't perform this test if the scheduling policy is not SCHED_RR or SCHED_FIFO
2) skip this test on FreeBSD versions that return EINVAL (maybe adding a new requires_freebsd_version to test.support)

----------
components: Tests
messages: 142423
nosy: benjamin.peterson, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12783>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:04:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:04:57 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1313755497.53.0.646473398248.issue12707@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> For these two reasons I propose to:
>  * document the 3 attributes as the suggested way to access this
>    information;
>  * deprecate the 3 getters;
>  * avoid to document the now undocumented getcode();
+1

> The addclosehook class could be provided via an alternative constructor
I can?t say why, but I don?t like that.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12707>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:18:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 12:18:27 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4E15AE.5060000@egenix.com>
Message-ID: <1313756175.3549.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The suggested change removes the compile time information from
> the platform string, so that information needs to be preserved
> in a new attribute.

-1 on any new platform identification attribute. We already have too
many of them, and there's the platform module for precise
identification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:23:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 12:23:03 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1313725176.92.0.154184830871.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313756451.3549.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have tried running the tests on a machine with 12GB of RAM, but when I do so,
> the new tests get skipped saying "not enough memory", even when I specify "-M 11G"
> on the command-line.

How much does it say is required?
Did you remove the skips in BigmemPickleTests?

>  The problem seems to be the change to the precisionbigmemtest
> decorator in test.support. I don't understand what the purpose of the "dryrun"
> flag is, but the modified condition for skipping doesn't look right to me.

Well, perhaps I got the logic wrong. Debugging welcome :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:25:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:25:14 +0000
Subject: [issue12256] Link isinstance/issubclass doc to abc module
In-Reply-To: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>
Message-ID: <E1QuO8K-0002iS-GX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eeb8a440bde0 by ?ric Araujo in branch '3.2':
Link isinstance/issubclass to the ABC glossary entry (#12256)
http://hg.python.org/cpython/rev/eeb8a440bde0

New changeset e2e8c752c1b6 by ?ric Araujo in branch '3.2':
Mention virtual subclasses in the glossary entry for ABCs (#12256).
http://hg.python.org/cpython/rev/e2e8c752c1b6

New changeset 5160d8eb3468 by ?ric Araujo in branch 'default':
Merge fixes for #12256 and typos from 3.2
http://hg.python.org/cpython/rev/5160d8eb3468

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12256>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:25:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:25:14 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <E1QuO8K-0002iS-H2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 59f7bbe1236c by ?ric Araujo in branch '3.2':
Remove obsolete term + indicate how to find the program (#1626300).
http://hg.python.org/cpython/rev/59f7bbe1236c

New changeset adaec1a0dd47 by ?ric Araujo in branch '3.2':
Fix instance I missed in 59f7bbe1236c (#1626300)
http://hg.python.org/cpython/rev/adaec1a0dd47

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:27:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:27:37 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1313756857.49.0.346907065492.issue10149@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I was about to commit an edited version of your patch (attached) but then I thought we should check whether this isn?t really a bug.  I just don?t see why expat would chunk without paying heed to the newlines if it is supposed to chunk at newlines.

----------
Added file: http://bugs.python.org/file22945/pyexpat.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:28:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:06 +0000
Subject: [issue12256] Link isinstance/issubclass doc to abc module
In-Reply-To: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>
Message-ID: <E1QuOBA-0002sS-Qg@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 96222062239f by ?ric Araujo in branch '2.7':
Link isinstance/issubclass to the ABC glossary entry (#12256)
http://hg.python.org/cpython/rev/96222062239f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12256>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:28:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:06 +0000
Subject: [issue10745] setup.py install --user option undocumented
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <E1QuOBA-0002sS-Qu@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 25a48fe791e6 by ?ric Araujo in branch '2.7':
Add documentation for PEP 370 features in distutils (#10745).
http://hg.python.org/cpython/rev/25a48fe791e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10745>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:28:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:07 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <E1QuOBA-0002sS-Qo@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b3f72b6450f1 by ?ric Araujo in branch '2.7':
Improve documentation for PEP 370 support in site module (#8617).
http://hg.python.org/cpython/rev/b3f72b6450f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8617>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:28:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:07 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <E1QuOBA-0002sS-R9@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e9022dc7a411 by ?ric Araujo in branch '2.7':
Remove obsolete term + indicate how to find the program (#1626300).
http://hg.python.org/cpython/rev/e9022dc7a411

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:35:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:35:02 +0000
Subject: [issue10745] setup.py install --user option undocumented
In-Reply-To: <1292883114.81.0.0146533387318.issue10745@psf.upfronthosting.co.za>
Message-ID: <1313757302.57.0.25401539964.issue10745@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils
nosy: +alexis
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10745>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:35:29 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 19 Aug 2011 12:35:29 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313757329.17.0.396098223637.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> How much does it say is required?
> Did you remove the skips in BigmemPickleTests?

Yes, I did remove the skips. It says 2GB for some, and 4GB for others.

> Well, perhaps I got the logic wrong. Debugging welcome :)

I'd be glad to do so, but I'm not sure what the aim of the "dryrun" flag is.
Do you want to make it the default that precisionbigmem tests are skipped,
unless the decorator invocation explicitly specifies dryrun=False?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:35:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:35:36 +0000
Subject: [issue8617] Better document user site-packages in site module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1313757336.71.0.468228027638.issue8617@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8617>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:36:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:36:48 +0000
Subject: [issue12256] Link isinstance/issubclass doc to abc module
In-Reply-To: <1307120125.95.0.344188720519.issue12256@psf.upfronthosting.co.za>
Message-ID: <1313757408.78.0.218497231661.issue12256@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I committed a modified version of the patch.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12256>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:38:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 12:38:35 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1313757329.17.0.396098223637.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313757382.3549.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'd be glad to do so, but I'm not sure what the aim of the "dryrun" flag is.
> Do you want to make it the default that precisionbigmem tests are skipped,
> unless the decorator invocation explicitly specifies dryrun=False?

No, the point is to avoid running these tests when -M is not specified.
See what happens with other bigmem tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:43:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:43:10 +0000
Subject: [issue9173] logger statement not guarded in shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1313757790.05.0.0282876734551.issue9173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I fixed this in 615a29295d5f but forgot to mention the bug number in the commit message.  To reproduce the bug, I only had to backport two lines from 3.2, so I did not use your patch.  Thanks to both of you nonetheless for the report and help!

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9173>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:45:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:45:55 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313757955.2.0.53850356217.issue12703@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:50:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 12:50:57 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1313758257.6.0.141976458927.issue12707@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I thought about having another class, but I couldn't come up with a decent name for it (ResponseWithCloseHook?).  After all it's still a Response and unless you need a way to distinguish responses with and without close hooks, I think it might be better to have a single class for both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12707>
_______________________________________

From report at bugs.python.org  Fri Aug 19 14:58:56 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Aug 2011 12:58:56 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1313758736.55.0.525286983031.issue10149@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fred at fdrake.net> added the comment:

Chunking of the data is expected with Expat.  There are no promises about *where* chunks are broken; the underlying behavior will break at line endings, but is not limited to that.

Setting buffer_text informs the Python wrapper that it's allowed to combine the chunks reported by the Expat library; this was made optional since it could affect working applications (changing the default with the move to Python 3 may have been acceptable, though).

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:10:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 13:10:48 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313759448.75.0.644480676706.issue12782@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson, ncoghlan
type: behavior -> feature request
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:12:24 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 13:12:24 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313756175.3549.0.camel@localhost.localdomain>
Message-ID: <4E4E612E.6010005@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> The suggested change removes the compile time information from
>> the platform string, so that information needs to be preserved
>> in a new attribute.
> 
> -1 on any new platform identification attribute. We already have too
> many of them, and there's the platform module for precise
> identification.

Please reread the quoted sentence:

The *compile time* version information needs to be preserved.

The platform module provide *run-time* information, but doesn't
give access to the compile time information.

We do have distutils to read the full compile time information,
but it's not always available, since it often requires installing
development packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:13:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 13:13:54 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313759634.39.0.61410713752.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> We do have distutils to read the full compile time information
We have sysconfig in the stdlib in 2.7 and 3.2+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:15:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 13:15:34 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313759734.34.0.475440521447.issue12682@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would say I find "accepted" little useful in practice. Removing it would avoid the confusion with its various (intended or not) meanings.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12682>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:16:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 13:16:58 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313759818.5.0.265649986064.issue12682@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

Martin, should we convert all the "accepted" to "fixed" before removing it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12682>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:19:26 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 13:19:26 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313759634.39.0.61410713752.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4E62D5.1040006@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
>> We do have distutils to read the full compile time information
> We have sysconfig in the stdlib in 2.7 and 3.2+.

Right (it originated in distutils), but it has the same problem:
without the Makefile and pyconfig.h files installed, it cannot
do its magic.

In addition to that it has the same problem as the platform module:
getting the information can be time and resource consuming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:24:17 2011
From: report at bugs.python.org (=?utf-8?q?K=C3=A5re_Krig?=)
Date: Fri, 19 Aug 2011 13:24:17 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
Message-ID: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>


New submission from K?re Krig <karekrig at gmail.com>:

When I concatenate two strings, with the one on the right hand side being large, the resulting string is almost correct but has a few chars substituted. 

The following code (with (...) added on the print statement for 3.1) prints False on both Python 2.6.5 & 3.1. The file I read is a 20Mb file of text.


inbuff = open('top.test.in')
full_file = inbuff.readlines()
inbuff.close()
data_string = ''.join(full_file)

buff_A = ' ' + data_string
buff_B = ' ' + data_string
print buff_A == buff_B 




I have only been able to test this on one computer, running SUSE. Ram seems fine as it passed 15h of memtest. 

Python versions are:

Python 2.6.5 (r265:79063, May  6 2011, 17:25:59) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2

Python 3.1 (r31:73572, Jul  5 2010, 13:31:53) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2

----------
components: None
messages: 142445
nosy: K?re.Krig
priority: normal
severity: normal
status: open
title: Concatenation of strings returns the wrong string
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:24:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 13:24:36 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4E612E.6010005@egenix.com>
Message-ID: <1313760143.3549.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please reread the quoted sentence:
> 
> The *compile time* version information needs to be preserved.

Then please give it a very explicit name, such as "sys.build_platform"
or "sys.compile_time_version_info". We don't want people to be misled by
yet another platform identification attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:27:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 13:27:38 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313760458.82.0.793995259285.issue12784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Have you tried with other large files? Or on another system?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:32:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2011 13:32:08 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313760728.78.0.527739979666.issue12784@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:32:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 13:32:47 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313760767.66.0.770794864881.issue12784@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/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:33:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 13:33:03 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1313760783.84.0.770084926143.issue12409@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From IRC:

<fdrake> After last being pressed on this, I got to thinking about it more.  Back in the day, that's all the doc there was about the tool-chain.  With Sphinx standing as a successful independent project, the tool documentation need no longer be part of any of the python.org docs; what's left probably can be moved.
<fdrake> (Yes, I'm withdrawing my objection.)

So, I am in favor of moving the Python-specific parts of Doc/documenting (if any) to the devguide and just link to the upstream Sphinx docs (which are a subset of our Doc/documenting) for the markup and suchlike.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:33:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2011 13:33:07 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313760787.26.0.0661786053364.issue12784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Try hash(buff_A) == hash(buff_B).

Are you able to identify which bytes/characters are differents?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:35:27 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 13:35:27 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313760143.3549.9.camel@localhost.localdomain>
Message-ID: <4E4E6696.6030302@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Please reread the quoted sentence:
>>
>> The *compile time* version information needs to be preserved.
> 
> Then please give it a very explicit name, such as "sys.build_platform"
> or "sys.compile_time_version_info". We don't want people to be misled by
> yet another platform identification attribute.

Good idea.

We could simply write `uname -s -r -m` into the new attribute:

sys.build_platform = ('Linux', '2.6.34.8-0.2-desktop', 'x86_64')

and then have

sys.platform = 'linux'

for quick general platform checks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:43:39 2011
From: report at bugs.python.org (James Y Knight)
Date: Fri, 19 Aug 2011 13:43:39 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313761419.27.0.415485940297.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:48:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 13:48:40 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1313761720.59.0.807411594466.issue12409@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Fri Aug 19 15:58:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 13:58:49 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313761419.27.0.415485940297.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4E6C10.6030803@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

James Y Knight wrote:
> 
> YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now?

Because it's been integrated to sys.platform for years and on many
platforms. If we now plan to remove it, the information has to be
available from somewhere else, hence the new attribute.

Note that I'm talking about removing it for all platforms, not just
Linux, which has had the major version 2 number for 15 years, but
also for FreeBSD which releases new major versions far more
frequently. The new attribute also helps on Mac OS X and Linux,
since it includes the minor version as well.

BTW: Your "forever" is a rather short time period - Python predates
Linux :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:07:24 2011
From: report at bugs.python.org (=?utf-8?q?K=C3=A5re_Krig?=)
Date: Fri, 19 Aug 2011 14:07:24 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313762844.03.0.439915960416.issue12784@psf.upfronthosting.co.za>


K?re Krig <karekrig at gmail.com> added the comment:

I tried it again with another file. This time I used the dictionary from www.math.sjsu.edu/~foster/dictionary.txt  (~3Mb)

hash(buff_A) == hash(buff_B)  returns False just like the direct comparison. I ran the program on dictionary.txt and printed buff_A & buff_B to two different files. When running diff on those files the reported differences where:

149668c149668
< intraisland
---
> intrqisland
150052c150052
< invernacular
---
> ynvernacular
230933c230933
< perwitsky
---
> perwitski


For my first run, then immediatly running the same script and doing diff again produced another set of differences

253803c253803
< recrown
---
> recrow~
254213c254213
< redisseise
---
> bedisseise
254656c254656
< reflectors
---
> beflectors
255083c255083
< regrating
---
> regratinw


Note how the ascii codes for the faulty characters only differ by one bit, and only the 5th least significant bit. This is consistent with my previous tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:09:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 14:09:53 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313762993.53.0.568208347037.issue12778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I actually looked into doing this for issue #12134, but it didn't seem 
> so simple; Since C has no yield, I think the iterator would need to
> maintain its own stack to keep track of where it is in the object tree 
> it's encoding...

The encoder doesn't have to be turned into an iterator. It would just need to call a given callable (fp.write) at regular intervals and that would be enough to C-accelerate dump().

My patch actually provides a good foundation for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:22:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 14:22:55 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313763775.47.0.356748925991.issue12784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note how the ascii codes for the faulty characters only differ by one
> bit, and only the 5th least significant bit.

This looks very much like a hardware issue.
Python usually does nothing special with the 5th bit of characters. Also, the IO system and string objects are different in 2.6 and 3.1, so witnessing the same behaviour under both versions points to a likely external cause.

Could you try on another system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:23:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2011 14:23:02 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313763782.74.0.432683872235.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong.

--

If I understood correctly, this issue has 3 remaining points:

(1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes:

Antoine Pitrou: -1
Victor Stinner: +0
Martin von Gagern: +1
Barry A. Warsaw: +1
Martin v. L?wis: +1
Marc-Andre Lemburg: +1

=> total=+3 (6 votes)

(2) Python 3.3: change sys.platform to 'linux'? Votes:

Martin v. L?wis: +1
Charles-Fran?ois Natali: -1
Amaury Forgeot d'Arc: -1
Antoine Pitrou: -0 ?
Victor Stinner: +1

=> total=0 (5 votes)

(3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform

--

For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571).

I prefer to do nothing for (1), but users usually prefer software that "just work". Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach.

--

For the second point, there is no consensus.

I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8).

--

For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2).

@Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature.

----------
Added file: http://bugs.python.org/file22946/configure_linux2.python3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:23:37 2011
From: report at bugs.python.org (Niko Wilbert)
Date: Fri, 19 Aug 2011 14:23:37 +0000
Subject: [issue12657] Cannot override JSON encoding of basic type subclasses
In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za>
Message-ID: <1313763817.1.0.875470380471.issue12657@psf.upfronthosting.co.za>


Niko Wilbert <mail at nikowilbert.de> added the comment:

This issue is also a real pain when using namedtuple. In many situations a namedtuple should be serialized as a dict, but there is no reasonable way to get this behavior.

Earlier solutions (e.g., see http://stackoverflow.com/questions/5906831/serializing-a-python-namedtuple-to-json) are now broken in Python 2.7.

----------
nosy: +nikow
versions: +Python 2.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12657>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:26:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Aug 2011 14:26:15 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313763975.65.0.0393608400438.issue12326@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

MAL wrote:

> As already mentioned, the diff between Linux 2.x and 3.x will
> grow over time and while there may not be much to see now,
> things will change in the coming years.

The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string.  If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux.

So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:32:12 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 19 Aug 2011 14:32:12 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313763782.74.0.432683872235.issue12326@psf.upfronthosting.co.za>
Message-ID: <20110819103205.13329eda@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 19, 2011, at 02:23 PM, STINNER Victor wrote:

>(2) Python 3.3: change sys.platform to 'linux'? Votes:
>
>Martin v. L?wis: +1
>Charles-Fran?ois Natali: -1
>Amaury Forgeot d'Arc: -1
>Antoine Pitrou: -0 ?
>Victor Stinner: +1
>
>=> total=0 (5 votes)

Please add my +1 to this tally.

>(3) Python 3.3: if point (2) is accepted, add a new variable providing more
>information about the build platform

I'm -0 on this.  I think we either have enough information already, or YAGNI.

>For the second point, there is no consensus.

Maybe I tipped it over. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:36:53 2011
From: report at bugs.python.org (James Y Knight)
Date: Fri, 19 Aug 2011 14:36:53 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313764613.16.0.636583006439.issue12326@psf.upfronthosting.co.za>


James Y Knight <foom at users.sourceforge.net> added the comment:

> configure_linux2.python3.2.patch

It would probably be more future-proof to use "linux*)", not "linux3)" in the case expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 16:57:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2011 14:57:05 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313765825.92.0.0150311368191.issue12784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You should retry memtest86+: http://www.memtest.org/#downiso

I had also memory errors recently. After 10 minutes, memtest86+ listed me 4 errors. After 30 minutes, there were 30 errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:03:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:03:28 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313766208.51.0.0894298027952.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Python 2.7 and 3.2: force sys.platform to 'linux2'?
-0.  I dislike this change for stable releases, but it?s a small change that would help a lot of users.  I think the release managers would need to approve such a change.

> Python 3.3: change sys.platform to 'linux'?
+1!

> Python 3.3: if point (2) is accepted, add a new variable providing
> more information about the build platform
-0.

BTW, your tallies are wrong: a +0 is more supportive than a -0, but your additions don?t show that.  :)

----------
nosy: +benjamin.peterson, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:30:40 2011
From: report at bugs.python.org (=?utf-8?q?K=C3=A5re_Krig?=)
Date: Fri, 19 Aug 2011 15:30:40 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313767840.72.0.0549853802649.issue12784@psf.upfronthosting.co.za>


K?re Krig <karekrig at gmail.com> added the comment:

I managed to get access to another two systems to test this on. One running ubuntu & python 2.7.1 and the other suse & python 2.6. I could not reproduce the bug on either of those systems.

This all points to the issue not really being a bug in python but something on my system.

The fact that I could predictably produce this bug using <20Mb of data, then pass 15 hours of memtest86+ and finally produce the bug again makes me think it's not the ram system, but there are of course layers between python and the ram that might be broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:32:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Aug 2011 15:32:43 +0000
Subject: [issue12784] Concatenation of strings returns the wrong string
In-Reply-To: <1313760257.69.0.91324509855.issue12784@psf.upfronthosting.co.za>
Message-ID: <1313767963.7.0.591585923704.issue12784@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's an hardware problem, not a Python problem, so I close this issue. Check your RAM and the temperature of your mother board and of the CPU using your tests (e.g. try lm-sensors on Linux).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12784>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:48:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 15:48:39 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <E1QuRJF-0004Fl-Fy@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 40f4a3d6a532 by ?ric Araujo in branch 'default':
Restore $HOME after test has run (should fix #12765)
http://hg.python.org/cpython/rev/40f4a3d6a532

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:49:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:49:31 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313768971.71.0.972105596991.issue12765@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you sir!  How did you find it?

----------
resolution:  -> fixed
stage: needs patch -> commit review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:55:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 15:55:03 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1313769303.04.0.0179228950809.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new version of the patch.
I decided to leave the prefix anyway, for consistency with what I'll commit to 3.3 and because without the prefix NEXT() looks ambiguous (and it's not entirely clear if it's private or not).
I rewrote the macro as Victor suggested and tested that it still works (I also added a test with surrogates).
The macros are now called _Py_UNICODE_IS_{LOW|HIGH}_SURROGATE, with '_'s.  I also tried the implementation proposed in #12751 and benchmarked with:
$ ./python -m timeit -s 's = "\uD800\uD8000\uDFFF\uDFFF\uDFFF"*1000' 's.islower()'
and got "1000 loops, best of 3: 345 usec per loop" on both, so I left the old version because I think it's more readable.
Finally, I rewrote the comment about the macro, adding a note about its side effects.

----------
stage: patch review -> commit review
versions: +Python 2.7, Python 3.3
Added file: http://bugs.python.org/file22947/issue9200-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:56:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:56:51 +0000
Subject: [issue12785] list_distinfo_file is wrong
Message-ID: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The list_distinfo_files method does not fulfills its mission.  I changed the test file to be more stupid (and therefore not use high-level functions that we can?t trust) when building the expected list and discovered that list_distinfo_files returned too many files!

I would need someone to test the attached patch on Windows to see if I need to replace '/' in self.path or not (the code before the XXX comment).

----------
assignee: eric.araujo
components: Distutils2
messages: 142469
nosy: alexis, eric.araujo, higery, michael.mulich
priority: high
severity: normal
stage: patch review
status: open
title: list_distinfo_file is wrong
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:57:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:57:29 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1313769449.55.0.730447085603.issue12785@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:57:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:57:40 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313769460.72.0.674496567271.issue12678@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +list_distinfo_file is wrong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Fri Aug 19 17:59:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 15:59:44 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313769584.59.0.904304074564.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t understand this part:

Traceback (most recent call last):
  File "distutils\tests\test_sdist.py", line 385, in test_manual_manifest
    archive = tarfile.open(archive_name)
  File "tarfile.py", line 1736, in open
    return func(name, "r", fileobj, **kwargs)
  File "tarfile.py", line 1806, in gzopen
    fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'

The code is protected by a skipUnless(ZLIB_SUPPORT), so how can the tarfile object be None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:05:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 16:05:55 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <E1QuRZy-0005yW-DU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 47176e8d7060 by Antoine Pitrou in branch 'default':
Issue #12778: Reduce memory consumption when JSON-encoding a large container of many small objects.
http://hg.python.org/cpython/rev/47176e8d7060

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:07:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 16:07:04 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1313770024.16.0.45289827272.issue12659@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made a review on Rietveld; a mail should have been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12659>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:08:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 16:08:33 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1313770113.27.0.799580975563.issue1492704@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  I made a review on Rietveld; a mail should have been sent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492704>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:09:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 16:09:39 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313770179.37.0.0185707816111.issue12778@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/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:21:59 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Aug 2011 16:21:59 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313770919.65.0.582638796134.issue12765@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I found it by patching the appropriate unittest test runner to check before and after each test case.  It would be nice if there were a standard option to do that.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:31:02 2011
From: report at bugs.python.org (Idan Kamara)
Date: Fri, 19 Aug 2011 16:31:02 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
Message-ID: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>


New submission from Idan Kamara <idankk86 at gmail.com>:

The following program hangs on Debian, Python 2.6.6:

import subprocess

proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)

proc1.stdin.close()
proc1.wait()

Changing the last two lines to:

proc2.stdin.close()
proc2.wait()

Doesn't hang. The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x.

----------
components: Library (Lib)
messages: 142475
nosy: Idan.Kamara
priority: normal
severity: normal
status: open
title: subprocess wait() hangs when stdin is closed
type: resource usage
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:41:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 16:41:52 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1313772112.66.0.215635319621.issue12786@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:48:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 19 Aug 2011 16:48:14 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313772494.67.0.0455053697475.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

D'oh. I just realized why the -M option wasn't being recognized - I had passed it
after the actual test name, so it was being treated as another test instead of an
option. Sorry for the confusion :/

As for the actual test results, test_huge_bytes_(32|64)b both pass, but
test_huge_str fails with this traceback:

    ======================================================================
    FAIL: test_huge_str (test.test_pickle.InMemoryPickleTests)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/usr/local/google/home/nadeemvawda/code/cpython/3.2/Lib/test/support.py", line 1108, in wrapper
        return f(self, maxsize)
      File "/usr/local/google/home/nadeemvawda/code/cpython/3.2/Lib/test/pickletester.py", line 1151, in test_huge_str
        self.dumps(data, protocol=proto)
    AssertionError: (<class 'ValueError'>, <class 'OverflowError'>) not raised

The same error occurs on the default branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 18:58:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 16:58:59 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1313772494.67.0.0455053697475.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313773006.3549.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> D'oh. I just realized why the -M option wasn't being recognized - I had passed it
> after the actual test name, so it was being treated as another test instead of an
> option. Sorry for the confusion :/
> 
> As for the actual test results, test_huge_bytes_(32|64)b both pass, but
> test_huge_str fails with this traceback:

Can you replace "_2G" with "_4G" in the decorator for that test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 19:03:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 19 Aug 2011 17:03:57 +0000
Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313773437.73.0.656635730425.issue12781@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sure it could be a solution, but I didn't go that way since it *may* complicate the example (which I see a something to get quick ready to test some code, there's always time for improvements later). I'm fine either way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12781>
_______________________________________

From report at bugs.python.org  Fri Aug 19 19:10:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 17:10:22 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313773822.91.0.211263717294.issue12213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think your expectations for BufferedRWPair are wrong. You should not use BufferedRWPair with the same underlying stream (that's the whole point of BufferedRWPair).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:01:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 19 Aug 2011 18:01:29 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1313776889.08.0.489551759635.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

version 7 here we come :) I've addressed Eric's commenta on rietveld (all but one, I need input from him) and also updated the tests for new helper functions.

----------
Added file: http://bugs.python.org/file22949/shutil_chown-default-v7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:01:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 19 Aug 2011 18:01:34 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1313776894.81.0.796951041731.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Can you replace "_2G" with "_4G" in the decorator for that test?

I'm not at work any more, but I'll try that out on Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:12:07 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 18:12:07 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313763782.74.0.432683872235.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4EA766.20209@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong.
> 
> --
> 
> If I understood correctly, this issue has 3 remaining points:
> 
> (1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes:
> 
> Antoine Pitrou: -1
> Victor Stinner: +0
> Martin von Gagern: +1
> Barry A. Warsaw: +1
> Martin v. L?wis: +1
> Marc-Andre Lemburg: +1

I voted -1 on this, not +1. For existing releases, we cannot change
the value of the sys variable and as explained this is not needed
either. IMHO, it's better to fix the few cases in Python that use
'linux2' to also include 'linux3' (either literally or via
.startswith()) and also add a plat-linux3/ dir.

> => total=+3 (6 votes)
> 
> (2) Python 3.3: change sys.platform to 'linux'? Votes:
> 
> Martin v. L?wis: +1
> Charles-Fran?ois Natali: -1
> Amaury Forgeot d'Arc: -1
> Antoine Pitrou: -0 ?
> Victor Stinner: +1

I voted +1 on this one.

I also suggested to apply the version removal to all platforms,
not just Linux.

> => total=0 (5 votes)
> 
> (3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform
> 
> --
> 
> For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571).
> 
> I prefer to do nothing for (1), but users usually prefer software that "just work". Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach.
> 
> --
> 
> For the second point, there is no consensus.
> 
> I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8).
> 
> --
> 
> For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2).
> 
> @Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature.

That would make sense, except that I view the removal of the
version and the addition of the compile time information as one
feature request. Moving this off to the sysconfig is not realistic
as mentioned before and the new variable doesn't really cost much
in terms maintenance, since it can be auto-generated by configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:14:14 2011
From: report at bugs.python.org (Ben Wolfson)
Date: Fri, 19 Aug 2011 18:14:14 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1313777654.59.0.535553163654.issue12786@psf.upfronthosting.co.za>


Ben Wolfson <wolfson at gmail.com> added the comment:

"The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x."

Really? This is on gentoo, not debian, admittedly:

coelacanth ~ 11:12:36 $ python3
Python 3.1.3 (r313:86834, May  1 2011, 09:41:48) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
>>> proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
>>> proc2.stdin.close()
>>> proc2.wait()
0
>>> 



coelacanth ~ 11:12:13 $ python3.1
Python 3.1.3 (r313:86834, May  1 2011, 09:41:48) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
>>> proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
>>> proc1.stdin.close()
>>> proc1.wait()

[hangs]

----------
nosy: +Ben.Wolfson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:14:18 2011
From: report at bugs.python.org (poq)
Date: Fri, 19 Aug 2011 18:14:18 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313777658.11.0.0279691971926.issue12778@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

> It would just need to call a given callable (fp.write) at regular intervals and that would be enough to C-accelerate dump().

True, but that would just special case dump(), just like dumps() is special-cased now. Ideally JSONEncoder.iterencode() would be accelerated, so you wouldn't need any special cases. Or deprecate iterencode() and replace it with a callback interface...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:15:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 19 Aug 2011 18:15:08 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313772112.7.0.669304302842.issue12786@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM11j=j=cK9nKhBuPmCGOAE+t4=zkNqi_8UU7+h=RiSU=w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello Idan,

> The following program hangs on Debian

Debian is a good choice :-)

Concerning your example, it hangs is because the file descriptor used
to communicate with proc1 is inherited when proc2 is created (FDs are
inherited upon fork by default): thus, when you call
proc1.stdin.close(), `cat` doesn't receive EOF on read(0), and remains
stuck.
If you close proc2's stdin and wait it first, then you don't have this problem:
- because it's been created after proc1, its stdin FD has not been inherited
- when you call proc2.stdin.close(), `cat` receives EOF from read(0), and exits

There are two reasons while it doesn't hang on Python 3.x:
1) it uses close_fds=True by default
2) it sets the pipe FDs CLOEXEC, so that they're closed when cat is `executed`

Try with
"""
proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE)
proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE, close_fds=True)

proc1.stdin.close()
proc1.wait()
"""

And you'll be fine.

We can't make the change 1) in 2.7, because that's a behavior change.
We could however set the FDs used to communicate with the children CLOEXEC.
I'll work on a patch for 2.7 (but it won't be thread-safe, because
pipe2 is not exposed and there's no _posixsubprocess.c like in 3.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:28:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 18:28:31 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313777658.11.0.0279691971926.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313778377.3549.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > It would just need to call a given callable (fp.write) at regular
> intervals and that would be enough to C-accelerate dump().
> 
> True, but that would just special case dump(), just like dumps() is
> special-cased now. Ideally JSONEncoder.iterencode() would be
> accelerated, so you wouldn't need any special cases. Or deprecate
> iterencode() and replace it with a callback interface...

Is iterencode() used much? I would think dump() and dumps() see the most
use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:33:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 18:33:25 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313778805.69.0.89898176935.issue12213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file22950/bufrandom.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Fri Aug 19 20:47:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 18:47:30 +0000
Subject: [issue1626300] 'Installing Python Modules' does not work for Windows
Message-ID: <1313779650.23.0.647868967385.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On my fresh install, double clicking *does* run the file as it should, but the window disappears immediately, erasing output and error tracebacks, unless one adds something like ``input("Hit Enter to quit") at the end of the script so the user can see any output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1626300>
_______________________________________

From report at bugs.python.org  Fri Aug 19 21:08:19 2011
From: report at bugs.python.org (poq)
Date: Fri, 19 Aug 2011 19:08:19 +0000
Subject: [issue12778] JSON-serializing a large container takes too much memory
In-Reply-To: <1313680996.25.0.799183861359.issue12778@psf.upfronthosting.co.za>
Message-ID: <1313780899.6.0.0112137517374.issue12778@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

> Is iterencode() used much? I would think dump() and dumps() see the most use.

Of course. I'd just prefer an elegant & complete solution. But I agree accelerating just dump() would already be much better than the current situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12778>
_______________________________________

From report at bugs.python.org  Fri Aug 19 21:25:04 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 19 Aug 2011 19:25:04 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313781904.93.0.65443501312.issue12326@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Note that PyPy is also affected by this issue; see https://bugs.pypy.org/issue832

For CPython, I'm of the opinion that:
  - the final digit of sys.platform as-is for "linux*" is effectively meaningless
  - that no code should be relying on the final digit of sys.platform (thankfully this is now recommended by: http://docs.python.org/library/sys.html#sys.platform )
  - unfortunately there is code out there that checks against "linux2" and thus does rely on this value
  - patching CPython to force this to read "linux2" may be necessary for some downstream distributors of Python, to maximize compatibility with such broken code.

For CPython, "sys.platform" currently reports on the difference between whether "uname" reported linux2 or linux3 at build time, which is currently meaningless (see msg142219 above about our chroot-ed build environment).

For example, in RHEL we may at some future time upgrade our build farm to linux 3, but still provision our build trees within it for linux 2; this may mean that our build farm starts reporting "linux3" when rebuilding security updates for python 2.2, 2.3, 2.4 or 2.6, even when building against kernel-2.*'s user-space.   If this happens, I'd be inclined to patch those builds of Python back to "linux2".  It would be entirely meaningless and only damaging for one of our security updates of, say, Python 2.2 to shift sys.platform from "linux2" to "linux3" simply because of the kernel that was running in the build environment (as opposed to the kernel headers exposed to the compiler, and other such aspects of the kernel exposed in user-space).

FWIW, my opinion is currently:
  - in 3.3, sys.platform on linux should be simply "linux"
  - for 2.7 and 3.2, sys.platform should be forced to "linux2" (and indeed, I anticipate doing this for earlier releases that I still maintain downstream)
  - existing documentation should say that on linux, sys.platform begins with "linux", and that programmers should avoid relying upon the suffix
  - I don't see the need for more adding access to more details of the build platform (and I can poke holes in any such plan, if anyone wants me to: what would it contain?  what about the case where the user-space files e.g. headers aren't the same as the uname?  etc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 21:27:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 19:27:47 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313782067.5.0.809147765497.issue12682@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Only if the issue is closed, so that it actually means 'fixed'.
Otherwise, just delete it.

The following data suggests to me that 'accepted' is a de facto synonym for 'fixed' and therefore useless and might as well be removed.
N     Issue category
3290  fixed
    68  open
  3219  closed
     354  feature request (and closed)
     302  behavior
     126  other type
    2437  type not specified
       346  documentation component (and type not specified)
       679  library component

The type field has been, at least in the past, greatly underused. But of the last 679, only 27 were in the last 3 years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12682>
_______________________________________

From report at bugs.python.org  Fri Aug 19 21:30:31 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Fri, 19 Aug 2011 19:30:31 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313782231.02.0.708315520379.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

I just made such a change to Python 2.7's argparse.
If there is interest I'll post a patch here.

Unfortunately I can't find the description how to produce a proper patch.
The link I found (http://www.python.org/dev/patches/) gives an error 404.

----------
nosy: +chriz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Fri Aug 19 22:14:40 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 20:14:40 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313763975.65.0.0393608400438.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E4EC420.8060207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> MAL wrote:
> 
>> As already mentioned, the diff between Linux 2.x and 3.x will
>> grow over time and while there may not be much to see now,
>> things will change in the coming years.
> 
> The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string.  If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux.

Indeed. See the sys.build_platform attribute we discussed.

> So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases?

I already mentioned those use cases. Please see the ticket discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 22:24:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 20:24:47 +0000
Subject: [issue12745] Python2 or Python3 page
In-Reply-To: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>
Message-ID: <1313785487.14.0.279690992833.issue12745@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with your sentiments about Python 2 while being aware that not all agree yet and that the current Wiki page was the result of some heated discussion and compromise. I also agree that the page could use tweaking/updating/rewriting. For one thing the supposed 2010 date in inconsistent with 3.2 being released.

"Python 3 is the future of the language." kind of implies that it is not the current version of the language. I would change that to "Python 3 is the present and future of the language"

I might start with discussion of 3 rather that 2.

I am closing this simply because it is not about changing the CPython repository, which is what the tracker tracks. There is no way to attach and review a wiki diff here.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12745>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:05:56 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 19 Aug 2011 21:05:56 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1313787956.61.0.513529675225.issue12786@psf.upfronthosting.co.za>


Changes by Mads Kiilerich <mads at kiilerich.com>:


----------
nosy: +kiilerix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:09:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Aug 2011 21:09:36 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1313759818.5.0.265649986064.issue12682@psf.upfronthosting.co.za>
Message-ID: <4E4ED10F.8040906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, should we convert all the "accepted" to "fixed" before removing it?

That's not strictly necessary. It would only be retired (roundup does
not support true removal), and as such would then still show up in
issues that currently use it, but not show up elsewhere anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12682>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:10:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Aug 2011 21:10:39 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313788239.04.0.312587486848.issue12678@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This failure needs to be gone in time for 3.2.2. Please find an appropriate way to fix it, even if it is the temporary disabling of a faulty test.

----------
nosy: +benjamin.peterson, georg.brandl
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:15:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 21:15:19 +0000
Subject: [issue12682] Meaning of 'accepted' resolution as documented in
	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313788519.9.0.355531766753.issue12682@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

OK, I removed the resolution and its documentation from the devguide in 3f4710b6baf9.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12682>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:16:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Aug 2011 21:16:22 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4EC420.8060207@egenix.com>
Message-ID: <4E4ED2A4.1040409@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> The only way I can read this argument that makes any sense to me is
>> that you are arguing for a precise build-time OS string.  If it is
>> supposed to be an argument in favor of keeping 'linux3' it makes no
>> sense, since '2' vs '3' is in no way a useful line of demarcation
>> when it comes to linux.

The build time Linux kernel has no effect on Python's build procedure
whatsoever. Python does not use the kernel at all for building; it
only uses the C library headers, and the kernel headers that happen
to be incorporated into the version of the C library installed. That
affects what features get selected during build time.

Notice that the proposed fix to keep os.platform to "linux2" actually
means that there is *no change*, as os.platform always was "linux2"
on the system. It is a bug that it reports "linux3" in some cases,
and that bug is being fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:28:36 2011
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 19 Aug 2011 21:28:36 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313789316.99.0.792772023217.issue12326@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

> The build time Linux kernel has no effect on Python's build procedure
> whatsoever. Python does not use the kernel at all for building; it
> only uses the C library headers, and the kernel headers that happen
> to be incorporated into the version of the C library installed. That
> affects what features get selected during build time.

would be very nice, but unfortunately this is not true; the multiprocessing behavior depends on configure checks testing the running kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Fri Aug 19 23:33:30 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Aug 2011 21:33:30 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E4ED2A4.1040409@v.loewis.de>
Message-ID: <4E4ED699.6040005@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>>> The only way I can read this argument that makes any sense to me is
>>> that you are arguing for a precise build-time OS string.  If it is
>>> supposed to be an argument in favor of keeping 'linux3' it makes no
>>> sense, since '2' vs '3' is in no way a useful line of demarcation
>>> when it comes to linux.
> 
> The build time Linux kernel has no effect on Python's build procedure
> whatsoever. Python does not use the kernel at all for building; it
> only uses the C library headers, and the kernel headers that happen
> to be incorporated into the version of the C library installed. That
> affects what features get selected during build time.

That last sentence contradicts the first one. In any case, you're right:
the OS build version does affect the Python build. And not only on
Linux, but on all OSes Python runs on.

That said, the changes on Linux that affect Python are minimal compared
to what other vendors do for even minor OS releases, e.g. Apple with
Mac OS X.

> Notice that the proposed fix to keep os.platform to "linux2" actually
> means that there is *no change*, as os.platform always was "linux2"
> on the system. It is a bug that it reports "linux3" in some cases,
> and that bug is being fixed.

There are Linux 2.x systems out there that report sys.platform ==
'linux3' ? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 00:34:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 19 Aug 2011 22:34:57 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1313793297.1.0.45359977924.issue12786@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch + test for 2.7.

> Really? This is on gentoo, not debian, admittedly:

That's because the change of close_fds to True by default and the CLOEXEC flag were added in 3.2.
Since 3.1 is in security-fix mode only, this patch is only relevant to 2.7.

----------
keywords: +needs review, patch
nosy: +haypo
stage:  -> patch review
versions:  -Python 2.6
Added file: http://bugs.python.org/file22951/subprocess_cloexec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Sat Aug 20 00:50:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 22:50:58 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1313794258.42.0.875776753601.issue12753@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that the test file raises the quoted SyntaxError on 3.2 on Win7. This:

>>> "\N{LATIN CAPITAL LETTER GHA}"
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-27: unknown Unicode character name

is most likely a result of this:

>>> unicodedata.lookup("LATIN CAPITAL LETTER GHA")
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    unicodedata.lookup("LATIN CAPITAL LETTER GHA")
KeyError: "undefined character name 'LATIN CAPITAL LETTER GHA'"

Although the lookup comes first in nametests.py, it is never executed because of the later SyntaxError.

The Reference for string literals says" 
"\N{name} Character named name in the Unicode database"

The doc for unicodedata says
"This module provides access to the Unicode Character Database (UCD) which defines character properties for all Unicode characters. The data contained in this database is compiled from the UCD version 6.0.0.

The module uses the same names and symbols as defined by Unicode Standard Annex #44, ?Unicode Character Database?." 
http://www.unicode.org/reports/tr44/tr44-6.html

So the question is, what are the 'names' therein defined?
All such should be valid inputs to 
"unicodedata.lookup(name) Look up character by name."

The annex refers to http://www.unicode.org/Public/6.0.0/ucd/
This contains NamesList.txt, derived from UnicodeData.txt. Unicodedata must be using just the latter. The ucd directory also contains NameAliases.txt, NamedSequences.txt, and the file of provisional named sequences.

As best I can tell, the annex plus files are a bit ambiguous as to  'Unicode character name'. The following quote seems neutral: "the Unicode Character Database (UCD), a collection of data files which contain the Unicode character code points and character names." The following: "Unicode character names constitute a special case. Formally, they are values of the Name property." points toward UnicodeData.txt, which lists the Name property along with others. However, "Unicode character name, as published in the Unicode names list," indirectly points toward including aliases. NamesList.txt says it contains the "Final Unicode 6.0 names list." (but one which "should not be parsed for machine-readable information". It includes all 11 aliases in NameAliases.txt. 

My current opinion is that adding the aliases might be done in current releases. It certainly would serve the any user who does not know to misspell 'FTHORA' as 'FHTORA' for just one of the 17 'FTHORA' chars.

Adding named sequences is definitely a feature request. The definition of .lookup(name) would be enlarged to "Look up character by name, alias, or named sequence" with reference to the specific files. The meaning of \N{} would also have to be enlarged.

Minimal test code might be:

from unicodedata import lookup
AssertEqual(lookup("LATIN CAPITAL LETTER GHA")), "\u01a2")
AssertEqual(lookup("LATIN CAPITAL LETTER A WITH MACRON AND GRAVE"),
   "\u0100\u0300")
plus a test that "\N{LATIN CAPITAL LETTER GHA}" and
"\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE}" compile without error (I have no idea how to write that).

---
> "If you look at the ICU UCharacter class, you can see that they provide a more"

More what ;-)
I presume ICU =International Components for Unicode, icu-project.org/
"Offers a portable set of C/C++ and Java libraries for Unicode support, software internationalization (I18N) and globalization (G11N)."
[appears to be free, open source, and possibly usable within Python]

----------
nosy: +terry.reedy
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Aug 20 00:53:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Aug 2011 22:53:11 +0000
Subject: [issue12772] fractional day attribute in datetime class
In-Reply-To: <1313597703.11.0.0103584159949.issue12772@psf.upfronthosting.co.za>
Message-ID: <1313794391.27.0.770303916066.issue12772@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

You can easily get the fractional day value using existing functionality:


>>> from datetime import *
>>> (datetime(2011,8,15,18,30) -  datetime(2011,8,13,12,0)) / timedelta(1)
2.2708333333333335
>>> (datetime(2011,8,15,18,30) -  datetime(1970,1,1)) / timedelta(1)
15201.770833333334

In some sense this request is a duplicate of issue2736.

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12772>
_______________________________________

From report at bugs.python.org  Sat Aug 20 01:02:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 23:02:42 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313794962.15.0.578908481397.issue12775@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is in security fix only mode and the OP agrees not applicable to current

----------
nosy: +terry.reedy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Sat Aug 20 01:02:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 19 Aug 2011 23:02:40 +0000
Subject: [issue12787] xmlrpc.client documentation (MultiCall Objects) points
	to a broken link
Message-ID: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

following up http://mail.python.org/pipermail/docs/2011-March/003506.html , I verified that indeed

http://www.xmlrpc.com/discuss/msgReader$1208

is broken. I wrote to dave at scripting.com (the address you get when viewing http://www.xmlrpc.com/discuss/) on march and just now I re-wrote again, but I got no reply and the link is still broken.

I tried finding another source for the same doc, but it seems it's only available on xmlrpc.com (or some other dead links). I found, tho, the relative article on the wayback machine:

http://web.archive.org/web/20060624230303/http://www.xmlrpc.com/discuss/msgReader$1208?mode=topic

Now, what should we do about this? remove the link completely? but then how can a user find information about multicalls? should we incorporate that article in our doc (do the licences allow us?)?

Cheers,
Sandro

----------
assignee: docs at python
components: Documentation
messages: 142504
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: xmlrpc.client documentation (MultiCall Objects) points to a broken link
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12787>
_______________________________________

From report at bugs.python.org  Sat Aug 20 01:26:18 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 19 Aug 2011 23:26:18 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313794258.42.0.875776753601.issue12753@psf.upfronthosting.co.za>
Message-ID: <27236.1313796370@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

"Terry J. Reedy" <report at bugs.python.org> wrote
   on Fri, 19 Aug 2011 22:50:58 -0000: 

> My current opinion is that adding the aliases might be done in current
> releases. It certainly would serve the any user who does not know to
> misspell 'FTHORA' as 'FHTORA' for just one of the 17 'FTHORA' chars.

Yes, I think the 11 aliases pose no problem.  It's amazing the trouble
you get into from having a fat-fingered amanuesis typing your laws 
into indelible stone tablets.

> Adding named sequences is definitely a feature request. The definition
> of .lookup(name) would be enlarged to "Look up character by name,
> alias, or named sequence" with reference to the specific files. The
> meaning of \N{} would also have to be enlarged.

But these do.  The problem is bracketed character classes.  
Yes, if you got named reference into the regex compiler as a raw
string, it could in theory rewrite

    [abc\N{seq}] 

as 

    (?:[abc]|\N{seq})

but that doesn't help if the sequence got replaced as a string escape.
At which point you have different behavior in the two lookalike cases.

If you ask how we do this in Perl, the answer is "poorly".  It really only
works well in strings, not charclasses, although there is a proposal to do
a rewrite during compilation like I've spelled out above.  Seems messy for
something that might(?) not get much use.  But it would be nice for \N{} to
work to access the whole namespace without prejudice.  I have a feeling
this may be a case of trying to keep one's cake and eating it too, as
the two goals seem to rule each other out.

>> "If you look at the ICU UCharacter class, you can see that they provide a more"

> More what ;-)

More expressive set of lookup functions where it is clear which thing
you are getting.  I believe the ICU regexes only support one-char returns
for \N{...}, not multis per the sequences.  But I may not be looking
at the right docs for ICU; not sure.

> I presume ICU =International Components for Unicode, icu-project.org/
> "Offers a portable set of C/C++ and Java libraries for Unicode support,
> software internationalization (I18N) and globalization (G11N)." [appears
> to be free, open source, and possibly usable within Python]

Well, there are some Python bindings for ICU that I was eager to try out,
because I wanted to see whether I couild get at full/real Unicode collation
that way, but I had trouble getting the Python bindings to compile.  Not
sure why.  The documentation for the Python bindings isn't very um wordy,
and it isn't clear how tightly integrated it all is: there's talk about C++
strings that kind of scares me. :)

Hm, and maybe they are only for Python 2 not Python 3, which I try to do
all my Python stuff in because it seems like it has a better Unicode model.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Aug 20 01:36:45 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 19 Aug 2011 23:36:45 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1313797005.69.0.593629032079.issue12753@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

For the "Line_Break" property, one of the possible values is "Inseparable", with 2 permitted aliases, the shorter "IN" (which is reasonable) and "Inseperable" (ouch!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Aug 20 01:57:42 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 19 Aug 2011 23:57:42 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313797005.69.0.593629032079.issue12753@psf.upfronthosting.co.za>
Message-ID: <31486.1313798244@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Matthew Barnett <report at bugs.python.org> wrote
   on Fri, 19 Aug 2011 23:36:45 -0000: 

> For the "Line_Break" property, one of the possible values is
> "Inseparable", with 2 permitted aliases, the shorter "IN" (which 
> is reasonable) and "Inseperable" (ouch!).

Yeahy, I've shaken my head at that one, too.

It's one thing to make an alias for something you typo'd in the first 
place, but to have something that's correct which you then make a typo 
alias for is just encouraging bad/sloppy/wrong behavior.

    Bidi_Class=Paragraph_Separator
    Bidi_Class=Common_Separator
    Bidi_Class=European_Separator
    Bidi_Class=Segment_Separator
    General_Category=Line_Separator
    General_Category=Paragraph_Separator
    General_Category=Separator
    General_Category=Space_Separator
    Line_Break=Inseparable
    Line_Break=Inseperable

And there's still set, which makes you wonder
why they couldn't spell at least *one* of them out:

    Sentence_Break=Sep SB=SE
    Sentence_Break=Sp  SB=Sp

You really have to look those up to realize they're two different things:

    SB ; SE        ; Sep
    SB ; SP        ; Sp

And that none of them have something like SB=Space or SB=Separator
so you know what you're talking about.  Grrr.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Sat Aug 20 02:36:53 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 20 Aug 2011 00:36:53 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313800613.42.0.412579165664.issue12678@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

The failure was due to the sdist command having different default formats for each platform (i.e., POSIX: gztar, Win32: zip).  Patch attached.

----------
keywords: +patch
nosy: +jkloth
Added file: http://bugs.python.org/file22952/test_sdist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sat Aug 20 03:07:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 01:07:22 +0000
Subject: [issue12788] test_email fails with -R
Message-ID: <1313802442.52.0.218487753455.issue12788@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m test -R 3:2 test_email
[1/1] test_email
beginning 5 repetitions
12345
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_email/test_policy.py", line 136, in test_overriden_register_defect_works
    self.assertEqual(my_policy.defects, [defect1])
AssertionError: Lists differ: [MyDefect('one',), MyDefect('t... != [MyDefect('one',)]

First differing element 0:
one
one

First list contains 2 additional elements.
First extra element 1:
two

- [MyDefect('one',), MyDefect('two',), MyDefect('one',)]
+ [MyDefect('one',)]

1 test failed:
    test_email

----------
components: Library (Lib), Tests
messages: 142510
nosy: barry, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_email fails with -R
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12788>
_______________________________________

From report at bugs.python.org  Sat Aug 20 05:13:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=82ngelo_Ot=C3=A1vio_Nuffer_Nunes?=)
Date: Sat, 20 Aug 2011 03:13:59 +0000
Subject: [issue12789] re.Scanner don't support more then 2 groups on regex
Message-ID: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>


New submission from ?ngelo Ot?vio Nuffer Nunes <angelonuffer at gmail.com>:

When I use the scanner object in re module, I can create groups on regex and associate this to a method...


In [17]: re.Scanner([(r"(\w)(\w)\w", foo)])
Out[17]: <re.Scanner instance at 0x15c4e60>


But I tryed 3 groups and it raises "invalid SRE code", but I think my regex is not wrong...


In [15]: scan = re.Scanner([(r"(\w)(\w)(\w)", foo)])
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/angelo/<ipython console> in <module>()

/usr/lib/python2.7/re.pyc in __init__(self, lexicon, flags)
    305         s.groups = len(p)+1
    306         p = sre_parse.SubPattern(s, [(BRANCH, (None, p))])
--> 307         self.scanner = sre_compile.compile(p)
    308     def scan(self, string):
    309         result = []

/usr/lib/python2.7/sre_compile.pyc in compile(p, flags)
    520     return _sre.compile(
    521         pattern, flags | p.pattern.flags, code,
    522         p.pattern.groups-1,
--> 523         groupindex, indexgroup
    524         )

RuntimeError: invalid SRE code

----------
components: Regular Expressions
messages: 142511
nosy: angelonuffer
priority: normal
severity: normal
status: open
title: re.Scanner don't support more then 2 groups on regex
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 05:54:33 2011
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 20 Aug 2011 03:54:33 +0000
Subject: [issue12790] doctest.testmod does not run tests in functools.partial
	functions
Message-ID: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Functions with docstrings which were created with partial are not run by doctest.testmod().

See the test script, which prints:

Expected 1 failure from 2 tests, but got 0 from 0.

----------
files: partial_doctest.py
messages: 142512
nosy: stevenjd
priority: normal
severity: normal
status: open
title: doctest.testmod does not run tests in functools.partial functions
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22953/partial_doctest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12790>
_______________________________________

From report at bugs.python.org  Sat Aug 20 07:36:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Aug 2011 05:36:36 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1313818596.32.0.81466412206.issue12765@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Sat Aug 20 07:40:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Aug 2011 05:40:30 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313818830.9.0.890680329898.issue12713@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

http://docs.python.org/devguide/patch.html

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sat Aug 20 08:03:26 2011
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Aug 2011 06:03:26 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1313820206.83.0.0724967152182.issue11397@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Another infinite loop that isn't caught in Python 3.2.1: With the symbolic link
    link => link/inside
a readlink("link") call will keep looping.

Anyhow, the proposed solution in issue11397_py32_2.patch does not account for paths with multiple independent references to the same link. Example link:
    here => .
Calling readlink("here/here") for me should return "/media/disk/home/vadmium" (my current directory, containing the "here" link), but the proposed version returns an "/media/disk/home/vadmium/here/here" (incompletely resolved).

I suggest something similar to "realpath_link_stack.py" I am attaching. I think the main difference is it pops each link off the cycle-detection stack after it has been resolved.

----------
nosy: +vadmium
Added file: http://bugs.python.org/file22954/realpath_link_stack.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Sat Aug 20 08:37:56 2011
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Aug 2011 06:37:56 +0000
Subject: [issue12791] Yield" leaks exception being handled as garbage
Message-ID: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>


New submission from Martin Panter <vadmium+py at gmail.com>:

See attached "leaky_generator.py" demo. Python doesn't appear to delete the exception variable if an exception is thrown back into it (via "throw", "close" or by deleting it). The result is a reference cycle that needs garbage collecting. This even happens when no exception variable is named. The exception variable is not leaked if the generator is called normally (via "next" or "send").

The exception variable of an exception handler is usually deleted (according to http://docs.python.org/py3k/reference/compound_stmts.html#the-try-statement) as soon as the handler is exited, even when it is not exited by simply falling through the end. So either this should also happen for "yield" inside the exception handler, or it should be documented that "yield" inside "except", even without "as", should be avoided.

I'm guessing this issue is specific to Python 3 because it exists for me in Python 3.2, 3.2.1 (both on Arch Linux) and 3.1.2 (Ubuntu) but not Python 2.7.1, 2.7.2 (Arch) nor 2.6.5 (Ubuntu).

----------
components: Interpreter Core
files: leaky_generator.py
messages: 142515
nosy: vadmium
priority: normal
severity: normal
status: open
title: Yield" leaks exception being handled as garbage
type: resource usage
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22955/leaky_generator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 09:16:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 07:16:48 +0000
Subject: [issue12787] xmlrpc.client documentation (MultiCall Objects) points
	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <1313824608.81.0.337652721933.issue12787@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

AFAIU xmlrpclib.MultiCall implements the technique described on the broken link, and the examples look pretty clear to me, so the user doesn't have to follow the link to understand how to use it.
I think it's good to keep a link around, in case the user wants to understand better how it works, but it could also be in a footnote.

This is what I would do:
  1) write something like "The xmlrpc.MultiCall object provides a way to  encapsulate multiple calls to a remote server into a single request?."
  2) in the footnote write something like "[1]: This approach has been first presented in `a discussion on xmlrpc.com <link-to-web.archive.org>`_."

Possibly you could leave an rst comment explaining that the original link is down and that we are using the web.archive.org one until the page is back up.
FWIW http://www.xmlrpc.com/discuss/topics seems to work, and there are a few discussions from last month, but the links are broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12787>
_______________________________________

From report at bugs.python.org  Sat Aug 20 09:30:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Aug 2011 07:30:22 +0000
Subject: [issue12791] Yield" leaks exception being handled as garbage
In-Reply-To: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>
Message-ID: <1313825422.67.0.00726874535314.issue12791@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 10:15:43 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Aug 2011 08:15:43 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1313828143.03.0.467382909709.issue6584@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

The attached patch follows Ezio's hints.

----------
nosy: +maker
Added file: http://bugs.python.org/file22956/6584_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Sat Aug 20 10:49:56 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Sat, 20 Aug 2011 08:49:56 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313830196.85.0.96288261124.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

I attached a patch against argparse.py from Python 2.7.1.

Subcommmands can now be abbreviated as long as they are unambiguous.
Otherwise an error message 'ambigous choice' will be thrown (like the 'invalid choice' one).

(It's my first patch, so hopefully I did it right.)

BTW: ?ric mentioned aliases for argparse. 
For that I have done a patch too. 
I'll try to find the appropriate issue number here to post it.

----------
keywords: +patch
Added file: http://bugs.python.org/file22957/abbrev_subcmds.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sat Aug 20 10:50:49 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 08:50:49 +0000
Subject: [issue12789] re.Scanner don't support more then 2 groups on regex
In-Reply-To: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>
Message-ID: <1313830249.69.0.520913519647.issue12789@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 11:02:39 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Sat, 20 Aug 2011 09:02:39 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313830959.8.0.445106217232.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

Since there seems to be no means to edit (my last) message a little followup regarding aliases:

I found http://bugs.python.org/issue9234 
"argparse: aliases for positional arguments (subparsers)"

That one is for version 3.2 and already closed. 
So I'll stop bugging here with aliases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sat Aug 20 11:03:31 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Aug 2011 09:03:31 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1313831011.18.0.916979080575.issue6584@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file22958/6584_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Sat Aug 20 11:50:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 09:50:36 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
Message-ID: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The attached patch adds documentation for the "type" field of the tracker to the devguide/triaging page.
This is also related to the meta issue #393 [0].

[0]: http://psf.upfronthosting.co.za/roundup/meta/issue393

----------
assignee: ezio.melotti
components: Devguide
files: issue12792.diff
keywords: patch
messages: 142520
nosy: eric.araujo, ezio.melotti, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Document the "type" field of the tracker in the devguide
Added file: http://bugs.python.org/file22959/issue12792.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sat Aug 20 12:37:01 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Aug 2011 10:37:01 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1313836621.3.0.795529810754.issue6669@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Would it be better to use TarError as Sridhar suggested, or create a new class BadTarfile(TarError, IOError), following the convention used for gzip and zipfile?

----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Sat Aug 20 13:46:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 11:46:37 +0000
Subject: [issue12791] reference cycle with exception state not broken by
	generator.close()
In-Reply-To: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>
Message-ID: <1313840797.26.0.864938175313.issue12791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem is probably that the frame keeps the last execution state around, and since the exception itself has a reference to a frame, a cycle is created. Note that it doesn't happen if you catch the GeneratorExit that gets raised inside the generator at shutdown:

def leaky_generator():
    try:   
        1/0
    except:  # Exception handler with anonymous exception variable
        try:
            yield  # Yield from exception handler
        except (GeneratorExit, RuntimeError):
            pass

def throw_leaks(g):
    try:
        g.throw(RuntimeError())
    except Exception:
        pass

----------
nosy: +benjamin.peterson, ncoghlan
title: Yield" leaks exception being handled as garbage -> reference cycle with exception state not broken by generator.close()
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 13:52:54 2011
From: report at bugs.python.org (Jacek Pliszka)
Date: Sat, 20 Aug 2011 11:52:54 +0000
Subject: [issue12793] allow filters in os.walk
Message-ID: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>


New submission from Jacek Pliszka <jacek.pliszka at gmail.com>:

I suggest a small change in os.walk module.  

Instead of:
def walk(top, topdown=True, onerror=None, followlinks=False):

I would like to have:
def walk(top, topdown=True, onerror=None, skipnames=lambda x : False, skipdirs=islink):

Implementation might be as follows:

<         if isdir(join(top, name)):
---
>         fullname=join(top, name)
>         if skipnames(fullname):
>             continue
>         if isdir(fullname):

and:

<         if followlinks or not islink(new_path):
<             for x in walk(new_path, topdown, onerror, followlinks):
---
>         if not skipdirs(new_path):
>             for x in walk(new_path, topdown, onerror, skipnames, skipdirs):

This is a small change, breaks a bit 'followlinks' option but gives
much more flexibility as skipnames and skidirs can be any 
functions (including ones using regexp and similar).

----------
components: Library (Lib)
files: os.diff
keywords: patch
messages: 142523
nosy: Jacek.Pliszka
priority: normal
severity: normal
status: open
title: allow filters in os.walk
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file22960/os.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12793>
_______________________________________

From report at bugs.python.org  Sat Aug 20 13:53:19 2011
From: report at bugs.python.org (Jacek Pliszka)
Date: Sat, 20 Aug 2011 11:53:19 +0000
Subject: [issue12793] allow filters in os.walk
In-Reply-To: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>
Message-ID: <1313841199.31.0.155826159992.issue12793@psf.upfronthosting.co.za>


Changes by Jacek Pliszka <jacek.pliszka at gmail.com>:


----------
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12793>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:02:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 12:02:54 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QukGL-0001nO-5b@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 800d45e51dd7 by Victor Stinner in branch '3.2':
Issue #12326: sys.platform is now always 'linux2' on Linux
http://hg.python.org/cpython/rev/800d45e51dd7

New changeset c816479f6aaf by Victor Stinner in branch '2.7':
Issue #12326: sys.platform is now always 'linux2' on Linux
http://hg.python.org/cpython/rev/c816479f6aaf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:07:58 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Aug 2011 12:07:58 +0000
Subject: [issue12793] allow filters in os.walk
In-Reply-To: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>
Message-ID: <1313842078.21.0.734480360625.issue12793@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/issue12793>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:11:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 12:11:59 +0000
Subject: [issue12791] reference cycle with exception state not broken by
	generator.close()
In-Reply-To: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>
Message-ID: <1313842319.67.0.429067464086.issue12791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file22961/genexcstate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:20:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 12:20:47 +0000
Subject: [issue12791] reference cycle with exception state not broken by
	generator.close()
In-Reply-To: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>
Message-ID: <E1QukXd-0002yx-NZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 867ce75b885c by Antoine Pitrou in branch '3.2':
Issue #12791: Break reference cycles early when a generator exits with an exception.
http://hg.python.org/cpython/rev/867ce75b885c

New changeset 7d390c3a83c6 by Antoine Pitrou in branch 'default':
Issue #12791: Break reference cycles early when a generator exits with an exception.
http://hg.python.org/cpython/rev/7d390c3a83c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:21:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 12:21:11 +0000
Subject: [issue12791] reference cycle with exception state not broken by
	generator.close()
In-Reply-To: <1313822276.28.0.844478703688.issue12791@psf.upfronthosting.co.za>
Message-ID: <1313842871.21.0.805761732274.issue12791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the report, fixed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12791>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:54:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 12:54:24 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <E1Qul4A-0005DW-3m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5330af45f777 by Antoine Pitrou in branch '3.2':
Issue #12213: Fix a buffering bug with interleaved reads and writes that
http://hg.python.org/cpython/rev/5330af45f777

New changeset d7f6391954cf by Antoine Pitrou in branch 'default':
Issue #12213: Fix a buffering bug with interleaved reads and writes that
http://hg.python.org/cpython/rev/d7f6391954cf

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 14:55:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 12:55:08 +0000
Subject: [issue12213] BufferedRandom: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313844908.99.0.666257472356.issue12213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should be fixed for BufferedRandom. As I said, I don't think BufferedRWPair is buggy.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
title: BufferedRandom, BufferedRWPair: issues with interlaced read-write -> BufferedRandom: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 15:16:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 13:16:22 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1313773822.91.0.211263717294.issue12213@psf.upfronthosting.co.za>
Message-ID: <4E4FB39F.8030807@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> You should not use BufferedRWPair with the same underlying stream (that's the whole point of BufferedRWPair).

It might be documented. Something like "Warning: don't use the same 
stream as reader and writer, or the BufferedRWPair becomes inconsistent 
on interlaced read-write" ?

----------
status: pending -> open
title: BufferedRandom: issues with interlaced read-write -> BufferedRandom,	BufferedRWPair: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 15:17:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 13:17:46 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313846266.0.0.382897854963.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm working on a patch to remove the major version of sys.platform. The patch is much bigger than expected. You will see when it will be done :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 15:43:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 13:43:18 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <E1QulpV-0000A8-BS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cf2010e9f941 by Antoine Pitrou in branch '2.7':
Issue #12213: Fix a buffering bug with interleaved reads and writes that
http://hg.python.org/cpython/rev/cf2010e9f941

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 16:03:39 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Sat, 20 Aug 2011 14:03:39 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313849019.61.0.163718243645.issue12703@psf.upfronthosting.co.za>


R?my HUBSCHER <remy.hubscher at ionyse.com> added the comment:

Hello, I did the patch, but I have no idea of how to make a test for it.

More over, I have seen a similar problem each time there is this code in the Python code (here in distutils.util.Distribution.get_command_class) :


            try:
                __import__ (module_name)
                module = sys.modules[module_name]
            except ImportError:
                continue

            try:
                klass = getattr(module, klass_name)
            except AttributeError:
                raise DistutilsModuleError(
                      "invalid command '%s' (no class '%s' in module '%s')"
                      % (command, klass_name, module_name))


Maybe it could be better to have a function in cpython to do that ?

----------
hgrepos: +59
keywords: +patch
Added file: http://bugs.python.org/file22962/packaging.util.resolve_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sat Aug 20 16:23:51 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Sat, 20 Aug 2011 14:23:51 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313850231.68.0.679749232662.issue12703@psf.upfronthosting.co.za>


R?my HUBSCHER <remy.hubscher at ionyse.com> added the comment:

Actually it is not the same problem for `distutils.util.Distribution.get_command_class` my mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:02:40 2011
From: report at bugs.python.org (Vivek Sekhar)
Date: Sat, 20 Aug 2011 15:02:40 +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: <1313852561.0.0.931595372259.issue8713@psf.upfronthosting.co.za>


Changes by Vivek Sekhar <vivek at viveksekhar.ca>:


----------
nosy: +vsekhar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:03:13 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sat, 20 Aug 2011 15:03:13 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313852593.52.0.596098416335.issue12703@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Thanks R?my, 

About testing, I would go for modules with errors in it and check that when imported trough this function it does what it is supposed to do.

IOW:

1. Create a test python module with errors in their definition (Throw an exception would do the trick)
2a. Try to load this python module, check that the exception is the one thrown in the module
2.b Check that loading a non existing modules still tell us that the module doesn't exist
2.c Check that importing something existing works, trough this function. 

Hope I'm clear enough, thanks again,
Alexis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:08:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 15:08:43 +0000
Subject: [issue12787] xmlrpc.client documentation (MultiCall Objects) points
	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <E1QunA9-0005zU-ET@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e8f878837eae by Sandro Tosi in branch '2.7':
#12787: link original MultiCall proposal to webarchive and in a footnote
http://hg.python.org/cpython/rev/e8f878837eae

New changeset ab11edca2310 by Sandro Tosi in branch '3.2':
#12787: link original MultiCall proposal to webarchive and in a footnote
http://hg.python.org/cpython/rev/ab11edca2310

New changeset 0fa18bc5427b by Sandro Tosi in branch 'default':
#12787: merge with 3.2
http://hg.python.org/cpython/rev/0fa18bc5427b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12787>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:10:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 15:10:22 +0000
Subject: [issue12787] xmlrpc.client documentation (MultiCall Objects) points
	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <1313853022.49.0.514995244155.issue12787@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Ezio for the suggestions.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12787>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:12:40 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 15:12:40 +0000
Subject: [issue12213] BufferedRandom,
	BufferedRWPair: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313853161.0.0.973137550344.issue12213@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: BufferedRandom,	BufferedRWPair: issues with interlaced read-write -> BufferedRandom, BufferedRWPair: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:15:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 15:15:22 +0000
Subject: [issue12213] BufferedRandom: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313853322.18.0.320547775514.issue12213@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: BufferedRandom, BufferedRWPair: issues with interlaced read-write -> BufferedRandom: issues with interlaced read-write

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:30:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 15:30:40 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
Message-ID: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

#12326 proposes to remove the major version from sys.platform. If we remove it, we will need another easy way to get this information. I don't think that we need the version used to build Python, but the version at runtime. That's why the platform is a good candidate to add such information.

I propose to add platform.major(): major version of the system, or 0 if we cannot get it. I chose 0 instead of None or raising an error to be consistent with the other functions. Platform functions don't raise error and always return the same type. For example, platform.release() returns an empty string if the release string cannot be read.

Each system formats its full version (e.g. (2, 6, 28) for Linux 2.6.28) differently. It is easier and more reliable to only provide the major version.

If you would like to get more information (e.g. minor minor), you have to test the system name. See for example platform.mac_ver(), platform.win_ver(), and also test.support.requires_linux_version().

Attached patch implements platform.major().

----------
files: platform_major.patch
keywords: patch
messages: 142538
nosy: haypo, lemburg
priority: normal
severity: normal
status: open
title: platform: add a major function to get the system major version
versions: Python 3.3
Added file: http://bugs.python.org/file22963/platform_major.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:35:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 15:35:21 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313854521.66.0.0934402184411.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm working on a patch to remove the major version of sys.platform

As expected by Marc-Andre: we need this information and so it has to be available somewhere else. I created #12794 to add platform.major(). I prefer to get the major version at runtime, not the major version used to build Python. I need the major version for Python tests: the tests checks features of the running system (kernel), not of the system used to build Python.

@Marc-Andre Lemburg: If you still think that we need all information about the system used to build Python, please open another issue (or comment maybe #12794).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 17:36:03 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 15:36:03 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313854563.7.0.569449182531.issue12794@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/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 18:23:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 16:23:17 +0000
Subject: [issue12795] Remove the major version from sys.platform
Message-ID: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

sys.platform contains the major system version. If you test the sys.platform value (e.g. sys.platform == 'linux2'), your program doesn't work anymore with the new system major version (e.g. Linux 3). This problem is common with NetBSD, OpenBSD and FreeBSD. You don't have the problem if you test the prefix of sys.platform (e.g. sys.platform.startswith('linux')), but this code pattern is rare.

Because of the release of Linux 3, it was proposed in #12326 to remove the major version from sys.platform. It is already done for Cygwin and Darwin. Example of new sys.platform values: 'linux', 'freebsd', 'hp-ux', ... (instead of 'linux2', 'freebsd8', hp-ux11', ...).

I don't know if "osf1" becomes "osf". I don't know if "irix646" becomes "irix6" or just "irix"?

What about sys.platform=="win32"? Should it be truncated to "win"? Many tests use already sys.platform.startswith("win"). And what about sys.platform=="java"? It would be nice to be consistent (e.g. never have digits in sys.platform).

Without the major version, it's much easier when you only care of the system name: you can use a dictionary with the name for the key (it's used in regrtest.py with my patch).

Another example :
------------------------
    if sys.platform in ('netbsd1', 'netbsd2', 'netbsd3',
                        'Darwin1.2', 'darwin',
                        'freebsd2', 'freebsd3', 'freebsd4', 'freebsd5',
                        'freebsd6', 'freebsd7', 'freebsd8',
                        'bsdos2', 'bsdos3', 'bsdos4',
                        'openbsd', 'openbsd2', 'openbsd3', 'openbsd4'):
------------------------
becomes:
------------------------
    if sys.platform in ('netbsd', 'freebsd', 'openbsd', 'bsdos', 
                        'Darwin1.2', 'darwin'):
------------------------
('Darwin1.2'? WTF?)

This issue follows my previous commit 50f1922bc1d5:

   Issue #12326: don't test the major version of sys.platform
   Use startswith, instead of ==, when testing sys.platform to support
   new platforms like Linux 3 or OpenBSD 5.

I chose to keep sys.platform in distutils and packaging because these modules are supposed to work on older Python versions (e.g. packaging will be backported to Python 2.4-3.2).

Attached patch implements this issue. It requires platform.major(): see issue #12794. The patch require to rerun "autoconf".

----------
files: sys_platform_without_major.patch
keywords: patch
messages: 142540
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: Remove the major version from sys.platform
versions: Python 3.3
Added file: http://bugs.python.org/file22964/sys_platform_without_major.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 18:24:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 16:24:21 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313857461.6.0.161944530826.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm working on a patch to remove the major version of sys.platform

Done. I created the issue #12795: "Remove the major version from sys.platform".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 18:25:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 16:25:49 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1313857549.72.0.423312379148.issue12795@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

To have an idea of how much code has to be changed for the sys.platform change, there is the diffstat :

$ diffstat sys_platform_without_major.patch 
 Lib/ctypes/util.py                      |    6 --
 Lib/distutils/command/build_ext.py      |    3 -
 Lib/distutils/unixccompiler.py          |    4 -
 Lib/distutils/util.py                   |   12 ++---
 Lib/packaging/command/build_ext.py      |    3 -
 Lib/packaging/compiler/unixccompiler.py |    6 +-
 Lib/packaging/tests/test_config.py      |    4 -
 Lib/sysconfig.py                        |   12 ++---
 Lib/test/fork_wait.py                   |    2 
 Lib/test/regrtest.py                    |   71 ++++++++++++++------------------
 Lib/test/support.py                     |    2 
 Lib/test/test_asyncore.py               |    2 
 Lib/test/test_fcntl.py                  |    9 +---
 Lib/test/test_locale.py                 |    2 
 Lib/test/test_logging.py                |    2 
 Lib/test/test_multiprocessing.py        |    2 
 Lib/test/test_os.py                     |    6 +-
 Lib/test/test_posix.py                  |    2 
 Lib/test/test_signal.py                 |   11 ++--
 Lib/test/test_socket.py                 |    7 ---
 Lib/test/test_tarfile.py                |    2 
 Lib/test/test_tempfile.py               |    2 
 Lib/test/test_threading.py              |   14 +++---
 Lib/unittest/test/test_break.py         |    4 -
 configure.in                            |   17 ++-----
 setup.py                                |   19 ++++----
 26 files changed, 105 insertions(+), 121 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 18:57:59 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 20 Aug 2011 16:57:59 +0000
Subject: [issue12789] re.Scanner don't support more then 2 groups on regex
In-Reply-To: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>
Message-ID: <1313859479.12.0.574131586204.issue12789@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Even if this bug is fixed, it still won't work as you expect, and this s why.

The Scanner function accepts a list of 2-tuples. The first item of the tuple is a regex and the second is a function. For example:

    re.Scanner([(r"\d+", number), (r"\w+", word)])

The Scanner function then builds a regex, using the given regexes as alternatives, each wrapped as a capture group:

    r"(\d+)|(\w+)"

When matching, it sees which group captured and uses that to decide which function it should call, so, for example, if group 1 matched, it calls "number", and if group 2 matched, it calls "word".

When you introduce capture groups into the regexes, it gets confused. If your regex matches, it'll see that groups 1 and 2 match, so it'll try to call the second function, but there's isn't one...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 19:11:41 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 17:11:41 +0000
Subject: [issue12789] re.Scanner doesn't support more than 2 groups on regex
In-Reply-To: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>
Message-ID: <1313860301.36.0.70344557073.issue12789@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: re.Scanner don't support more then 2 groups on regex -> re.Scanner doesn't support more than 2 groups on regex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 19:12:04 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 17:12:04 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1313860324.89.0.809387159314.issue12795@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/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 19:53:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Aug 2011 17:53:58 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1313862838.42.0.670832447938.issue12792@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This documents the current list, but ;-) I think the current list should be modified.

1. Put behavior at the top of the list, as it is the most common (a 'human factor' principle).

2. Combine performance and resource usage. Both are extremely rare and largely overlap. Time is a resource and space-hogging is bad performance. There is no difference as far as I know in terms of how we treat issues.

3. Going further: Each category should have a reason for being in terms of how we treat issues. I really think behavior, feature request, security, and other (listed in that order) are sufficient. Compiler errors, for instance, are rare (2% overall and probably less now), are covered by the build component, and are treated like bugs anyway (fixes are applied to current versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sat Aug 20 19:56:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 17:56:19 +0000
Subject: [issue12213] BufferedRandom: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <E1QupmL-0000c2-N3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 524896c305ce by Antoine Pitrou in branch '3.2':
Issue #12213: make it clear that BufferedRWPair shouldn't be called with the
http://hg.python.org/cpython/rev/524896c305ce

New changeset a423bd492d6c by Antoine Pitrou in branch 'default':
Issue #12213: make it clear that BufferedRWPair shouldn't be called with the
http://hg.python.org/cpython/rev/a423bd492d6c

New changeset dd4f29e39756 by Antoine Pitrou in branch '2.7':
Issue #12213: make it clear that BufferedRWPair shouldn't be called with the
http://hg.python.org/cpython/rev/dd4f29e39756

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 19:56:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 17:56:48 +0000
Subject: [issue12213] BufferedRandom: issues with interlaced read-write
In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za>
Message-ID: <1313863008.17.0.7969143293.issue12213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think it can be closed now.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12213>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:02:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 18:02:34 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QupsO-00013K-T6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4136acaf03de by ?ric Araujo in branch 'default':
Fix sdist test on Windows (#12678).  Patch by Jeremy Kloth.
http://hg.python.org/cpython/rev/4136acaf03de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:02:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 18:02:34 +0000
Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific
	cases
In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za>
Message-ID: <E1QupsO-00013K-Sz@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7d9fa30c5588 by ?ric Araujo in branch '3.2':
Refactor the copying of xxmodule.c in distutils tests (#12141).
http://hg.python.org/cpython/rev/7d9fa30c5588

New changeset 900738175779 by ?ric Araujo in branch 'default':
Refactor the copying of xxmodule.c in packaging tests (#12141).
http://hg.python.org/cpython/rev/900738175779

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12141>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:22:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 18:22:56 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313864576.99.0.367223277559.issue12782@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree it?s unfortunate that we have to use backslashes to have multi-line with statements.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:27:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Aug 2011 18:27:29 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313864849.03.0.128760768066.issue12782@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> is the only other example I can think of 

One similar example would be "raise" in Python 2.

> all compound statements uniformly allowed the same continuation syntax.

This is not true: only "import-as" allows this syntax.  All other uses of parentheses for continuation are continuations of *expressions*.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:41:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Aug 2011 18:41:24 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313865684.71.0.33495545399.issue12794@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please elaborate why we need it?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:48:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Aug 2011 18:48:10 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1313866090.35.0.248131610243.issue12795@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this change should be much much smaller in scope. It was (nearly) agreed to drop the major version if the system is Linux. There is no consensus (that I'm aware of) to drop the major OS version for all systems.

So I would propose to do this *only* selectively, and *only* if experts of the platform request such a change. For example, hpux9, hpux10, and hpux11 are *very* different operating systems; it's not clear that users are helped if we drop the major version for them. Also, if HP-UX 12 ever gets released, it is probably again different. 

I'm not sure sure about the BSDs: it is my understanding that they follow the tradition of only adding major changes to major OS releases, which would be in favor of keeping the status quo for them. OTOH, it may also be that the impact of the major version on Python and Python applications is too small so that applications would be better helped with dropping the major version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:49:20 2011
From: report at bugs.python.org (Miguel de Val Borro)
Date: Sat, 20 Aug 2011 18:49:20 +0000
Subject: [issue12772] fractional day attribute in datetime class
In-Reply-To: <1313597703.11.0.0103584159949.issue12772@psf.upfronthosting.co.za>
Message-ID: <1313866160.89.0.984654700539.issue12772@psf.upfronthosting.co.za>


Miguel de Val Borro <miguel.deval at gmail.com> added the comment:

Thanks, I need the fractional day added to the ordinal day of the month. Using the timedelta division it would be:

>>> from __future__ import division
>>> dt = datetime.datetime(2008, 5, 8, 13, 35, 41, 567777)
>>> dt.day + (dt-datetime.datetime(dt.year, dt.month, dt.day))/datetime.timedelta(1)
8.566453330752315

Then it simply becomes a one line function so I'm closing this ticket.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12772>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:49:34 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 20 Aug 2011 18:49:34 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1313866174.4.0.662175244624.issue12795@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:52:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=82ngelo_Ot=C3=A1vio_Nuffer_Nunes?=)
Date: Sat, 20 Aug 2011 18:52:00 +0000
Subject: [issue12789] re.Scanner doesn't support more than 2 groups on regex
In-Reply-To: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>
Message-ID: <1313866320.48.0.603728741267.issue12789@psf.upfronthosting.co.za>


?ngelo Ot?vio Nuffer Nunes <angelonuffer at gmail.com> added the comment:

Ah, ok, thanks...
Then I think my idea is impossible.
I will use the Scanner in normal way. :)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 20:54:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 20 Aug 2011 18:54:01 +0000
Subject: [issue12783] test_posix failure on FreeBSD 6.4:
	test_get_and_set_scheduler_and_param
In-Reply-To: <1313751328.54.0.186872494969.issue12783@psf.upfronthosting.co.za>
Message-ID: <1313866441.59.0.0818766411306.issue12783@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch skipping this part of the test on FreeBSD (it actually also fails on FreeBSD 7.2).
Note that while calling sched_setparam(param) results in EINVAL with SCHED_OTHER processes, calling sched_setscheduler(SCHED_OTHER, param) works just fine...

----------
keywords: +needs review, patch
nosy: +pitrou
stage: needs patch -> patch review
versions: +Python 3.3
Added file: http://bugs.python.org/file22965/test_sched_freebsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12783>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:00:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 19:00:55 +0000
Subject: [issue12789] re.Scanner doesn't support more than 2 groups on regex
In-Reply-To: <1313810039.38.0.201023108206.issue12789@psf.upfronthosting.co.za>
Message-ID: <1313866855.97.0.327132438574.issue12789@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12789>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:01:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 19:01:26 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313866886.51.0.0754121145009.issue12782@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/issue12782>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:22:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 19:22:40 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1313868160.16.0.912335112785.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file22966/aa9e276a791d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:23:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 19:23:58 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1313868238.92.0.256669292159.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch incorporating Ezio's comments and synchronized with latest default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:25:30 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 20 Aug 2011 19:25:30 +0000
Subject: [issue12794] platform: add a major function to get the system
	major	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <4E500A38.8090405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> #12326 proposes to remove the major version from sys.platform. If we remove it, we will need another easy way to get this information. I don't think that we need the version used to build Python, but the version at runtime. That's why the platform is a good candidate to add such information.
> 
> I propose to add platform.major(): major version of the system, or 0 if we cannot get it. I chose 0 instead of None or raising an error to be consistent with the other functions. Platform functions don't raise error and always return the same type. For example, platform.release() returns an empty string if the release string cannot be read.
> 
> Each system formats its full version (e.g. (2, 6, 28) for Linux 2.6.28) differently. It is easier and more reliable to only provide the major version.
> 
> If you would like to get more information (e.g. minor minor), you have to test the system name. See for example platform.mac_ver(), platform.win_ver(), and also test.support.requires_linux_version().
> 
> Attached patch implements platform.major().

I'm not sure I understand why platform.release() isn't sufficient
for this purpose. Note that some systems return alphanumeric
values for platform.release(), e.g. for Windows you get
'NT' or 'XP'.

What we could do is add a function that tries to find out the
true version number of the OS, e.g. for Windows 7 that would
be (6, 1, 7601) instead of the marketing name '7' returned by
platform.release().

Still, this won't help with the OS version used for the Python
build.

When Tarek was working on separating sysconfig from
distutils, we briefly discussed parsing the Makefile and pyconfig.h
files into a Python module. This would work around the issues
with the parsing overhead of using sysconfig and also prevent
the problems you currently find on some platforms that choose
to place the needed Makefile and pyconfig.h into a Python
development package.

However, even with those generated modules, access to the build
platform version would have to be provided through the sysconfig
module, not the platform module, since that's the more appropriate
module for such information.

That would be the full solution to the problem, but it would have
to go on a separate ticket.

----------
title: platform: add a major function to get the system major version -> platform: add a major function to get the system major	version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 21:29:25 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 19:29:25 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313868565.02.0.89819068548.issue12794@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: platform: add a major function to get the system major	version -> platform: add a major function to get the system major version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 22:27:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 20:27:34 +0000
Subject: [issue12796] total_ordering goes into infinite recursion when
	NotImplemented is returned
Message-ID: <1313872054.41.0.176512047741.issue12796@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This small test file exhibits the issue. When @total_ordering is not applied, the '<' operator raises TypeError as expected. When @total_ordering is applied, there is an infinite recursion error.

----------
components: Library (Lib)
files: totbug.py
messages: 142558
nosy: ncoghlan, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: total_ordering goes into infinite recursion when NotImplemented is returned
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22967/totbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12796>
_______________________________________

From report at bugs.python.org  Sat Aug 20 22:31:47 2011
From: report at bugs.python.org (Idan Kamara)
Date: Sat, 20 Aug 2011 20:31:47 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1313872307.4.0.708398752325.issue12786@psf.upfronthosting.co.za>


Idan Kamara <idankk86 at gmail.com> added the comment:

Thanks for getting on top of this so quickly Charles. Setting close_fds=True worked like a charm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Sat Aug 20 22:54:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 20:54:18 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313873658.21.0.994530029963.issue12768@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/issue12768>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:00:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 21:00:03 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
Message-ID: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Right now it is painful to integrate openat() with the normal IO classes. You have to figure out the low-level flags yourself (i.e. replicate the logic and error handling from the FileIO constructor), then replicate the open() logic yourself (because you want to set the name attribute on the FileIO object before wrapping it).

Therefore it would be nice if the FileIO constructor and the open() function supported openat natively. I see two possibilities:
- allow a (dirfd, name) tuple for the first "file" argument
- allow an optional dirfd argument at the end of the arglist

----------
components: IO, Library (Lib)
messages: 142560
nosy: haypo, neologix, pitrou, rosslagerwall
priority: normal
severity: normal
stage: needs patch
status: open
title: io.FileIO and io.open should support openat
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:00:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 21:00:11 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313874011.6.0.957310502975.issue12794@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That other ticket is #9878.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:01:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 20 Aug 2011 21:01:23 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1313874083.02.0.846535190535.issue9878@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/issue9878>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:02:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 21:02:37 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313874157.31.0.622703008669.issue12794@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Can you please elaborate why we need it?

platform.major() will be needed if we remove the major version for all platforms from sys.platform (issue #12795). See sys_platform_without_major.patch attached to issue #12795 see how it is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:13:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 21:13:11 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1313874791.44.0.538528824297.issue12792@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I believe you can?t capitalize ?behavior? in English.

About Terry?s 3): I think the usefulness of having separate types is the same as components, to let people search for what they can help with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:13:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 21:13:34 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1313874814.24.0.488304481911.issue12795@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

At the beginning, I thaught that it would be better to remove the major version from sys.platform on all platforms. When I started to write the patch, I expected to change only 2 or 3 files. But the patch is now huge ("26 files changed, 105 insertions(+), 121 deletions(-)"), which means that it will break most third party projects.

> I would propose to do this *only* selectively,
> and *only* if experts of the platform request such a change.

Ok, I (now) agree. So let's close this issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:14:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 20 Aug 2011 21:14:30 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313874870.81.0.195877694631.issue12797@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:17:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Aug 2011 21:17:16 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313875036.89.0.550815207239.issue12797@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A third idea is to find a way to override the low-level open() function (the one that returns a fd).

openat() seems to exist only on Linux, so I'm -1 on adding new parameters to support this function only.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:19:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 21:19:44 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313875184.97.0.739356163073.issue12794@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'm not sure I understand why platform.release() isn't sufficient
> for this purpose. Note that some systems return alphanumeric
> values for platform.release(), e.g. for Windows you get
> 'NT' or 'XP'.

It's not easy to get 2 (int) from '2.6.38-8-generic' (str). For Windows, there *is* a major version:

 * Windows 3.1 : 3
 * Windows 95/98, NT 4 : 4
 * Windows XP, 2003 : 5
 * Vista, Seven : 6

The major version is maybe less revelant for Windows.

Anyway...

> platform.major() will be needed if we remove the major
> version for all platforms from sys.platform (issue #12795).

I just closed the issue #12795, and so I don't think that this issue is still needed and so I close it. Reopen it if you still see an use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:20:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 21:20:49 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313875249.57.0.178056321043.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, I checked and aliases are already supported.

You seem to have overlooked the Versions field on the top of this page: new features don?t go in stable releases, so your patch would have to apply to default, a.k.a. 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:21:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 21:21:17 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313875036.89.0.550815207239.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313875140.3579.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A third idea is to find a way to override the low-level open()
> function (the one that returns a fd).

Why not. It would e.g. allow to use CreateFile under Windows (the hg
guys do this in order to change the "sharing" mode to something more
laxist).

> openat() seems to exist only on Linux, so I'm -1 on adding new
> parameters to support this function only.

openat() is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:32:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 21:32:22 +0000
Subject: [issue12783] test_posix failure on FreeBSD 6.4:
	test_get_and_set_scheduler_and_param
In-Reply-To: <1313751328.54.0.186872494969.issue12783@psf.upfronthosting.co.za>
Message-ID: <1313875942.43.0.710670576023.issue12783@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sounds fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12783>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:41:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 21:41:30 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QutIG-0006A4-LD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b072e1559d6b by Victor Stinner in branch 'default':
Close #12326: sys.platform is now always 'linux' on Linux
http://hg.python.org/cpython/rev/b072e1559d6b

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:47:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 21:47:08 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313876828.31.0.374574056152.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

For the sys.build_info, I opened #12794 (platform.major()) but then quickly closed it because it was only useful if the issue #12795 (Remove the major version from sys.platform) was accepted, but I closed it.

--

Update votes for "(2) Python 3.3: change sys.platform to 'linux'":

Charles-Fran?ois Natali: -1
Amaury Forgeot d'Arc: -1

Antoine Pitrou: +1
Barry A. Warsaw: +1
?ric Araujo: +1
Dave Malcolm: +1
Marc-Andre Lemburg: +1
Martin v. L?wis: +1
Victor Stinner: +1

=> total=+5 (9 votes)

The changeset b072e1559d6b (sys.platform is now always 'linux') closes this issue because it solves the initial problem. Did you notice how trivial is the final patch? ;-)

This funny issue is closed, we can now work again on real bugs :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:49:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 21:49:07 +0000
Subject: [issue12798] Update mimetypes documentation
Message-ID: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following http://mail.python.org/pipermail/docs/2011-June/004727.html I've updated the mimetypes module doc.

Some changes I would like to do (but I didn't, since I'd like to hear comments):

- move the example of the module before the definition of MimeTypes class (so right below mimetypes.common_types)
- move all the text about MimeTypes class in the subsection that talks about it.

Comments, as always, are welcome.

----------
assignee: docs at python
components: Documentation
files: mimetypes_doc_update.patch
keywords: patch
messages: 142572
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Update mimetypes documentation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22968/mimetypes_doc_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Sat Aug 20 23:54:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 21:54:01 +0000
Subject: [issue12799] realpath not resolving symbolic links under Windows
Message-ID: <1313877241.08.0.942719634854.issue12799@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

>From a look at the code, realpath() does not seem to resolve symlinks under Windows, even though we have the _getfinalpathname function to do that.
Please indulge with me if I'm wrong :)

----------
components: Library (Lib)
messages: 142573
nosy: brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: realpath not resolving symbolic links under Windows
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12799>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:00:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 22:00:28 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1Qutac-0000kS-Ed@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 85e091c83f9a by Victor Stinner in branch 'default':
Issue #12326: woops, I really mean 'linux', not 'linux2'
http://hg.python.org/cpython/rev/85e091c83f9a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:19:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 22:19:01 +0000
Subject: [issue5301] add mimetype for image/vnd.microsoft.icon (patch)
In-Reply-To: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za>
Message-ID: <E1QutsZ-0001pS-Q3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4964215ddcba by Sandro Tosi in branch '2.7':
#5301: add image/vnd.microsoft.icon (.ico) MIME type
http://hg.python.org/cpython/rev/4964215ddcba

New changeset d9a0781c24b8 by Sandro Tosi in branch '3.2':
#5301: add image/vnd.microsoft.icon (.ico) MIME type
http://hg.python.org/cpython/rev/d9a0781c24b8

New changeset 95b230772469 by Sandro Tosi in branch 'default':
#5301: merge with 3.2
http://hg.python.org/cpython/rev/95b230772469

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5301>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:21:01 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 22:21:01 +0000
Subject: [issue5301] add mimetype for image/vnd.microsoft.icon (patch)
In-Reply-To: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za>
Message-ID: <1313878861.93.0.204496462706.issue5301@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Drew for the issue and the patch: it has now been committed on all the active branches!

----------
assignee:  -> sandro.tosi
nosy: +sandro.tosi
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5301>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:21:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 22:21:19 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1313878879.7.0.115138212954.issue9878@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

"avoid parsing pyconfig.h and Makefile in the sysconfig module by autogenerating an extension module"

This feature will be appreciated by small devices embeding Python: on such device, headers and Makefile are not copied to not waste disk space.

To me, it is also an horrible thing to parse pyconfig.h and Makefile at startup, because these files are non trivial to parse and it should be done only once. Because these files are created one, we should parse them once, when Python is compiled. So an "autogenerating an extension module" is an excellent idea. It will speed up Python startup.

----------
nosy: +haypo
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:23:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 22:23:00 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313878980.3.0.0645481176808.issue12797@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> allow an optional dirfd argument at the end of the arglist

I prefer this suggestion.

I didn't know openat(). Antoine told me that it can be used, for example, to fix security vulnerabilities like #4489.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:24:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 22:24:00 +0000
Subject: [issue12794] platform: add a major function to get the system major
	version
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1313879040.34.0.210864002507.issue12794@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:37:54 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 22:37:54 +0000
Subject: [issue11362] image/webp missing from mimetypes.py
In-Reply-To: <1299002869.89.0.906487136823.issue11362@psf.upfronthosting.co.za>
Message-ID: <1313879874.74.0.941540968024.issue11362@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11362>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:40:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 22:40:11 +0000
Subject: [issue1043134] Add preferred extensions for MIME types
Message-ID: <1313880011.47.0.220116485648.issue1043134@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043134>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:52:52 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 22:52:52 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1QuuPL-0003k0-AO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b5ccdf7c032a by Victor Stinner in branch 'default':
Issue #12326: refactor usage of sys.platform
http://hg.python.org/cpython/rev/b5ccdf7c032a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 00:57:40 2011
From: report at bugs.python.org (=?utf-8?q?Aur=C3=A9lien_Dunand?=)
Date: Sat, 20 Aug 2011 22:57:40 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
	when extract symlink
Message-ID: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>


New submission from Aur?lien Dunand <aurelien.dunand+python at gmail.com>:

When you extractall a tarball containing a symlink in stream mode ('r|'), an Exception happens:

Traceback (most recent call last):
    File "./test_extractall_stream_symlink.py", line 26, in <module>
    tar.extractall(path=destdir)
    File "/usr/lib/python3.2/tarfile.py", line 2134, in extractall
    self.extract(tarinfo, path, set_attrs=not tarinfo.isdir())
    File "/usr/lib/python3.2/tarfile.py", line 2173, in extract
    set_attrs=set_attrs)
    File "/usr/lib/python3.2/tarfile.py", line 2249, in _extract_member
    self.makefile(tarinfo, targetpath)
    File "/usr/lib/python3.2/tarfile.py", line 2289, in makefile
    source.seek(tarinfo.offset_data)
    File "/usr/lib/python3.2/tarfile.py", line 553, in seek
    raise StreamError("seeking backwards is not allowed")
    tarfile.StreamError: seeking backwards is not allowed

You can reproduce the bug with this snippet of code:

TEMPDIR='/tmp/pyton_test'
os.mkdir(TEMPDIR)
tempdir = os.path.join(TEMPDIR, "testsymlinks")
temparchive = os.path.join(TEMPDIR, "testsymlinks.tar")
destdir = os.path.join(TEMPDIR, "extract")
os.mkdir(tempdir)
try:
    source_file = os.path.join(tempdir,'source')
    target_file = os.path.join(tempdir,'symlink')
    with open(source_file,'w') as f:
        f.write('something\n')
    os.symlink('source', target_file)
    tar = tarfile.open(temparchive,'w')
    tar.add(target_file, arcname=os.path.basename(target_file))
    tar.add(source_file, arcname=os.path.basename(source_file))
    tar.close()
    fo = open(temparchive, 'rb')
    tar = tarfile.open(fileobj=fo, mode='r|')
    try:
        tar.extractall(path=destdir)
    finally:
        tar.close()
finally:
    os.unlink(temparchive)
    shutil.rmtree(TEMPDIR)



If source_file is added before target_file, there is no Exception raised. But it still raised when you create the same tarball with GNU tar.

----------
components: Library (Lib)
messages: 142580
nosy: adunand
priority: normal
severity: normal
status: open
title: 'tarfile.StreamError: seeking backwards is not allowed' when extract symlink
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12800>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:34:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Aug 2011 23:34:29 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313883269.59.0.857470155989.issue12797@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe openat is new to POSIX (mandatory as of POSIX 2008).  For example, it's not currently in OS X and apparently was first added to FreeBSD in 8.0.  So it would have to be checked by configure and documented as platform-dependent.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:42:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 23:42:08 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313883269.59.0.857470155989.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313883593.3579.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I believe openat is new to POSIX (mandatory as of POSIX 2008).  For
> example, it's not currently in OS X and apparently was first added to
> FreeBSD in 8.0.  So it would have to be checked by configure and
> documented as platform-dependent.

We already have os.openat:
http://docs.python.org/dev/library/os.html#os.openat

This request is to make it easier to use with the high-level IO classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:47:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 23:47:31 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
Message-ID: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

We have our own quirky implementation of C realpath() in posixpath.py.
It would probably be simpler, safer and more efficient to simply call the POSIX function instead (but it most be exposed somewhere, by posixmodule.c I suppose).

----------
components: Library (Lib)
messages: 142583
nosy: haypo, neologix, pitrou, rosslagerwall
priority: normal
severity: normal
status: open
title: C realpath not used by os.path.realpath
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:56:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 23:56:07 +0000
Subject: [issue12799] realpath not resolving symbolic links under Windows
In-Reply-To: <1313877241.08.0.942719634854.issue12799@psf.upfronthosting.co.za>
Message-ID: <1313884567.1.0.0938949868217.issue12799@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You are right, but this issue is a duplicate of #9949.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12799>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:56:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 23:56:13 +0000
Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links
In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za>
Message-ID: <1313884573.37.0.193871149991.issue9949@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The issue #12799 has been marked as a duplicate of this issue:
"From a look at the code, realpath() does not seem to resolve symlinks under Windows, even though we have the _getfinalpathname function to do that. Please indulge with me if I'm wrong :)"

----------
nosy: +haypo, pitrou, tim.golden
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9949>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:56:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 23:56:59 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1313884619.39.0.626799511462.issue1298813@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The latest POSIX versions (*) allow NULL to be passed for the target memory area, meaning that realpath() will allocate as much memory as necessary by itself. This essentially does the same thing as canonicalize_file_name(), but in a standard way rather than by relying on a GNU extension.

I suppose that possibility could be checked at configure time.

(*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

----------
nosy: +pitrou
stage: test needed -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Sun Aug 21 01:57:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 23:57:43 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1313884663.73.0.56356967143.issue12801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The Python implementation (os.path.realpath) was introduced 10 years ago by the issue #461781.

The Python implemtation has known bugs:

 - #9949: os.path.realpath on Windows does not follow symbolic links
 - #11397: os.path.realpath() may produce incorrect results

See also the issue #1298813: _Py_wrealpath() must use canonicalize_file_name() if available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sun Aug 21 02:01:03 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Aug 2011 00:01:03 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313884863.17.0.245056165708.issue12797@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

> We already have os.openat
Ah, right.  The comment still applies, though, to future documentation of the proposed feature.  +1 on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 21 02:07:46 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Aug 2011 00:07:46 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
	when extract symlink
In-Reply-To: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>
Message-ID: <1313885266.14.0.763457898315.issue12800@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12800>
_______________________________________

From report at bugs.python.org  Sun Aug 21 02:46:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Aug 2011 00:46:30 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
Message-ID: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Windows error 3 is returned when a directory path doesn't exist, but 267 is returned when an existing path is not a directory. This corresponds straight to the definition of ENOTDIR, but Python translates it to EINVAL:

>>> os.listdir("xx")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 3] The system cannot find the path specified: 'xx\\*.*'

>>> os.listdir("LICENSE")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 267] The directory name is invalid: 'LICENSE\\*.*'

>>> os.chdir("LICENSE")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 267] The directory name is invalid: 'LICENSE'

>>> e = sys.last_value
>>> e.errno
22
>>> errno.errorcode[22]
'EINVAL'


In PC/errmap.h, no Windows error code is translated to ENOTDIR (errno 20).

----------
messages: 142589
nosy: amaury.forgeotdarc, brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows error code 267 should be mapped to ENOTDIR, not EINVAL
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sun Aug 21 05:37:06 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sun, 21 Aug 2011 03:37:06 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1313897826.63.0.954184852604.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached new mapping though I don't know where unit test for this should go...

----------
keywords: +patch
nosy: +vladris
Added file: http://bugs.python.org/file22969/issue12802.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sun Aug 21 07:04:05 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 21 Aug 2011 05:04:05 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1313903045.44.0.537831836344.issue12801@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

An initial patch.

The first problem is that before, os.path.realpath('') == os.path.realpath('.')
but this is not true for realpath(3).

Thus, the test suite does not run because it relies on this behaviour.

----------
keywords: +patch
Added file: http://bugs.python.org/file22970/i12801.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sun Aug 21 08:08:36 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Sun, 21 Aug 2011 06:08:36 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313906916.57.0.343571210652.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

Just for my understanding:
Even "the current development/testing version: Python 3.2.2 rc 1 (August 14, 2011)" isn't new enough here?

So I'll have to find out how to install Python 3.3 in parallel to my 2.7.1 (on Fedora 15).

Starting with "hg clone http://hg.python.org/cpython" now.

Until later (after reading http://docs.python.org/devguide/ by myself of course ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 08:49:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Aug 2011 06:49:52 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313909392.37.0.432347802086.issue12326@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Where's the Doc changes? sys.platform is currently clearly documented as being "linux2" or "linux3". Adding an entry to Misc/NEWS is not enough.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 08:51:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Aug 2011 06:51:38 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1313909498.05.0.144083462258.issue12792@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You mean "pluralize" I guess.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sun Aug 21 08:53:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Aug 2011 06:53:20 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313909600.24.0.597201416824.issue12326@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 09:28:27 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Sun, 21 Aug 2011 07:28:27 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
Message-ID: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>


New submission from Adam Simpkins <adam at adamsimpkins.net>:

The SSLContext.load_cert_chain() method should accept a password argument to use if the private key is encrypted.  Currently it always uses OpenSSL's default password callback, which prompts the user interactively for a password.

I've attached a patch that adds an extra password argument, which can be either a string, bytes, bytearray, or a function to call to get the password.

----------
components: Library (Lib)
files: ssl-password.patch
keywords: patch
messages: 142595
nosy: simpkins
priority: normal
severity: normal
status: open
title: SSLContext.load_cert_chain() should accept a password argument
type: feature request
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22971/ssl-password.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 09:42:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Aug 2011 07:42:54 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1313912574.72.0.990397745886.issue12803@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +giampaolo.rodola, janssen, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 09:45:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Aug 2011 07:45:33 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1313912733.46.0.671173053784.issue12803@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 3.3 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 10:10:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 08:10:27 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1313914227.37.0.0418227581475.issue9878@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wouldn?t call this a performance issue.  From #4359, you can see that the two main reasons are first to avoid breakage on platforms that put pyconfig.h and Makefile in another package than the interpreter, and most importantly than the code is hard to maintain.  Resource usage diminution will just be a nice side-effect.

----------
type: performance -> 
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Sun Aug 21 10:15:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 08:15:24 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1313914524.66.0.85733922557.issue12792@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I did!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sun Aug 21 10:18:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 08:18:27 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313914707.64.0.521585967633.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Even "the current development/testing version: Python 3.2.2 rc 1
> (August 14, 2011)" isn't new enough here?
No.  (Where does the quote come from?)  The current development version is 3.3; its version number is currently 3.3.0a0, to mean it was not released yet.  3.2 is a stable release now; 3.2.2c1 is the candidate release of the next bugfix version of 3.2, which is one of the stable versions (with 2.7).

> So I'll have to find out how to install Python 3.3 in parallel to my 2.7.1
> Starting with "hg clone http://hg.python.org/cpython" now.
Yep, there?s no need to install.  Cloning http://hg.python.org/cpython#default will get you 3.3.  If you already have a clone for 3.2, you can also pull the default branch in your existing clone; feel free to ask for anything that?s not in the devguide or not clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:03:41 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Sun, 21 Aug 2011 09:03:41 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313917421.18.0.963735817802.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

>> Even "the current development/testing version: Python 3.2.2 rc 1
>> (August 14, 2011)" isn't new enough here?
>
> No.  (Where does the quote come from?) 

http://python.org/download/releases/

> Cloning http://hg.python.org/cpython#default will get you 3.3

I have 3.3 compiled and running now. :-)

> feel free to ask for anything that?s not in the devguide or not clear.

Thanks for the offer!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:05:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 09:05:51 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313917551.37.0.733154191813.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> http://python.org/download/releases/
Ah, I understand: the release candidate for 3.2.2 is a testing release, but not a development one :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:24:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 09:24:07 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313918647.59.0.187037128971.issue12703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m confused about what the proposed change would actually do.  Could you explain what behavior you want to change and how?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:29:00 2011
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_HUBSCHER?=)
Date: Sun, 21 Aug 2011 09:29:00 +0000
Subject: [issue12703] Improve error reporting for packaging.util.resolve_name
In-Reply-To: <1312626935.87.0.525014153536.issue12703@psf.upfronthosting.co.za>
Message-ID: <1313918940.16.0.470781616879.issue12703@psf.upfronthosting.co.za>


R?my HUBSCHER <remy.hubscher at ionyse.com> added the comment:

It is exactly what explained Alexis.

The __import__ can failed in two case :

 - The module doesn't exist
 - There is a error in the module

With the previous behaviour, even if the module exist, the message was that it doesn't exists. And it was then not fast forward to guess where was the error.

With this new behaviour, if there is an __import__ error and the module file actually exists, then we raise the real exception problem from the module that we try to import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12703>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:44:16 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 21 Aug 2011 09:44:16 +0000
Subject: [issue12461] it's not clear how the shutil.copystat() should work on
	symlinks
In-Reply-To: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>
Message-ID: <1313919856.59.0.831068649216.issue12461@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

This is a sub-issue of #12715.

ATM the consent is to add just one symlinks parameter and use the l* functions iff src _and_ dst are symlinks.

----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12461>
_______________________________________

From report at bugs.python.org  Sun Aug 21 11:51:09 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 21 Aug 2011 09:51:09 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1313920269.14.0.270943469252.issue9993@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I work on the superficially related #12715 (symlinks for shutil). As we try to mimic the POSIX tools and `mv` indeed doesn't follow links, I agree with the approach of this patch.

----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Sun Aug 21 12:08:24 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 10:08:24 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <E1Qv4x4-0002rO-Ul@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset bf89ff3d1ec9 by Victor Stinner in branch 'default':
Issue #12326: update sys.platform doc for Linux
http://hg.python.org/cpython/rev/bf89ff3d1ec9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 12:21:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 10:21:12 +0000
Subject: [issue12461] it's not clear how the shutil.copystat() should work on
	symlinks
In-Reply-To: <1309513358.23.0.446931887968.issue12461@psf.upfronthosting.co.za>
Message-ID: <1313922072.02.0.670608814871.issue12461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This report is older but the other one has more discussion and patches, so I?m closing this one.  You?re welcome to follow the other.  If you think the documentation for current versions should mention how symlinks are handled, please open a new documentation bug.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Add symlink support to shutil functions
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12461>
_______________________________________

From report at bugs.python.org  Sun Aug 21 12:41:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 10:41:17 +0000
Subject: [issue12783] test_posix failure on FreeBSD 6.4:
	test_get_and_set_scheduler_and_param
In-Reply-To: <1313751328.54.0.186872494969.issue12783@psf.upfronthosting.co.za>
Message-ID: <E1Qv5Su-0005DY-BS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a04e70d7d76c by Charles-Fran?ois Natali in branch 'default':
Issue #12783: Fix test_posix failures on FreeBSD buildbots, due to
http://hg.python.org/cpython/rev/a04e70d7d76c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12783>
_______________________________________

From report at bugs.python.org  Sun Aug 21 12:56:27 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 21 Aug 2011 10:56:27 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1313924187.12.0.399320404194.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

We have an edge case when the caller calls copymode with symlinks=True on an OS that doesn't have lchmod (ie any other than FreeBSD).

Should it be a nop (as in copystat), use chmod or raise an Exception?

I Personally (and some people on #python-dev) believe it should raise an Exception as the caller made the effort to say that (s)he wants the link _not_ to be followed and it's just one operation (contrary to copystat that does several things).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Sun Aug 21 12:57:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 10:57:24 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1313924244.94.0.0379584616289.issue4489@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I made two comments on rietveld but the email was rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:00:14 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 21 Aug 2011 11:00:14 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313924414.52.0.30274273874.issue12678@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:01:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 11:01:15 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1313924475.88.0.568066422718.issue9993@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you update the documentation?

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:01:53 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 21 Aug 2011 11:01:53 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1313924513.57.0.43726778103.issue4489@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/issue4489>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:04:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 21 Aug 2011 11:04:08 +0000
Subject: [issue4489] shutil.rmtree is vulnerable to a symlink attack
In-Reply-To: <1228232522.58.0.0992151848245.issue4489@psf.upfronthosting.co.za>
Message-ID: <1313924648.98.0.870801972485.issue4489@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4489>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:36:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 11:36:36 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1313926596.9.0.461176861453.issue12803@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've attached a patch that adds an extra password argument, which can be
> either a string, bytes, bytearray, or a function to call to get the password.

It seems a bit strange to me to accept string types or callable in the same argument.  If it just supported strings, people could still write password=somefunction(), right?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 13:58:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 11:58:56 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1313927936.74.0.242031994973.issue10504@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:00:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:00:01 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <1313928001.88.0.215826177567.issue12780@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Barry, could you review the second part of the patch?  (the first was committed)

----------
nosy: +barry
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:03:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:03:34 +0000
Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313928214.75.0.461307149615.issue12781@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to Sandro?s patch.  Documenting all SO_* constants should be another bug; right now, there is only an index entry for ?SO_*?, I suppose for the benefit of C programmers wanting to know where the constants are defined.  I think the reason for not documenting all constants is that people should look them up in a C/kernel reference manual.

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12781>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:05:45 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 21 Aug 2011 12:05:45 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313928345.81.0.566792938986.issue12326@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

So what about doing the same for FreeBSD, SunOS, and Windows?  The conversation about this point sort of trailed off.  But, dammit, a foolish consistency is the hobgoblin of my small mind.

If we're changing "linux2" / "linux3" to just "linux", we should be consistent and do it for everybody.  I propose sys.platform under 3.3 should contain things like "linux", "freebsd", "openbsd", "darwin", and "windows".

I further propose we add a "sys.platform_major_version" which would contain the OS major version number (as an integer!).  That'd be 3 for Linux 3.0, 8 for FreeBSD 8, 32 for Win32, and so on.  That'd let users easily reconstitute the old value of "sys.platform".  (Except on Windows.  But I am strangely averse to setting sys.platform to "win" on Windows.)  Of course, we should determine this value at runtime rather than build time on platforms where the number could change at runtime.  (A counter-example: it need not be late-binding for "windows" 32 vs 64.)

With that addition, we can now address plat-freebsd<x>.:
 * Move the all existing plat-freebsd<x>/IN.py to plat-freebsd/IN<x>.py
 * Write a new plat-freebsd/IN.py that uses sys.platform_version
   to read in the correct IN<x>.py.
 * Alter plat-freebsd/regen to generate IN<x>.py
I suspect plat-freebsd<x> should have used the run-time OS major version all along, so this would be an improvement!  And since FreeBSD is the only OS with more than one plat-* entry, the plat-* problem is solved.

I'm happy to open a new issue discussing this if that's the right thing to do.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:08:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:08:14 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313928494.84.0.78939385273.issue12326@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Larry: the scope of this bug was narrowed to the linux breakage only; see #12795 for other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:13:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:13:09 +0000
Subject: [issue12790] doctest.testmod does not run tests in functools.partial
	functions
In-Reply-To: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za>
Message-ID: <1313928789.91.0.651173362518.issue12790@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/issue12790>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:17:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:17:53 +0000
Subject: [issue12793] allow filters in os.walk
In-Reply-To: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>
Message-ID: <1313929073.4.0.860538089144.issue12793@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  2.7 is a stable version, so this would have to go in 3.3.  Even where, breaking the function signature wouldn?t be possible, so we would have to add arguments without removing any.

Have you looked at shutil.rmtree?s ignore argument and the shutil.ignore_patterns factory function?  Maybe that would be a good pattern to copy.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12793>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:25:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:25:28 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1313929528.08.0.737461926517.issue12798@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Some changes I would like to do
+1 on those.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:26:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:26:26 +0000
Subject: [issue11362] image/webp missing from mimetypes.py
In-Reply-To: <1299002869.89.0.906487136823.issue11362@psf.upfronthosting.co.za>
Message-ID: <1313929586.6.0.367296051826.issue11362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On a related note, the Google-originated video codec WebM is used out there and supported by various software.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11362>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:34:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:34:01 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1313930041.2.0.872963381344.issue1298813@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Sun Aug 21 14:38:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:38:24 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1313930304.83.0.515477760199.issue12797@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/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 21 15:53:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 13:53:39 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1313934819.71.0.749858320243.issue12801@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+   Return a string representing the canonicalized pathname of *path*.

This sounds a bit strange to me; ?Return a string representing the canonical version of *path*?.

Would it be a good idea to use the full docstring of posixpath.realpath to os.realpath and then just do ?realpath = os.realpath? in posixpath?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:03:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 14:03:45 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313935425.61.0.072320858229.issue12776@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  I commented on the code review site, you should have received an email.

----------
nosy: +eric.araujo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:08:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 14:08:22 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
Message-ID: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When I run make test on 3.3 now, I get failures because the tests try to make HTTP requests.

----------
messages: 142621
nosy: eric.araujo, nadeem.vawda
priority: normal
severity: normal
status: open
title: make test should not enable the urlfetch resource
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:23:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 21 Aug 2011 14:23:20 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1313936600.4.0.425189293538.issue12804@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Are the failures because the machine you're running the test on doesn't
have internet access? Or are there problems with some of the tests?

The attached patch should solve the problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file22972/i12804.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:32:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 14:32:28 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1313937148.87.0.429193145392.issue12804@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, the machine did not have Internet access.  Before the run_tests.py patch, the urlfetch resource was not enabled by default.

I don?t want to disconnect to test the patch, but it looks good:
/home/wok/python/3.3/python -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-urlfetch,-audio,-gui

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:33:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 14:33:07 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1313937187.06.0.301320599466.issue12804@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Before the run_tests.py patch, the urlfetch resource was not enabled
> by default.

I?m referring to the addition of run_tests.py, not this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:42:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 14:42:15 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <E1Qv9E6-0003cD-6h@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 228fd2bd83a5 by Nadeem Vawda in branch 'default':
Issue #12804: Prevent "make test" from using network resources.
http://hg.python.org/cpython/rev/228fd2bd83a5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:44:37 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 21 Aug 2011 14:44:37 +0000
Subject: [issue12804] make test should not enable the urlfetch resource
In-Reply-To: <1313935702.14.0.838210022398.issue12804@psf.upfronthosting.co.za>
Message-ID: <1313937877.76.0.281128936602.issue12804@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12804>
_______________________________________

From report at bugs.python.org  Sun Aug 21 16:49:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 14:49:03 +0000
Subject: [issue11651] Improve test targets in Makefile
In-Reply-To: <1300892266.04.0.602974057054.issue11651@psf.upfronthosting.co.za>
Message-ID: <E1Qv9Kf-00045Y-Un@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6c4fa9559b7e by Nadeem Vawda in branch 'default':
Update README section on testing following issue #11651.
http://hg.python.org/cpython/rev/6c4fa9559b7e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11651>
_______________________________________

From report at bugs.python.org  Sun Aug 21 17:07:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 21 Aug 2011 15:07:53 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1313939273.2.0.395402345028.issue11657@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I looked at multiprocessing code, but didn't understand how to trigger a
> call to these functions. Makes it hard to come up with a unit test...

Here's a sample test:
"""
import _multiprocessing
import os
import socket


for i in range(4, 256):
    os.dup2(1, i)

s, r = socket.socketpair()
pid = os.fork()


if pid == 0:
    # child
    fd = _multiprocessing.recvfd(r.fileno())
    f = os.fdopen(fd)
    print(f.read())
    f.close()
else:
    # parent
    f = open('/etc/fstab')
    _multiprocessing.sendfd(s.fileno(), f.fileno())
    f.close()
    os.waitpid(pid, 0)
"""

What happens is that the parent process opens /etc/fstab, and sends the FD to the child process, which prints it.

Now, if I run it with the current code, here's what I get:
"""
cf at neobox:~/cpython$ ./python ~/test.py 
Traceback (most recent call last):
  File "/home/cf/test.py", line 18, in <module>
    _multiprocessing.sendfd(s.fileno(), f.fileno())
OSError: [Errno 9] Bad file descriptor

cf at neobox:~/cpython$ strace -e sendmsg ./python ~/test.py 
sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\10", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {171137285}}, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)
Traceback (most recent call last):
  File "/home/cf/test.py", line 18, in <module>
    _multiprocessing.sendfd(s.fileno(), f.fileno())
OSError: [Errno 9] Bad file descriptor
"""

Duh, it's failing with EBADF.
Why?
    cmsg->cmsg_len = CMSG_LEN(sizeof(int));
    msg.msg_controllen = cmsg->cmsg_len;
    *CMSG_DATA(cmsg) = fd;

Since we only set one byte in CMSG_DATA, if the other bytes are non-zero, the value stored in CMSG_DATA(cmsg) ends up referring to a non existing FD, hence the EBDAF.

With this simple patch:
"""
diff -r e49dcb95241f Modules/_multiprocessing/multiprocessing.c
--- a/Modules/_multiprocessing/multiprocessing.c        Sun Aug 21 12:54:06 2011 +0200
+++ b/Modules/_multiprocessing/multiprocessing.c        Sun Aug 21 16:56:01 2011 +0200
@@ -111,7 +111,7 @@
     cmsg->cmsg_type = SCM_RIGHTS;
     cmsg->cmsg_len = CMSG_LEN(sizeof(int));
     msg.msg_controllen = cmsg->cmsg_len;
-    *CMSG_DATA(cmsg) = fd;
+    *(int *)CMSG_DATA(cmsg) = fd;
 
     Py_BEGIN_ALLOW_THREADS
     res = sendmsg(conn, &msg, 0);
@@ -154,7 +154,7 @@
     if (res < 0)
         return PyErr_SetFromErrno(PyExc_OSError);
 
-    fd = *CMSG_DATA(cmsg);
+    fd = *(int *)CMSG_DATA(cmsg);
     return Py_BuildValue("i", fd);
 }
"""

It works fine.
Note that if you want to check that for FD > 255, you'd have to add something like this at the top:

for i in range(4, 256):
    os.dup2(1, i)

Note that I just used a cast to (int *) instead of memcpy() because CMSG_DATA is actually int-aligned, so there's no risk of unaligned-access, and also it's what's commonly used in the litterature.

So, would you like to add a test along those lines to test_multiprocessing?
AFAICT, multiprocessing.connection is not even documented, but this shows that it really needs some testing...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Sun Aug 21 17:52:46 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 21 Aug 2011 15:52:46 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313941966.04.0.943902469329.issue12326@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

In case of plat-* directories, please see issue #12619, which proposes some changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 18:19:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 16:19:01 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313943541.79.0.547480864424.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks like the patch is not enough:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.2/builds/477/steps/test/logs/stdio/text

Please see #12785 for a patch to packaging.database that should fix test_packaging failures and needs testing on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 18:29:30 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Sun, 21 Aug 2011 16:29:30 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313944170.39.0.306226170085.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

Attached a patch against Python 3.3

All the existing tests are still running successfully.

But I wasn't able to add additional tests for the new functionality. 
Writing proper tests is a bit over my head for now - still learning.

----------
Added file: http://bugs.python.org/file22973/abbrev_subcmds_3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 18:30:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Aug 2011 16:30:40 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313944240.62.0.156540339013.issue12782@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Following on to Georg's comment about expressions, as a workaround, note
that:

  with (
     open('abc')) as foo:

works.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Sun Aug 21 18:39:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 16:39:37 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313944777.19.0.0710571128715.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have to log off for today; another committer can use the attached patch so that we get more info.

----------
Added file: http://bugs.python.org/file22974/tmp-debug.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 18:46:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 16:46:17 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1313945177.51.0.0408888756365.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

test_argparse has a proper test infrastructure so that people don?t have to write the same boilerplate and assertion code over and over again.  If you want, you can probably learn by copy-pasting things.

What you want to test is basically that shortened forms work and conflicting abbreviations report an error.

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Sun Aug 21 19:46:04 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 21 Aug 2011 17:46:04 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313948764.36.0.509649596413.issue12678@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

diff --git a/Lib/distutils/tests/test_sdist.py b/Lib/distutils/tests/test_sdist.py
index 440af98..520289c 100644
--- a/Lib/distutils/tests/test_sdist.py
+++ b/Lib/distutils/tests/test_sdist.py
@@ -381,6 +381,15 @@ class SDistTestCase(PyPIRCCommandTestCase):
 
         self.assertEqual(manifest, ['README.manual'])
 
+        if os.name == 'nt':
+            archive_name = join(self.tmp_dir, 'dist', 'fake-1.0.zip')
+            with zipfile.ZipFile(archive_name, "r", ) as zipfp:
+                archive = zipfp.infolist()
+                filenames = [zipinfo.filename for zipinfo in archive]
+            self.assertEqual(sorted(filenames), ['fake-1.0/PKG-INFO',
+                                                 'fake-1.0/README.manual'])
+            return
+
         archive_name = join(self.tmp_dir, 'dist', 'fake-1.0.tar.gz')
         archive = tarfile.open(archive_name)
         try:

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 19:50:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Aug 2011 17:50:28 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313928345.81.0.566792938986.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E514562.4060108@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So what about doing the same for FreeBSD, SunOS, and Windows?

I agree that's definitely out of scope of this issue.

> If we're changing "linux2" / "linux3" to just "linux", we should be
> consistent and do it for everybody.  I propose sys.platform under 3.3
> should contain things like "linux", "freebsd", "openbsd", "darwin",
> and "windows".

Definitely not. The reasoning that applies to Linux doesn't necessarily
apply to the other systems. My understanding that it definitely does not
apply to HP-UX, where major version number changes really indicate major
changes (unlike in Linux).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Sun Aug 21 20:20:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 18:20:13 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313950813.51.0.0940052357969.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Roumen: I thought too about checking the zipfile on Windows, but with Jeremy?s patch the test force tar.gz generation, so it should amount to the same with less code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 20:24:36 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Sun, 21 Aug 2011 18:24:36 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1313951076.98.0.991686855127.issue12803@psf.upfronthosting.co.za>


Adam Simpkins <adam at adamsimpkins.net> added the comment:

> It seems a bit strange to me to accept string types or callable in the 
> same argument.  If it just supported strings, people could still write
> password=somefunction(), right?

The function is only called if the private key is encrypted and a 
password is necessary.  This allows the code to only prompt for a 
password if it is actually needed.

This also parallels the OpenSSL C API, which only accepts a function to
get the password.  I added support for plain strings as a convenience.  
The string argument will be ignored if the file is not encrypted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 20:56:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 21 Aug 2011 18:56:24 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1313952984.3.0.478037038624.issue12792@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Behaviors' is quite legal. However,
"behavior
    Wrong or unexpected behaviors/results/exceptions. ..."
could well be
"behavior
    Wrong or unexpected behavior, result, or exception. ..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Sun Aug 21 21:15:43 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 21 Aug 2011 19:15:43 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1313954143.68.0.428911579858.issue12721@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

While writing my tests I realized, it would be really useful to make write_file() return the path it wrote to. I need the concatenated filenames most of the time, so I'm getting blocks of:

fn = os.path.join(x,y)
write_file(fn, 'contents')

I'd prefer:
fn = write_file((x,y), 'contents')

Any thoughts? IMHO a write_file that concats path but doesn't return it is only useful in the tree-functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12721>
_______________________________________

From report at bugs.python.org  Sun Aug 21 21:42:51 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Sun, 21 Aug 2011 19:42:51 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1313955771.98.0.0992792804542.issue12803@psf.upfronthosting.co.za>


Adam Simpkins <adam at adamsimpkins.net> added the comment:

Here's a new patch that accepts any callable.  The old patch only accepted
actual function objects.

----------
Added file: http://bugs.python.org/file22975/ssl-password.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Sun Aug 21 21:49:53 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 21 Aug 2011 19:49:53 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313956193.16.0.266131720482.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Looks like the patch is not enough:
> http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.2/builds/477/steps/test/logs/stdio/text

That's a 3.2 builder. You only committed Jeremy's fix to default. I've tested
the fix on 3.2 on my own XP system, and it seems to fix the sdist failure.
test_install.InstallTestCase.test_record_extensions still fails, though.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 21:58:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 21 Aug 2011 19:58:51 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1313956731.42.0.167707558376.issue12785@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

With the patch applied, I still get failures in test_old_record_extensions
and test_record_basic, so it doesn't seem to work.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Sun Aug 21 22:01:41 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 21 Aug 2011 20:01:41 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1313956901.32.0.0535334614912.issue11657@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Yes, Charles - the test is not only welcome, but needed - it just can't rely on reading /etc/fstab ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Sun Aug 21 22:02:51 2011
From: report at bugs.python.org (Jesse Noller)
Date: Sun, 21 Aug 2011 20:02:51 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1313956971.1.0.826679357369.issue11657@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Charles; you have +commit, it seems. I would welcome the patch and test (just as long as the aforementioned reliance on /etc/fstab was removed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Sun Aug 21 22:36:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 20:36:42 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QvEl6-0002IG-MN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c8e73a89150e by Nadeem Vawda in branch '3.2':
Issue #12678: Fix distutils sdist test on Windows.
http://hg.python.org/cpython/rev/c8e73a89150e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 22:40:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Aug 2011 20:40:28 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QvEol-0002Yf-01@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d40856e424fd by Nadeem Vawda in branch '2.7':
Issue #12678: Fix distutils sdist test on Windows.
http://hg.python.org/cpython/rev/d40856e424fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Sun Aug 21 22:55:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 21 Aug 2011 20:55:06 +0000
Subject: [issue12783] test_posix failure on FreeBSD 6.4:
	test_get_and_set_scheduler_and_param
In-Reply-To: <1313751328.54.0.186872494969.issue12783@psf.upfronthosting.co.za>
Message-ID: <1313960106.07.0.0821319883095.issue12783@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

The test now passes on FreeBSD buildbots.
Closing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12783>
_______________________________________

From report at bugs.python.org  Sun Aug 21 23:01:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 21 Aug 2011 21:01:45 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1313956971.1.0.826679357369.issue11657@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1AyHzAvJgrHmMcWXz7Cs6JNWgP0fmFab=WwDXoHQVM8Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Charles; you have +commit, it seems.

Yeah, I could of course do this myself, but since Petri already
submitted a patch and seemed to be willing to update it with a test, I
thought he might be interested in this (I've also seen he's
participating to core-mentorship, so this would be a opportunity to
help fixing a bug).
As for the reliance on /etc/fstab, it was of course just a standalone
example to demonstrate how one could test this corner-case ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Mon Aug 22 00:10:59 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 21 Aug 2011 22:10:59 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1313964659.95.0.828044039653.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

The sdist failure is now fixed on the 3.2 XP builders.
test_record_extensions still needs attention, though.

I also tried backporting Jeremy's fix to 2.7, but that doesn't seem to
have worked; the sdist tests is still failing there. Someone who
actually knows what they're doing should probably have a look at it at
some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Mon Aug 22 01:27:03 2011
From: report at bugs.python.org (Brian May)
Date: Sun, 21 Aug 2011 23:27:03 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1313969223.22.0.733854342827.issue6560@psf.upfronthosting.co.za>


Changes by Brian May <brian at microcomaustralia.com.au>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Aug 22 01:27:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Aug 2011 23:27:34 +0000
Subject: [issue12788] test_email fails with -R
In-Reply-To: <1313802442.52.0.218487753455.issue12788@psf.upfronthosting.co.za>
Message-ID: <1313969254.95.0.897263327102.issue12788@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12788>
_______________________________________

From report at bugs.python.org  Mon Aug 22 02:43:56 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 22 Aug 2011 00:43:56 +0000
Subject: [issue12805] Optimzations for bytes.join() et. al
Message-ID: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

I noticed there are a few more common cases that can be sped up in bytes.join().

When:
 - The sequence length and separator length are both 0
 - The separator length is 0 or 1
 - The separator string contains only 1 distinct byte

These could also be applied to other sequence types.

for i in {{0..5}}; do
./python -m timeit -s "f=open('/usr/share/dict/words', 'rb'); L=f.readlines()" \
"b' '.join(L)"; 
done

- BEFORE -
100 loops, best of 3: 3.79 msec per loop
100 loops, best of 3: 3.5 msec per loop
100 loops, best of 3: 3.75 msec per loop
- AFTER -
100 loops, best of 3: 2.81 msec per loop
100 loops, best of 3: 2.81 msec per loop
100 loops, best of 3: 3.03 msec per loop

~20% speedup

Same test on a smaller list (lines from LICENSE file) yields a similar 15-20% speedup.
Same test on L = [b'1', b'2', b'3'] yields 10% speedup

----------
components: Interpreter Core
files: bytes_join_optimization.patch
keywords: patch
messages: 142650
nosy: benjamin.peterson, ezio.melotti, haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: Optimzations for bytes.join() et. al
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file22976/bytes_join_optimization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12805>
_______________________________________

From report at bugs.python.org  Mon Aug 22 02:46:18 2011
From: report at bugs.python.org (Graylin Kim)
Date: Mon, 22 Aug 2011 00:46:18 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
Message-ID: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>


New submission from Graylin Kim <graylin.kim at gmail.com>:

When using argparse I frequently run into situations where my helper text is a mix of prose and bullets or options. I need the RawTextFormatter for the bullets, and I need the default formatter for the prose (so the line wraps intelligently).

The current HelpFormatter classes are marked as public by name only, so sub-classing them with overrides to get the desired functionality isn't great unless it gets pushed upstream. To that end, I've attached a subclass implementation that I've been using for the following effect:

Example:
    >>> parser = argparse.ArgumentParser(formatter_class=FlexiFormatter)
    >>> parser.add_argument('--example', help='''\
    ...     This argument's help text will have this first long line\
    ...     wrapped to fit the target window size so that your text\
    ...     remains flexible.
    ...
    ...         1. This option list
    ...         2. is still persisted
    ...         3. and the option strings get wrapped like this with an\
    ...            indent for readability.
    ...
    ...     You must use backslashes at the end of lines to indicate that\
    ...     you want the text to wrap instead of preserving the newline.
    ...    
    ...     As with docstrings, the leading space to the text block is\
    ...     ignored.
    ... ''')
    >>> parser.parse_args(['-h'])

    usage: argparse_formatter.py [-h] [--example EXAMPLE]

    optional arguments:
      -h, --help         show this help message and exit
      --example EXAMPLE  This argument's help text will have this first
                         long line wrapped to fit the target window size
                         so that your text remains flexible.

                             1. This option list
                             2. is still persisted
                             3. and the option strings get wrapped like
                                this with an indent for readability.

                         You must use backslashes at the end of lines to
                         indicate that you want the text to wrap instead
                         of preserving the newline.

                         As with docstrings, the leading space to the
                         text block is ignored.


                                 1. This option list
                                 2. is still persisted
                                 3. and the option strings get wrapped like
                                    this with an indent for readability.

                             You must use backslashes at the end of lines to
                             indicate that you want the text to wrap instead
                             of preserving the newline.

                             As with docstrings, the leading space to the
                             text block is ignored.


If there is interest in this sort of thing I'd be happy to fix it up for inclusion.

----------
components: Library (Lib)
files: argparse_formatter.py
messages: 142651
nosy: GraylinKim
priority: normal
severity: normal
status: open
title: argparse: Hybrid help text formatter
versions: Python 2.7
Added file: http://bugs.python.org/file22977/argparse_formatter.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Mon Aug 22 02:56:08 2011
From: report at bugs.python.org (Graylin Kim)
Date: Mon, 22 Aug 2011 00:56:08 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1313974568.96.0.118945256288.issue12806@psf.upfronthosting.co.za>


Graylin Kim <graylin.kim at gmail.com> added the comment:

I just noticed that the example output above repeats with a different indent. The attached formatter isn't broken, I just messed up the editing on my post. The repeated text isn't part of the output (and shouldn't be there).

While I'm certainly at fault here, a feature to preview your post before final submission would likely help people like me to catch these sorts of errors before spamming the world with them. :)

Apologies for the double post.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:21:44 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 22 Aug 2011 01:21:44 +0000
Subject: [issue12805] Optimizations for bytes.join() et. al
In-Reply-To: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za>
Message-ID: <1313976104.22.0.694647107232.issue12805@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
title: Optimzations for bytes.join() et. al -> Optimizations for bytes.join() et. al

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12805>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:46:15 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Mon, 22 Aug 2011 01:46:15 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313977575.82.0.633120941263.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine <arnau at debian.org> added the comment:

Thanks for the review. Sorry to send that here instead of the review page, but I get an error when replying: "Invalid XSRF token.".

> This looks good, especially if all existing tests still pass as you report, but
> I wonder about one thing: you have removed the part where the conversion
> function was applied to the default value, so I expected you to edit the other
> line were the conversion function was already called, but that?s not the case. 
> Am I misunderstanding something?

Yes, sorry, I should have perhaps explained it in further details... Here are some examples:

* Example test case 1:

parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('--foo bar'.split())

=> Before the patch, type function is called in parse_known_args() for the default given in add_argument(), and then in _parse_known_args() for '--foo bar' given in parse_args above, whereas type function should have been called only for the second one.

* Example test case 2:

parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func)
parser.parse_args('--foo bar'.split())

=> This was already working well before my patch.

* Example test case 3:

parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('')

=> type_foo_func is called after parsing arguments (none in this case) in my patch.

Therefore, my patch just moves the function type call after parsing the arguments (given to parse_args()) instead of before, only and only if it was not previously given in parse_args().

> http://bugs.python.org/review/12776/diff/3181/9898#newcode1985
> Lib/argparse.py:1985: if hasattr(namespace, action.dest) and \
> It is recommended to use parens to group multi-line statements, backslashes are
> error-prone.

I have just updated the patch on the bug report. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:47:27 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Mon, 22 Aug 2011 01:47:27 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313977647.97.0.843103221754.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Removed file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:47:34 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Mon, 22 Aug 2011 01:47:34 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313977654.7.0.945370338123.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Removed file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:48:51 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Mon, 22 Aug 2011 01:48:51 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313977731.42.0.0615952209137.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file22978/py2.7-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:49:03 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Mon, 22 Aug 2011 01:49:03 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1313977743.46.0.368826483139.issue12776@psf.upfronthosting.co.za>


Changes by Arnaud Fontaine <arnau at debian.org>:


Added file: http://bugs.python.org/file22979/py3k-argparse-call-type-function-once.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12776>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:52:19 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 01:52:19 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1313977939.51.0.812279449494.issue10951@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

this fixes the pickle warnings, and cleans up some (I'm pretty sure) dead code in there.  the pickle tests all pass.

----------
keywords: +patch
nosy: +poolie
Added file: http://bugs.python.org/file22980/20110822-1150-python-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:53:12 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 01:53:12 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1313977992.04.0.489483028126.issue9893@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

Here is a first pass at the README.vim file. Suggestions welcome from VIM power-users!

----------
nosy: +gjcross
Added file: http://bugs.python.org/file22981/README.vim

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Mon Aug 22 03:56:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 01:56:14 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <E1QvJkL-0004iI-BU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c64216addd7f by Nick Coghlan in branch 'default':
Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes #6560)
http://hg.python.org/cpython/rev/c64216addd7f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Aug 22 04:08:34 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 02:08:34 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1313978914.55.0.0774711083386.issue11561@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added Ned to the nosy list.

For Python core, we should also keep in mind that we do have the option of adding a -X coverage option to avoid the need for the encodings module hack.

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11561>
_______________________________________

From report at bugs.python.org  Mon Aug 22 04:18:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 02:18:03 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1313979483.37.0.138489380622.issue12782@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Georg noted, only individual expressions get parentheses based continuations automatically. For statement level use of comma separation, it's decided on a case-by-cases basis as to whether we think it is a legitimate usage based on our style guidelines.

That's why 'from location import (name1, name2)' is allowed, but 'import (name1, name2)' is not: we explicitly advise against importing too many modules in a single import statement, but importing multiple names from a single location is often a useful thing to do.

However, while the multiple context expression use case is reasonable, there may be a grammar ambiguity problem in this case, since (unlike from-import) with statements allow arbitrary subexpressions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Mon Aug 22 04:18:56 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 22 Aug 2011 02:18:56 +0000
Subject: [issue11561] "coverage" of Python regrtest cannot see initial import
	of libs
In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za>
Message-ID: <1313979536.16.0.134886668304.issue11561@psf.upfronthosting.co.za>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

The tip of the coverage.py repo (https://bitbucket.org/ned/coveragepy) has a new implementation of the encodings hack which seems to work well.

Of course, an option to run a module before anything else in the interpreter would make the whole thing much simpler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11561>
_______________________________________

From report at bugs.python.org  Mon Aug 22 04:53:25 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 22 Aug 2011 02:53:25 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1313981605.91.0.505115779155.issue12715@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Mon Aug 22 04:59:01 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 22 Aug 2011 02:59:01 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
Message-ID: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>


New submission from John O'Connor <tehjcon at gmail.com>:

bytearray() is using a less efficient implementation of split() than its similar friends bytes and unicode.

I added a couple extra checks to return early in {bytes,unicode} split().
 - if length is 0
 - if left strip removed all bytes

Looking at just how similar these 3 implementations are I feel that we could also unify/generalize them into one generic helper implementation and leave the object marshaling up to the type specific methods.

----------
components: Interpreter Core
files: strip_perf.patch
keywords: patch
messages: 142660
nosy: benjamin.peterson, ezio.melotti, haypo, jcon, pitrou
priority: normal
severity: normal
status: open
title: Optimizations for {bytearray,bytes,unicode}.strip()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file22982/strip_perf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Mon Aug 22 05:22:52 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 03:22:52 +0000
Subject: [issue12808] Coverage of codecs.py
Message-ID: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>


New submission from Tennessee Leeuwenburg <tleeuwenburg at gmail.com>:

Increases the coverage of codecs.py by about 3 lines...

----------
files: mywork.patch
keywords: patch
messages: 142661
nosy: ncoghlan, tleeuwenburg
priority: normal
severity: normal
status: open
title: Coverage of codecs.py
versions: Python 3.4
Added file: http://bugs.python.org/file22983/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 05:23:35 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 03:23:35 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1313983415.41.0.554547434636.issue12808@psf.upfronthosting.co.za>


Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Also some pep8 compliance outside of the scope of the added lines of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 05:26:52 2011
From: report at bugs.python.org (Michael Farrell)
Date: Mon, 22 Aug 2011 03:26:52 +0000
Subject: [issue12809] Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
Message-ID: <1313983612.44.0.0564079708334.issue12809@psf.upfronthosting.co.za>


New submission from Michael Farrell <micolous+py at gmail.com>:

Recently, iptables has added support for transparent proxies using a new TPROXY target on Linux2.  This requires a new option in setsockopts, IP_TRANSPARENT.  There's some background on the feature here:

http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt

I've created a patch to the header regen scripts on Linux2 that should expose this functionality to Python.  They'll need to be run to generate the headers again.

I notice that `_socket` doesn't include the names of socket options from this location, instead using a local database.  I had trouble trying to get `linux/in.h` included in that file, so I included a work-around which defines it statically for now.

It needs some work but it causes a lot of breakage when I try to do this -- and I don't know enough about the Linux sockets API to fix this properly.

----------
components: Library (Lib)
files: extra_linux_sockopts.diff
keywords: patch
messages: 142663
nosy: micolous
priority: normal
severity: normal
status: open
title: Missing new setsockopts in Linux (eg: IP_TRANSPARENT)
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22984/extra_linux_sockopts.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12809>
_______________________________________

From report at bugs.python.org  Mon Aug 22 05:29:40 2011
From: report at bugs.python.org (Mihai Ibanescu)
Date: Mon, 22 Aug 2011 03:29:40 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1313983780.9.0.782730248859.issue1298813@psf.upfronthosting.co.za>


Mihai Ibanescu <mihai.ibanescu at gmail.com> added the comment:

It's a real shame the original patch was not applied before py3k was branched, the code is now different.

Antoine, my autoconf knowledge is limited, I don't know how you'd test for realpath accepting a NULL argument (and doing the right thing) at compile time.

My involvement with this bug is fairly limited at this point, I would like to see it fixed, but having seen no movement on it for almost 6 years now, maybe it's not as critical as I thought it was.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Mon Aug 22 05:57:39 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 03:57:39 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1313985459.47.0.595845676768.issue10951@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

This fixes every compiler warning so that Python build with -Werror on Ubuntu Oneiric alpha (gcc 4.6.1-7ubuntu1).  

 * PyMem_Resize is a macro that mutates its first argument; the return value shouldn't be used.
 * Some variables in sre are (apparently harmlessly) not used when validating the opcodes.
 * gethostbyname_r return codes weren't used and should be; it is not guaranteed to set h_errno correctly (though it does seem to do so here)
 * a few vairables in pthread and tkappintr are not used in some preprocessor productions.
 * setup.py should detect linux kernel 3.0 as linux, and therefore able to build ossaudiodev

I don't get all the errors mentioned by haypo.  At least some seem already fixed.

----------
Added file: http://bugs.python.org/file22985/20110822-1352-gcc-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Mon Aug 22 06:15:28 2011
From: report at bugs.python.org (John Chandler)
Date: Mon, 22 Aug 2011 04:15:28 +0000
Subject: [issue11159] Sax parser crashes if given unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <1313986528.59.0.990034467907.issue11159@psf.upfronthosting.co.za>


John Chandler <therealmetaljoe at gmail.com> added the comment:

Confirmed about not being an issue in Python 3. Just checked with Python 3.3.0a0 and the example works fine - no exception raised.

----------
nosy: +John.Chandler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11159>
_______________________________________

From report at bugs.python.org  Mon Aug 22 06:21:27 2011
From: report at bugs.python.org (Anthony Briggs)
Date: Mon, 22 Aug 2011 04:21:27 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1313986887.46.0.379674813861.issue6484@psf.upfronthosting.co.za>


Changes by Anthony Briggs <anthony.briggs at gmail.com>:


----------
nosy: +anthonyb, ncoghlan
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Mon Aug 22 06:24:51 2011
From: report at bugs.python.org (Anthony Briggs)
Date: Mon, 22 Aug 2011 04:24:51 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1313987091.36.0.592455778562.issue6484@psf.upfronthosting.co.za>


Anthony Briggs <anthony.briggs at gmail.com> added the comment:

Added ncoghlan to the nosy list - we're reviewing/fixing unit test coverage as part of the sprints at PyconAU. Thanks Gnofi!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Mon Aug 22 06:39:27 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 04:39:27 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313987967.04.0.743295621052.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

Threading module docstrings added for all classes and public methods; mainly used a summarised version of information from the documentation.

----------
keywords: +patch
nosy: +gjcross
Added file: http://bugs.python.org/file22986/threading_docstrings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Mon Aug 22 06:56:15 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 04:56:15 +0000
Subject: [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313988975.84.0.652953683692.issue12767@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

I have added documentation for the 'n' parameter of threading.Condition.notify as part of the overhaul of the threading module's docstrings.

Reference: #12768

----------
nosy: +gjcross

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12767>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:11:15 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:11:15 +0000
Subject: [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313989875.14.0.814244389052.issue1215@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

The documentation for this can now point to the faulthandler module (in Python 3).

----------
nosy: +poolie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:11:33 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:11:33 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313987967.04.0.743295621052.issue12768@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-j0oCzV0_=BSH3NvPWuKmiDgdGWiLjJpHwsCmuh3PvFA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Mon, Aug 22, 2011 at 07:39, Graeme Cross <report at bugs.python.org> wrote:

>
> Graeme Cross <gjcross at gmail.com> added the comment:
>
> Threading module docstrings added for all classes and public methods;
> mainly used a summarised version of information from the documentation.
>

Thanks for the patch, Graeme.
I will try to find time to review and apply it in a few days, if no one else
will do it until then.

Eli

----------
Added file: http://bugs.python.org/file22987/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________
-------------- next part --------------
<div dir="ltr"><div class="gmail_quote">On Mon, Aug 22, 2011 at 07:39, Graeme Cross <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Graeme Cross &lt;<a href="mailto:gjcross at gmail.com">gjcross at gmail.com</a>&gt; added the comment:<br>
<br>
Threading module docstrings added for all classes and public methods; mainly used a summarised version of information from the documentation.<br></blockquote></div><br><br>Thanks for the patch, Graeme.<br>I will try to find time to review and apply it in a few days, if no one else will do it until then.<br>

<br>Eli<br></div>

From report at bugs.python.org  Mon Aug 22 07:12:28 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:12:28 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313989948.81.0.502072679707.issue12768@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file22987/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:12:52 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:12:52 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313989972.22.0.581278598365.issue12768@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Graeme - could you specify which version of Python this patch applies to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:15:01 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:15:01 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313990101.42.0.918489352653.issue1215@psf.upfronthosting.co.za>


Changes by Martin Pool <mbp at sourcefrog.net>:


----------
title: Python hang when catching a segfault -> documentation doesn't say that you can't handle C segfaults from python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:18:05 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 05:18:05 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313990285.85.0.624896121738.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

The patch applies to tip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:23:54 2011
From: report at bugs.python.org (Joel)
Date: Mon, 22 Aug 2011 05:23:54 +0000
Subject: [issue12810] Remove check for negative unsigned value in
	socketmodule.c
Message-ID: <1313990634.15.0.242436957417.issue12810@psf.upfronthosting.co.za>


New submission from Joel <joel at jms.id.au>:

fixes the following warning:

cpython/Modules/socketmodule.c:1748:74: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
    if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0)

----------
files: bad_unsigned_check.patch
keywords: patch
messages: 142674
nosy: shenki
priority: normal
severity: normal
status: open
title: Remove check for negative unsigned value in socketmodule.c
Added file: http://bugs.python.org/file22988/bad_unsigned_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12810>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:27:06 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:27:06 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313990826.85.0.105524850764.issue1215@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

This patch tries to improve the documentation a bit more to address the issue that confused tebeka and to advertise faulthandler.  Could someone review or apply it?

----------
keywords: +patch
Added file: http://bugs.python.org/file22989/20110822-1525-signal-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:30:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 05:30:26 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1313991026.57.0.929300839495.issue12808@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Tennessee, there were a few issues in the original patch - see the attached update (mostly the use of assert statements instead of methods and the overbroad scope of the context manager when checking for an expected exception).

However, in getting ready to commit this, I noticed something interesting. The docs for the IncrementalEncoder.getstate() API [1] state that the value returned *must* be an integer.

BufferedIncrementalEncoder doesn't obey that limitation - when data is buffered, it returns the raw buffered string instead of encoding it as some kind of integer.

As a separate, but related point, IncrementalDecoder.getstate() includes an explanation on how to save arbitrary state as an integer, but no such explanation (not even a reference to the IncrementalDecoder version) is present in the IncrementalEncoder.getstate() docs.

Adding MAL, since I'd like an expert opinion. Is the API less stringent than the docs state, or should BufferedIncrementalEncoder be fixed to always return the state as an integer?

[1] http://docs.python.org/dev/library/codecs#codecs.IncrementalEncoder.getstate

----------
nosy: +lemburg
Added file: http://bugs.python.org/file22990/issue12808_codecs_coverage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:38:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 22 Aug 2011 05:38:14 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <CAH_1eM1AyHzAvJgrHmMcWXz7Cs6JNWgP0fmFab=WwDXoHQVM8Q@mail.gmail.com>
Message-ID: <20110822053757.GA9441@p16>


Petri Lehtinen <petri at digip.org> added the comment:

Charles-Fran?ois Natali wrote:
> Yeah, I could of course do this myself, but since Petri already
> submitted a patch and seemed to be willing to update it with a test, I
> thought he might be interested in this (I've also seen he's
> participating to core-mentorship, so this would be a opportunity to
> help fixing a bug).

I'm fine if you fix it, as I'm currently really short on time myself.

When I was skimming through the multiprocessing tests a month ago, I
noticed that much of the multiprocessing test suite is disabled, and
it confused me. That was one reason why I didn't write a test right
away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Mon Aug 22 07:53:19 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Aug 2011 05:53:19 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1313992399.3.0.444837527833.issue12326@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Where's the doc updates for the stable branches?

Also, we might think about removing this version number everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:05:57 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 06:05:57 +0000
Subject: [issue10713] re module doesn't describe string boundaries for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1313993157.96.0.936422741611.issue10713@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

> Note, 366 above confirms it's never true for an empty string.  The
documentation states that \B "is just the opposite of \b" yet
re.match(r'\b', '') returns None and so does \B so \B isn't the opposite
of \b in all cases.

This is also a bit strange if you follow the Perl line of reasoning of imagining there are non-word characters outside the string.  And, indeed, in Perl, 

  "" =~ /\B/

is true.

So this patch adds some tests for \b behaviour and some docs.  I think possible \B should actually change, but that would be a bigger (perhaps impossible?) change.

----------
keywords: +patch
nosy: +poolie
Added file: http://bugs.python.org/file22991/20110822-1604-re-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10713>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:06:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 06:06:02 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <E1QvNe4-0005Di-I7@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 69cb66ab61cc by Nick Coghlan in branch 'default':
Add unit tests for the mailcap module. Patch by Gregory Nofi (closes #6484)
http://hg.python.org/cpython/rev/69cb66ab61cc

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:07:54 2011
From: report at bugs.python.org (Anthony Briggs)
Date: Mon, 22 Aug 2011 06:07:54 +0000
Subject: [issue12811] Tabnanny doesn't close its tokenize files properly
Message-ID: <1313993274.27.0.419233910291.issue12811@psf.upfronthosting.co.za>


New submission from Anthony Briggs <anthony.briggs at gmail.com>:

Unlike Python 2, Python 3 warns when files aren't closed properly, which raises lots of warnings when running tabnanny:

~/devinabox/cpython$ ./python -m tabnanny Lib/
/home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file <_io.TextIOWrapper name='Lib/sunau.py' mode='r' encoding='utf-8'>
  check(fullname)
/home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file <_io.TextIOWrapper name='Lib/sre_compile.py' mode='r' encoding='utf-8'>
  check(fullname)
/home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file <_io.TextIOWrapper name='Lib/this.py' mode='r' encoding='utf-8'>
  check(fullname)
/home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file <_io.TextIOWrapper name='Lib/difflib.py' mode='r' encoding='utf-8'>
  check(fullname)

The attached patch fixes the problem.

----------
components: Library (Lib)
files: tabnanny_close_file.patch
keywords: patch
messages: 142681
nosy: anthonyb, ncoghlan
priority: normal
severity: normal
status: open
title: Tabnanny doesn't close its tokenize files properly
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file22992/tabnanny_close_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12811>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:16:34 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 06:16:34 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1313993794.26.0.284914547398.issue10951@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

My patch above fixes all the messages so that you get a clean build with the current makefile.

-Wuninitialized and 'offset outside constant string' would be worth fixing but I can't reproduce them in Python.

I'm personally not so keen on fixing all the signed/unsigned comparisons unless they're checked by the default build, because in my experience that has a pretty low payoff and some chance of introducing errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10951>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:19:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 06:19:39 +0000
Subject: [issue12811] Tabnanny doesn't close its tokenize files properly
In-Reply-To: <1313993274.27.0.419233910291.issue12811@psf.upfronthosting.co.za>
Message-ID: <E1QvNrF-00062V-RO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c5cb0aa5bed6 by Nick Coghlan in branch 'default':
Fix #12811 by closing files promptly in tabnanny.check. Patch by Anthony Briggs.
http://hg.python.org/cpython/rev/c5cb0aa5bed6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12811>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:25:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 06:25:26 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1313994326.26.0.268817399166.issue11657@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For 3.3, it may be relevant that send/recvmsg are now available via the socket API (see #6560)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:29:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 06:29:57 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <E1QvNzM-0006dg-HC@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 37721ee145a2 by Nick Coghlan in branch 'default':
Credit patch authors in NEWS for #6560
http://hg.python.org/cpython/rev/37721ee145a2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:30:56 2011
From: report at bugs.python.org (Joel)
Date: Mon, 22 Aug 2011 06:30:56 +0000
Subject: [issue12812] libffi does not build with clang on amd64
Message-ID: <1313994656.23.0.148190380431.issue12812@psf.upfronthosting.co.za>


New submission from Joel <joel at jms.id.au>:

tl;dr libffi needs to be updated so Python will build with clang on Linux on amd64

libffi, part of ctypes, has a test for PC relative relocations. It assembles a assembler file with CC, and looks for the string "warning" in the output.

clang produces harmless warning unrelated to the assembly operation, but the test causes HAVE_AS_X86_PCREL to be left unset. When trying to assemble Modules/_ctypes/libffi/src/x86/unix64.S, the compiler finds invalid syntax and the build fails.

This was raised on the libffi mailing list, with a proposed patch 

  http://sourceware.org/ml/libffi-discuss/2011/msg00024.html

The patch appears to be part of upstream libffi:

 https://github.com/atgreen/libffi/blob/master/configure.ac#L296

So perhaps the best fix would be to update the version of libffi in the tree.

----------
components: Build
messages: 142686
nosy: shenki
priority: normal
severity: normal
status: open
title: libffi does not build with clang on amd64

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12812>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:41:02 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 06:41:02 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1313995262.99.0.367654359784.issue7584@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

Z is well established as meaning "UTC time" <http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Time_zones> so shouldn't be used for "zone not known."  rfc 3393 is clear that it's equivalent to +00:00.  

So the questions seem to be:
 * should there be an included battery to do this format at all?
 * should it represent utc as '+00:00' or as 'Z' by default - applications should have the choice.

It's probably reasonable to assume correct Python application code using datetime objects will know whether they have a local, utc, or unknown time.

The current patch does not seem to have any way to format an object with a declared UTC tzinfo as having a 'Z' prefix, which would be useful.

----------
nosy: +poolie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:41:41 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 22 Aug 2011 06:41:41 +0000
Subject: [issue12813] uuid4 is not tested if a uuid4 system routine isn't
	present
Message-ID: <1313995301.93.0.316946106703.issue12813@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

The uuid.uuid4 function is not tested if a C system routine is not present, despite that uuid4 has several fallback clauses. This patch will test at least the first fallback.

----------
components: Library (Lib)
files: uuid4-test-no-system-routine-fallback.patch
keywords: patch
messages: 142688
nosy: anacrolix
priority: normal
severity: normal
status: open
title: uuid4 is not tested if a uuid4 system routine isn't present
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file22993/uuid4-test-no-system-routine-fallback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12813>
_______________________________________

From report at bugs.python.org  Mon Aug 22 08:52:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 06:52:38 +0000
Subject: [issue12814] Possible intermittent bug in test_array
Message-ID: <1313995958.58.0.615032794438.issue12814@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Had a weird bug in test_array.test_tofromstring failing on Gentoo by generating too few warning messages:
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/568/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2262/steps/test/logs/stdio

Can't see anything obvious as to why that might fail sometimes or only on specific platforms (note that the subsequent build of the x86 Gentoo box worked OK). None of my checkins today should have affected anything like this.

----------
messages: 142689
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Possible intermittent bug in test_array

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12814>
_______________________________________

From report at bugs.python.org  Mon Aug 22 09:13:15 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 22 Aug 2011 07:13:15 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <E1QvJkL-0004iI-BU@dinsdale.python.org>
Message-ID: <CAH_1eM3RyGr52JxPjmMR7doXzSFuCJ3oRYx==06=eeR1=pvoWg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> New changeset c64216addd7f by Nick Coghlan in branch 'default':
> Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes #6560)
> http://hg.python.org/cpython/rev/c64216addd7f
>

I had actually started doing a review, I should have said so...
There was nothing spectacular though, so I'll just make some updates later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Aug 22 09:15:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 22 Aug 2011 07:15:06 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1313994326.26.0.268817399166.issue11657@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3UU4Pr1Ouk8_sQ6Abcbim=jqcDn=rb2FvdOXg=9ZknmQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I'm fine if you fix it, as I'm currently really short on time myself.

OK, I'll go ahead.

> For 3.3, it may be relevant that send/recvmsg are now available via the socket API (see #6560).

Indeed. We might still need C code for the Windows part (I won't be
able to help much with Windows, I'm blissfully ignorant).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Mon Aug 22 09:58:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Aug 2011 07:58:22 +0000
Subject: [issue12775] immense performance problems related to the garbage
	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313999902.76.0.277264683177.issue12775@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For the record, the speed improvement in 2.7 likely results from 79276316b94b. GC used to be quadratic with the number of objects, and is now only linear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12775>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:02:37 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Aug 2011 08:02:37 +0000
Subject: [issue12780] Clean up tests for pyc/pyo in __file__
In-Reply-To: <1313687680.79.0.253573735588.issue12780@psf.upfronthosting.co.za>
Message-ID: <1314000157.67.0.66290247395.issue12780@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Seems reasonable to me.  When did/does unicodedata ever have a __file__ attribute?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12780>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:07:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 08:07:23 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313992399.3.0.444837527833.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E520E35.3030004@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Where's the doc updates for the stable branches?

I don't know how to update this documentation. Can someone update the 
doc, or suggest a patch?

> Also, we might think about removing this version number everywhere.

Please, see my issue http://bugs.python.org/issue12795 for this topic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:13:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 08:13:05 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314000785.27.0.735158400503.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Someone here at the sprints pointed out a redundant unsigned comparison to 0 that I missed, so a second set of eyes to double-check things like that would be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:15:08 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 08:15:08 +0000
Subject: [issue12811] Tabnanny doesn't close its tokenize files properly
In-Reply-To: <1313993274.27.0.419233910291.issue12811@psf.upfronthosting.co.za>
Message-ID: <1314000908.61.0.256574827915.issue12811@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy:  -python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12811>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:25:07 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 08:25:07 +0000
Subject: [issue12815] Coverage of smtpd.py
Message-ID: <1314001507.51.0.00455911966964.issue12815@psf.upfronthosting.co.za>


New submission from Tennessee Leeuwenburg <tleeuwenburg at gmail.com>:

Okay, I really don't know if I'm doing the right things to test meaningfully here. However, 100% coverage of the PureProxy class has been achieved.

I also slightly changed smtpd.py in a way that I'm not confident is what people would want. I pushed one print statement into the debug stream, and raised an exception in a place where it looked like the expected behaviour wasn't properly defined, but it's probably not a good place to fail if you're using the code.

I'm also not an SMTP expert... yes there's an RFC but I was going for coverage with "just enough" correctness.

I'm more than happy to revisit this work if anyone has any comments or issues, so just let me know.

----------
files: PureProxy.diff
keywords: patch
messages: 142696
nosy: giampaolo.rodola, ncoghlan, tleeuwenburg
priority: normal
severity: normal
status: open
title: Coverage of smtpd.py
Added file: http://bugs.python.org/file22994/PureProxy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12815>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:30:50 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 08:30:50 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1313992399.3.0.444837527833.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E5213B8.9000001@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Georg Brandl wrote:
> 
> Also, we might think about removing this version number everywhere.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:40:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 08:40:32 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E514562.4060108@v.loewis.de>
Message-ID: <4E5215FE.3090107@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> So what about doing the same for FreeBSD, SunOS, and Windows?
> 
> I agree that's definitely out of scope of this issue.

We could change the title of the ticket :-)

>> If we're changing "linux2" / "linux3" to just "linux", we should be
>> consistent and do it for everybody.  I propose sys.platform under 3.3
>> should contain things like "linux", "freebsd", "openbsd", "darwin",
>> and "windows".
> 
> Definitely not. The reasoning that applies to Linux doesn't necessarily
> apply to the other systems. My understanding that it definitely does not
> apply to HP-UX, where major version number changes really indicate major
> changes (unlike in Linux).

Actually, with that reasoning we would need to reintroduce the
version for Mac OS, and even go a step further and add the minor
version number as well, since since major changes have happened on Mac OS
with every single minor release for the last couple of years.

IMO, a better approach is to split the information in two parts:

 * sys.platform, which only specifies the platform name on which
   Python was built (uname -s)

 * sys.platform_build_version, which provides the full platform
   version (uname -r; either as string or as tuple or both -
   that would have to be hashed out)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:43:49 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 08:43:49 +0000
Subject: [issue12794] platform: add a major function to get the system
	major	version
In-Reply-To: <1313875184.97.0.739356163073.issue12794@psf.upfronthosting.co.za>
Message-ID: <4E5216C3.5020602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> I'm not sure I understand why platform.release() isn't sufficient
>> for this purpose. Note that some systems return alphanumeric
>> values for platform.release(), e.g. for Windows you get
>> 'NT' or 'XP'.
> 
> It's not easy to get 2 (int) from '2.6.38-8-generic' (str). For Windows, there *is* a major version:
> 
>  * Windows 3.1 : 3
>  * Windows 95/98, NT 4 : 4
>  * Windows XP, 2003 : 5
>  * Vista, Seven : 6
>
> The major version is maybe less revelant for Windows.

For Windows and Mac OS X, the minor version is relevant as well:

Windows 7 has the version number 6.1. For Mac OS X, there are major
changes happening for minor releases, e.g. see the architecture changes
between 10.4, 10.5 and 10.6.

> Anyway...
> 
>> platform.major() will be needed if we remove the major
>> version for all platforms from sys.platform (issue #12795).
> 
> I just closed the issue #12795, and so I don't think that this issue is still needed and so I close it. Reopen it if you still see an use case.

----------
title: platform: add a major function to get the system major version -> platform: add a major function to get the system major	version

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:44:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 08:44:03 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1314002643.95.0.912106773806.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> We could change the title of the ticket :-)

No please, move the discussion to #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #12795 is also close but you can reopen it if you explain why :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:45:33 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 08:45:33 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
Message-ID: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>


New submission from Tennessee Leeuwenburg <tleeuwenburg at gmail.com>:

Hi,

I was writing some coverage tests, and started on a class called MailmanProxy inside of smtpd.py. It imports Mailman, which isn't in the standard library. I've attached a failing test to demonstrate the problem, but I didn't want to delete the section from smtpd.py as a beginner.

Thanks,
-Tennessee

----------
components: Library (Lib)
files: MailmanProxy.diff
keywords: patch
messages: 142701
nosy: barry, ncoghlan, tleeuwenburg
priority: normal
severity: normal
status: open
title: smtpd uses library outside of the standard libraries
Added file: http://bugs.python.org/file22995/MailmanProxy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12816>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:47:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 08:47:24 +0000
Subject: [issue12796] total_ordering goes into infinite recursion when
	NotImplemented is returned
In-Reply-To: <1313872054.41.0.176512047741.issue12796@psf.upfronthosting.co.za>
Message-ID: <1314002844.49.0.464354853362.issue12796@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is a dupe of #10042

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> total_ordering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12796>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:50:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Aug 2011 08:50:07 +0000
Subject: [issue10042] total_ordering
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1314003007.2.0.207214766669.issue10042@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Changed stage and resolution to reflect the fact that none of the existing patches adequately address the problem.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:52:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 08:52:03 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1314003123.45.0.190731553115.issue12795@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Having the major version in sys.platform only for a few selected platforms doesn't seem too consistent for me.

If linux 4 will introduce major changes, will we have to look for the major version of freebsd in sys.platform and for the linux major version elsewhere?

That said, removing the major version for the other platforms might introduce unnecessary breakage, but if it's ever going to happen, I think it's better to do it now for all the platforms and not waiting for the experts to speak and change it in later versions, adding even more inconsistency.

----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:54:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 08:54:41 +0000
Subject: [issue12794] platform: add a major function to get the system
	major	version
In-Reply-To: <4E500A38.8090405@egenix.com>
Message-ID: <4E521945.2070506@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 20/08/2011 21:25, Marc-Andre Lemburg a ?crit :
> I'm not sure I understand why platform.release() isn't sufficient
> for this purpose.

You cannot write platform.release() >= (2, 28)  (Linux >= 2.28) or 
platform.release() >= 7  (FreeBSD 7 or later).

You may use int(platform.release()[0]) but it will fail after the major 
version 10, and I'm not sure that release() always starts with a digit.

> What we could do is add a function that tries to find out the
> true version number of the OS, e.g. for Windows 7 that would
> be (6, 1, 7601) instead of the marketing name '7' returned by
> platform.release().

Yes, it would be more pratical than release() and it would be possible 
to compare it using a tuple, like sys.version_info.

> Still, this won't help with the OS version used for the Python
> build.

I don't care of the OS version used to build. See my patch attached to 
#12795: only the version at runtime is important. The common use case is 
to check if the OS has a feature using its version, so the version at 
runtime.

> When Tarek was working on separating sysconfig from
> distutils, we briefly discussed parsing the Makefile and pyconfig.h
> files into a Python module.

This is now an issue: #9878. But it doesn't help if I need the version 
at runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:57:02 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 08:57:02 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1314003422.81.0.170611517188.issue12795@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Moved the discussion here from issue12326:

>> [Larry Hastings]
>> >> If we're changing "linux2" / "linux3" to just "linux", we should be
>> >> consistent and do it for everybody.  I propose sys.platform under 3.3
>> >> should contain things like "linux", "freebsd", "openbsd", "darwin",
>> >> and "windows".

> [Martin v. L?wis]
> > Definitely not. The reasoning that applies to Linux doesn't necessarily
> > apply to the other systems. My understanding that it definitely does not
> > apply to HP-UX, where major version number changes really indicate major
> > changes (unlike in Linux).

Actually, with that reasoning we would need to reintroduce the
version for Mac OS, and even go a step further and add the minor
version number as well, since since major changes have happened on Mac OS
with every single minor release for the last couple of years.

IMO, a better approach is to split the information in two parts:

 * sys.platform, which only specifies the platform name on which
   Python was built (uname -s)

 * sys.platform_build_version, which provides the full platform
   version (uname -r; either as string or as tuple or both -
   that would have to be hashed out)

It is obvious that the version number in sys.platform often 
doesn't really get used (see Victor's example). In such cases,
having access to just the build platform name is better.
In other cases, where you do need to know the version (e.g.
on Mac OS X), you can then easily get if from the new attribute,
and including the minor and even patch level release version
details (e.g. to determine whether Python was compiled with
a Windows specific service pack in place or not).

----------
nosy: +lemburg
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 10:57:22 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 08:57:22 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1314002643.95.0.912106773806.issue12326@psf.upfronthosting.co.za>
Message-ID: <4E5219EF.5010109@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> We could change the title of the ticket :-)
> 
> No please, move the discussion to #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #12795 is also close but you can reopen it if you explain why :-)

Ok, I moved the discussion there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:01:05 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 09:01:05 +0000
Subject: [issue12794] platform: add a function to get the system	version as
	tuple
In-Reply-To: <4E521945.2070506@haypocalc.com>
Message-ID: <4E521ACE.6000108@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
>> What we could do is add a function that tries to find out the
>> true version number of the OS, e.g. for Windows 7 that would
>> be (6, 1, 7601) instead of the marketing name '7' returned by
>> platform.release().
> 
> Yes, it would be more pratical than release() and it would be possible 
> to compare it using a tuple, like sys.version_info.

Ok, changed the title accordingly.

>> Still, this won't help with the OS version used for the Python
>> build.
> 
> I don't care of the OS version used to build. See my patch attached to 
> #12795: only the version at runtime is important. The common use case is 
> to check if the OS has a feature using its version, so the version at 
> runtime.

Well, it is important to somehow get the build information for
Python, since that tells us which OS features were available
at the time of compilation.

>> When Tarek was working on separating sysconfig from
>> distutils, we briefly discussed parsing the Makefile and pyconfig.h
>> files into a Python module.
> 
> This is now an issue: #9878. But it doesn't help if I need the version 
> at runtime.

True, those two data points are different.

----------
title: platform: add a major function to get the system major	version -> platform: add a function to get the system	version as tuple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:07:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 09:07:43 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1314003123.45.0.190731553115.issue12795@psf.upfronthosting.co.za>
Message-ID: <4E521C56.7060201@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

FreeBSD or OpenBSD release major version frequently, something like one 
per year, or one per two years. FreeBSD and OpenBSD developers knows 
that for years, and Python programs use sys.platform.startswith() for 
these OSes.

For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 
2011: it took 14 years to change the major version. It don't think that 
any program working on Linux was prepared for this change: see #12326 
history to have an idea on the problem. It looks like 
sys.platform=='linux3' breaks most programs testing sys.platform 
(including Python itself because of Lib/plat-linux2/ directory).

If you want the OS name, use platform.system() or os.uname()[0].

If you want the OS version, use platform.release(). If you want the OS 
version as a tuple, hum... see the issue #12794.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:11:28 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 09:11:28 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313991026.57.0.929300839495.issue12808@psf.upfronthosting.co.za>
Message-ID: <4E521D3E.7060200@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Nick Coghlan wrote:
> 
> As a separate, but related point, IncrementalDecoder.getstate() includes an explanation on how to save arbitrary state as an integer, but no such explanation (not even a reference to the IncrementalDecoder version) is present in the IncrementalEncoder.getstate() docs.
> 
> Adding MAL, since I'd like an expert opinion. Is the API less stringent than the docs state, or should BufferedIncrementalEncoder be fixed to always return the state as an integer?
> 
> [1] http://docs.python.org/dev/library/codecs#codecs.IncrementalEncoder.getstate

I'm not sure how that description got into the docs. It must
have been added in the 3.x branch, since the 2.7 version of the
docs doesn't document those method at all.

FWIW: The .getstate() and .setstate() don't restrict the type of data
used for storing the state. The only requirement is that the data
returned by .getstate() can be passed to .setstate() in order to
recreate the internal state used by the codec:

    def getstate(self):
        """
        Return the current state of the encoder.
        """
        return 0

    def setstate(self, state):
        """
        Set the current state of the encoder. state must have been
        returned by getstate().
        """
For practical reasons, the used data should be pickleable.

The interface is very similar to the __getstate__/__setstate__
interface used by pickle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:14:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Aug 2011 09:14:18 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <4E5215FE.3090107@egenix.com>
Message-ID: <4E521DE8.4090808@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I agree that's definitely out of scope of this issue.
> 
> We could change the title of the ticket :-)

Please keep the issue closed... The issue at hand was that Linux 3
is released, and broke several applications. This issue has been
resolved.

For the other platforms, I don't see any issue to be fixed (except
for achieving "foolish consistency"). If something is *actually*
broken, it needs to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:20:16 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 09:20:16 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <4E521C56.7060201@haypocalc.com>
Message-ID: <4E521F4E.4060503@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> FreeBSD or OpenBSD release major version frequently, something like one 
> per year, or one per two years. FreeBSD and OpenBSD developers knows 
> that for years, and Python programs use sys.platform.startswith() for 
> these OSes.
> 
> For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 
> 2011: it took 14 years to change the major version. It don't think that 
> any program working on Linux was prepared for this change: see #12326 
> history to have an idea on the problem. It looks like 
> sys.platform=='linux3' breaks most programs testing sys.platform 
> (including Python itself because of Lib/plat-linux2/ directory).
> 
> If you want the OS name, use platform.system() or os.uname()[0].
> 
> If you want the OS version, use platform.release(). If you want the OS 
> version as a tuple, hum... see the issue #12794.

Victor, you are constantly mixing build time information with
runtime information. Those are two different types of information
and we should regard them as such.

sys.platform refers to build time information, so the platform
module won't help.

The version of the build platform is important to know, but
adding it to sys.platform is not necessarily the right
thing to do, since adding just the major version is often
not enough (see Mac OS X) and can sometimes lead to breakage
due to frequent new releases of OSes (see FreeBSD).

Given that the various OSes use different schemes for versioning
and backwards compatibility, a single string cannot possibly
cover all aspects.

Separating the information into OS name and version is a much
more future proof approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:24:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Aug 2011 09:24:45 +0000
Subject: [issue12794] platform: add a function to get the system	version
	as	tuple
In-Reply-To: <4E521ACE.6000108@egenix.com>
Message-ID: <4E52205B.2010908@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, it is important to somehow get the build information for
> Python, since that tells us which OS features were available
> at the time of compilation.

No, it doesn't (except for a bug that Matthias Klose pointed out).
The OS kernel version should have *zero* impact on the resulting Python
binary. What matters it the C compiler and the version of the C library.
The C library may or may not have features; features of the kernel used
to build Python are completely irrelevant.

(I think you misunderstood an earlier statement of me as
self-contradicting. It was not: The kernel *headers* may have an
impact during autoconf, not the running kernel. For Linux, the
kernel headers are part of the C library, and typically bear no
relationship with the running kernel - i.e. they may be either older
or newer than the running kernel).

Since there is no chance that we get the build environment captured
in a reasonable way (in particular not the version of the C library,
in a cross-platform manner), I strongly recommend to let this aspect
rest.

----------
title: platform: add a function to get the system	version as tuple -> platform: add a function to get the system	version as	tuple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 11:33:24 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 09:33:24 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314005604.67.0.439809818887.issue12768@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The usual procedure for committing to both 3.2 and 3.3 is to apply a patch to 3.2 and then merge it to 3.3 - could you check if the patch also works for 3.2 and if not, generate a patch for 3.2? I will do the merge when committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Mon Aug 22 12:01:53 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 10:01:53 +0000
Subject: [issue12794] platform: add a function to get the system	version
	as	tuple
In-Reply-To: <4E52205B.2010908@v.loewis.de>
Message-ID: <4E52290F.9080408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>> Well, it is important to somehow get the build information for
>> Python, since that tells us which OS features were available
>> at the time of compilation.
> 
> No, it doesn't (except for a bug that Matthias Klose pointed out).
> The OS kernel version should have *zero* impact on the resulting Python
> binary. What matters it the C compiler and the version of the C library.
> The C library may or may not have features; features of the kernel used
> to build Python are completely irrelevant.

We are now discussing the general case, not limited to Linux.

But even for Linux, the header information gets dumped into the
plat-linuxN directory files, and those change over time as well.
The kernel version also has an impact on certain features such
as real time clocks, timers or other kernel subsystems, which
autoconf then picks up at compile time.

Of course, you can check whether those features are available
one by one, but a version check is often a better way to see
whether your application has a chance of running on the Python
build in question.

For other OSes, the build version is much more important due
to the significant changes they make between releases, e.g.
Mac OS X.

> (I think you misunderstood an earlier statement of me as
> self-contradicting. It was not: The kernel *headers* may have an
> impact during autoconf, not the running kernel. For Linux, the
> kernel headers are part of the C library, and typically bear no
> relationship with the running kernel - i.e. they may be either older
> or newer than the running kernel).

I'm not talking about the runtime information. I'm talking
about the compile time build information which is available
via the Makefile and pyconfig.h file normally stored in the Python
installation and which is used by distutils.

The problem with those is that some distros choose to only
include those files in -dev packages and parsing them via
sysconfig just to get a quick look at the platform build
version is really a bit too much processing.

> Since there is no chance that we get the build environment captured
> in a reasonable way (in particular not the version of the C library,
> in a cross-platform manner), I strongly recommend to let this aspect
> rest.

We already do capture the build environment. This doesn't include
the C library version, but we could add that as well, if needed,
in a more direct way.

The platform module provides a way to determine the
lib C version required by the running Python binary on Linux
(and perhaps other OSes as well), but it's slow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 12:12:33 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 10:12:33 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1314007953.35.0.801322994245.issue12808@psf.upfronthosting.co.za>


Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Some more tests, updated initial state of BufferedIncrementalEncoder to be the correct type, updated rst file. Bit tired, hope I got it right!

Thanks for the feedback everyone, helps me to get it done, even if it's more work for you...

----------
Added file: http://bugs.python.org/file22996/codecs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 12:18:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Aug 2011 10:18:28 +0000
Subject: [issue12794] platform: add a function to get the system	version
	as	tuple
In-Reply-To: <4E52290F.9080408@egenix.com>
Message-ID: <4E522CF2.5040006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>> The OS kernel version should have *zero* impact on the resulting Python
>> binary. What matters it the C compiler and the version of the C library.
>> The C library may or may not have features; features of the kernel used
>> to build Python are completely irrelevant.
> 
> We are now discussing the general case, not limited to Linux.

And so was I. Read my statement as applying to the general case.

> But even for Linux, the header information gets dumped into the
> plat-linuxN directory files, 

Not in the build process, though...

> and those change over time as well.

What exactly changes over time? The plat-linuxN directory files?
Only if a developer updates them. For systems where the major
version indicates feature changes, the plat-OSn directory should
never change, since OS won't see any header changes until OSn+1
is released.

> The kernel version also has an impact on certain features such
> as real time clocks, timers or other kernel subsystems, which
> autoconf then picks up at compile time.

Which operating system specifically are you referring to here?
This should not happen.

> Of course, you can check whether those features are available
> one by one, but a version check is often a better way to see
> whether your application has a chance of running on the Python
> build in question.

That's a fragile approach, though. If the feature presence
varies with the OS kernel, you should rather check the version
of the kernel you are running on - it may be that support was
compiled in, but the system it runs on doesn't have that
support.

>> (I think you misunderstood an earlier statement of me as
>> self-contradicting. It was not: The kernel *headers* may have an
>> impact during autoconf, not the running kernel. For Linux, the
>> kernel headers are part of the C library, and typically bear no
>> relationship with the running kernel - i.e. they may be either older
>> or newer than the running kernel).
> 
> I'm not talking about the runtime information. I'm talking
> about the compile time build information which is available
> via the Makefile and pyconfig.h file normally stored in the Python
> installation and which is used by distutils.

And so am I. "running kernel" above refers to the kernel running
on the build system (i.e. what uname(1) gives you in autoconf,
and what currently gets into sys.platform).

> We already do capture the build environment. This doesn't include
> the C library version, but we could add that as well, if needed,
> in a more direct way.

No, we can't - that's impossible to implement in the general
case. Some systems may use static linking, or use a fixed version
number even as the library changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 13:08:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 11:08:07 +0000
Subject: [issue9200] Make str methods work with non-BMP chars on narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314011287.73.0.815547019542.issue9200@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: belopolsky -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 13:13:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Aug 2011 11:13:31 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
Message-ID: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Hello,

in my private repo I've changed memoryview's getbufferproc to be PEP-3118
compliant. test_multiprocessing does the equivalent of the following sequence,
which is not allowed by PEP-3118:


>>> import array, io
>>> a = array.array('i', [1,2,3,4,5])
>>> m = memoryview(a)
>>> m.format
'i'
>>> buf = io.BytesIO(bytearray(5))
>>> buf.readinto(m)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected an object with a writable buffer interface
>>>


The error occurs in Objects/abstract.c:315:

   ((*pb->bf_getbuffer)(obj, &view, PyBUF_WRITABLE) != 0))


Here, PyObject_AsWriteBuffer() requests a simple writable buffer of unsigned
bytes *without format information* from the memoryview. The memoryview's
getbufferproc is required to return an error:

"If format is not explicitly requested then the format must be returned
 as NULL (which means "B", or unsigned bytes)."

But the underlying buffer has format 'i' and not 'B', hence the error.


Antoine, is it correct that io.BytesIO should only be used with bytearray
buffers?

If so, this is a bug in the tests (patch attached).

----------
components: Tests
files: test_multiprocessing_use_bytearray.diff
keywords: needs review, patch
messages: 142718
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing: io.BytesIO() requires bytearray buffers
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22997/test_multiprocessing_use_bytearray.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Mon Aug 22 13:36:26 2011
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 22 Aug 2011 11:36:26 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1314012986.42.0.128381340118.issue11682@psf.upfronthosting.co.za>


Changes by Ryan Kelly <ryan at rfk.id.au>:


----------
nosy: +rfk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Mon Aug 22 13:39:37 2011
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 22 Aug 2011 11:39:37 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314013177.28.0.637658296851.issue11816@psf.upfronthosting.co.za>


Changes by Ryan Kelly <ryan at rfk.id.au>:


----------
nosy: +rfk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Aug 22 13:56:02 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 11:56:02 +0000
Subject: [issue12794] platform: add a function to get the system	version
	as	tuple
In-Reply-To: <4E522CF2.5040006@v.loewis.de>
Message-ID: <4E5243CE.1070907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

[This discussion is really off-topic for this issue, it should either
 be moved to issue12795 or a new ticket]

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
>>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>>> The OS kernel version should have *zero* impact on the resulting Python
>>> binary. What matters it the C compiler and the version of the C library.
>>> The C library may or may not have features; features of the kernel used
>>> to build Python are completely irrelevant.
>>
>> We are now discussing the general case, not limited to Linux.
> 
> And so was I. Read my statement as applying to the general case.
> 
>> But even for Linux, the header information gets dumped into the
>> plat-linuxN directory files, 
> 
> Not in the build process, though...
>
>> and those change over time as well.
> 
> What exactly changes over time? The plat-linuxN directory files?
> Only if a developer updates them. For systems where the major
> version indicates feature changes, the plat-OSn directory should
> never change, since OS won't see any header changes until OSn+1
> is released.

I meant that the OS platform directories change over time,
i.e. new plat-<os><version> directories get created to
hold the updated OS information.

Since Python was build on a specific OS version, it will only
see the APIs available on that OS version. The OS build
version provides a quick way to check whether a certain
set of feature is available or not.

>> The kernel version also has an impact on certain features such
>> as real time clocks, timers or other kernel subsystems, which
>> autoconf then picks up at compile time.
> 
> Which operating system specifically are you referring to here?
> This should not happen.

This is meant to happen. The whole purpose of autoconf/configure is
to try to figure out which features are available on a platform
and those features change with the OS version.

See e.g. these documents on the incremental Linux kernel changes
between 2.2 and 3.0:

http://www.kniggit.net/wwol22.html
http://www.kniggit.net/wwol24.html
http://www.kniggit.net/wwol26.html
http://jpranevich.tripod.com/wwol30/wonderful-world-of-linux-3.0.html

Here's a similar list for FreeBSD:

http://ivoras.net/freebsd/freebsd9.html
http://ivoras.net/freebsd/freebsd8.html
http://ivoras.net/freebsd/freebsd7.html

On Mac OS X the situations is a little different: older Python
binaries simply won't run on newer OS versions at all due to the
architecture changes, so there's nothing much to check.

>> Of course, you can check whether those features are available
>> one by one, but a version check is often a better way to see
>> whether your application has a chance of running on the Python
>> build in question.
> 
> That's a fragile approach, though. If the feature presence
> varies with the OS kernel, you should rather check the version
> of the kernel you are running on - it may be that support was
> compiled in, but the system it runs on doesn't have that
> support.

True, the feature may still not work in the runtime OS environment,
but at least the Python binary knows about the feature set you're
interested in, so you can actively check whether it works or not,
since the APIs will be available.

>>> (I think you misunderstood an earlier statement of me as
>>> self-contradicting. It was not: The kernel *headers* may have an
>>> impact during autoconf, not the running kernel. For Linux, the
>>> kernel headers are part of the C library, and typically bear no
>>> relationship with the running kernel - i.e. they may be either older
>>> or newer than the running kernel).
>>
>> I'm not talking about the runtime information. I'm talking
>> about the compile time build information which is available
>> via the Makefile and pyconfig.h file normally stored in the Python
>> installation and which is used by distutils.
> 
> And so am I. "running kernel" above refers to the kernel running
> on the build system (i.e. what uname(1) gives you in autoconf,
> and what currently gets into sys.platform).

Please don't mix up the build time environment with the
runtime environment. Using "running kernel" to refer to
the build time kernel is a rather confusing way of naming
things when discussing build time vs. runtime.

>> We already do capture the build environment. This doesn't include
>> the C library version, but we could add that as well, if needed,
>> in a more direct way.
> 
> No, we can't - that's impossible to implement in the general
> case. Some systems may use static linking, or use a fixed version
> number even as the library changes.

The platform API libc_ver() actually checks the linker references
in the binary and also allows using a different binary
for the check in case the Python binary is not a suitable
candidate.

It is mainly meant to identify the minimum lib C requirement
for a binary.

Adding the lib C version constants would make this information
more directly accessible: __GLIBC__ and __GLIBC_MINOR__ for
glibc.

Regardless, the issue is about adding a runtime query function
to the platform module, not the build time OS version information
which we currently don't provide in an easily usable way. The latter
is being discussed on issue12795 and issue12326.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 14:13:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 12:13:59 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314015239.36.0.592430578881.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

It turned out that this can't be fixed in 2.7 unless we backport the patch in #5127 (it's in 3.2/3.3 but not in 2.7).

IIUC the macro works fine and joins surrogate pairs to a Py_UCS4 char, but since the Py_UNICODE_IS* macros still expect Py_UCS2 on narrow builds on 2.7, the higher bits gets truncated and the macros return wrong results.

So, for example
    >>> u'\ud800\udc42'.isupper()
    True
because \ud800 + \udc42 = \U000100429  ?  \U000100429 gets truncated to \u0429  ?  \u0429 is the CYRILLIC CAPITAL LETTER SHCHA  ?  .isupper() returns True.

The current behavior is instead broken in another way, because it checks that u'\ud800'.isupper() and u'\udc42'.isupper() separately.

Would it make sense to backport #5127 or should I just give up and leave it broken?

----------
title: Make str methods work with non-BMP chars on narrow builds -> Make the str.is* methods work with non-BMP chars on narrow builds

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 14:35:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Aug 2011 12:35:53 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>
Message-ID: <1314016553.82.0.380569488448.issue12816@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That was a correct decision :)

It certainly shouldn't be simply deleted, since that would break backward compatibility.  Barry, is this something we (ie: you, in this case :) wish to continue to maintain?

If not, we have the options of deprecation-and-removal, or deprecation-in-place (in the latter case we just stick a comment in the file...)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12816>
_______________________________________

From report at bugs.python.org  Mon Aug 22 14:36:21 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 12:36:21 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1314007953.35.0.801322994245.issue12808@psf.upfronthosting.co.za>
Message-ID: <4E524D42.3020304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tennessee Leeuwenburg wrote:
> 
> Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:
> 
> Some more tests, updated initial state of BufferedIncrementalEncoder to be the correct type, updated rst file. Bit tired, hope I got it right!
> 
> Thanks for the feedback everyone, helps me to get it done, even if it's more work for you...

I think you should simply drop this whole part:

"""
The implementation should make sure that ``0`` is the most common state. (States
that are more complicated than integers can be converted into an integer by
marshaling/pickling the state and encoding the bytes of the resulting string
into an integer).
"""

or, better, rephrase it so that it becomes clear that the codec
implementation may use any type of pickleable object to represent
the internal state. The only requirement is that .setstate()
has to be able to read back the state returned by .getstate().

We have codecs in the stdlib that return integers, bytes/string
and even tuples (see the io module and the UTF-16 codec as example),
so the documentation is clearly wrong.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                43 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Mon Aug 22 14:46:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 12:46:42 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1314017202.27.0.799762313335.issue12795@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> sys.platform refers to build time information,
> so the platform module won't help.

When I wrote my patch, I realized that sys.platform is used to get the runtime information, which is wrong. See the tests in Lib/test/test_*.py: they use sys.platform to check features of the running OS (kernel). It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 14:57:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 12:57:53 +0000
Subject: [issue12794] platform: add a function to get the system	version
	as	tuple
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1314017873.63.0.413694579341.issue12794@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The whole purpose of autoconf/configure is
> to try to figure out which features are available on a platform
> and those features change with the OS version.

Hum, not exactly. autoconf checks if a function exists or if a constant exists in the C headers and in the C library. You have to check it or your program (C file) will not compile (missing function/constant).

But it's not enough. The GNU libc provides functions which are only available on some recent Linux kernels. Depending on the running kernel, the function may fail with something like "not implemented error".

See for example the discussion about accept4():
http://bugs.python.org/issue10115

At Python level, you need to know the running kernel version to check if accept4() if available or not. Knowing if the kernel used to compile Python has accept4() or not doesn't help.

(If you use the compiled Python on an older libc (e.g. on another computer), you have another problem, but it's the problem of OS vendors, not of Python.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 15:45:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Aug 2011 13:45:43 +0000
Subject: [issue12818] email.utils.formataddr incorrectly quotes parens inside
	quoted strings
Message-ID: <1314020743.63.0.326215230826.issue12818@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The attached test case fails.

----------
assignee: r.david.murray
files: formataddr_paren_test.patch
keywords: easy, patch
messages: 142725
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.formataddr incorrectly quotes parens inside quoted strings
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22998/formataddr_paren_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12818>
_______________________________________

From report at bugs.python.org  Mon Aug 22 16:00:32 2011
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 22 Aug 2011 14:00:32 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1314021632.09.0.826615669975.issue9253@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/issue9253>
_______________________________________

From report at bugs.python.org  Mon Aug 22 16:23:30 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 22 Aug 2011 14:23:30 +0000
Subject: [issue12794] platform: add a function to get the system version as
	tuple
In-Reply-To: <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Message-ID: <1314023010.72.0.526049764657.issue12794@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: platform: add a function to get the system	version as	tuple -> platform: add a function to get the system version as tuple

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________

From report at bugs.python.org  Mon Aug 22 16:26:23 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 14:26:23 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1314017202.27.0.799762313335.issue12795@psf.upfronthosting.co.za>
Message-ID: <4E52670C.1020002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> sys.platform refers to build time information,
>> so the platform module won't help.
> 
> When I wrote my patch, I realized that sys.platform is used to get the runtime information, which is wrong. See the tests in Lib/test/test_*.py: they use sys.platform to check features of the running OS (kernel). It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd).

Right. FreeBSD doesn't ship prebuilt binaries for packages -
it uses a very elegant "ports" collection, where everything gets
compiled on the target machine:

    http://www.freebsd.org/ports/

So you don't really run into the issue of using a older Python build
on the system, unless you have an application which ships Python
along with the application package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 16:27:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Aug 2011 14:27:25 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1314023245.72.0.107480757983.issue12817@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Of course, there is another interpretation:

[PyBUF_FORMAT]

"The returned buffer must have true format information if this flag is provided. This would be used when the consumer is going to be checking for what 'kind' of data is actually stored. An exporter should always be able to provide this information if requested. If format is not explicitly requested then the format must be returned as NULL (which means "B", or unsigned bytes)"


So, the returned buffer may have false format information ('B' vs. 'i'
in this case) if this flag is not provided.


Do you agree with this? I'll then make it explicit in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Mon Aug 22 16:37:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Aug 2011 14:37:44 +0000
Subject: [issue12818] email.utils.formataddr incorrectly quotes parens inside
	quoted strings
In-Reply-To: <1314020743.63.0.326215230826.issue12818@psf.upfronthosting.co.za>
Message-ID: <1314023864.23.0.314802016691.issue12818@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  The output of formataddr is not actually incorrect, it just overquotes compared to what is required by the RFC.  Attached is a fix, but since this isn't technically an RFC bug, I'm removing 3.2 and 2.7 from versions.

----------
keywords:  -easy
stage:  -> patch review
type:  -> behavior
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file22999/formataddr_paren_quote.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12818>
_______________________________________

From report at bugs.python.org  Mon Aug 22 17:03:59 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Aug 2011 15:03:59 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>
Message-ID: <1314025439.5.0.911657569947.issue12816@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think it should be deprecated and eventually removed.  I don't remember why I put it in this file, and besides Mailman 3 won't use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12816>
_______________________________________

From report at bugs.python.org  Mon Aug 22 18:04:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 16:04:50 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <4E52670C.1020002@egenix.com>
Message-ID: <4E527E18.20902@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd).
>
> Right. FreeBSD doesn't ship prebuilt binaries for packages

FreeBSD does ship prebuild Python packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 18:19:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 16:19:15 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1314029955.36.0.595080875926.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch adds the following 4 public macros to unicodeobjects.h:
  Py_UNICODE_IS_SURROGATE(ch)
  Py_UNICODE_IS_HIGH_SURROGATE(ch)
  Py_UNICODE_IS_LOW_SURROGATE(ch)
  Py_UNICODE_JOIN_SURROGATES(high, low)
and documents them.

Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as #9200.

----------
Added file: http://bugs.python.org/file23000/issue10542b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 22 18:29:25 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 16:29:25 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1314029955.36.0.595080875926.issue10542@psf.upfronthosting.co.za>
Message-ID: <4E5283E2.6020004@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The attached patch adds the following 4 public macros to unicodeobjects.h:
>   Py_UNICODE_IS_SURROGATE(ch)
>   Py_UNICODE_IS_HIGH_SURROGATE(ch)
>   Py_UNICODE_IS_LOW_SURROGATE(ch)
>   Py_UNICODE_JOIN_SURROGATES(high, low)
> and documents them.
> 
> Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as #9200.

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 22 19:04:36 2011
From: report at bugs.python.org (Christian Ziemski)
Date: Mon, 22 Aug 2011 17:04:36 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1314032676.69.0.755544314246.issue12713@psf.upfronthosting.co.za>


Christian Ziemski <czml1 at gmx.de> added the comment:

After some interesting hours of work (learning about tests) I created a new patch, including my original code changes as in the former patch and the new additional tests as well.

----------
Added file: http://bugs.python.org/file23001/abbrev_subcmds_plus_tests_3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Mon Aug 22 19:24:52 2011
From: report at bugs.python.org (Jonathan Niehof)
Date: Mon, 22 Aug 2011 17:24:52 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1314033892.47.0.305928199229.issue9993@psf.upfronthosting.co.za>


Jonathan Niehof <jniehof at lanl.gov> added the comment:

?ric, here's a quick docs-only patch against current default...does this do the job?

----------
Added file: http://bugs.python.org/file23002/shutil_move_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Mon Aug 22 19:31:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 17:31:33 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <E1QvYLU-00044i-0k@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 77171f993bf2 by Ezio Melotti in branch 'default':
#10542: Add 4 macros to work with surrogates: Py_UNICODE_IS_SURROGATE, Py_UNICODE_IS_HIGH_SURROGATE, Py_UNICODE_IS_LOW_SURROGATE, Py_UNICODE_JOIN_SURROGATES.
http://hg.python.org/cpython/rev/77171f993bf2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Mon Aug 22 19:31:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 17:31:33 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <E1QvYLU-00044i-0L@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 06b30c5bcc3d by Ezio Melotti in branch '3.2':
#9200: The str.is* methods now work with strings that contain non-BMP characters even in narrow Unicode builds.
http://hg.python.org/cpython/rev/06b30c5bcc3d

New changeset e3be2941c834 by Ezio Melotti in branch 'default':
#9200: merge with 3.2.
http://hg.python.org/cpython/rev/e3be2941c834

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 19:52:25 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Aug 2011 17:52:25 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <4E527E18.20902@haypocalc.com>
Message-ID: <4E529755.7040300@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>>> It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd).
>>
>> Right. FreeBSD doesn't ship prebuilt binaries for packages
> 
> FreeBSD does ship prebuild Python packages.

The FreeBSD base distribution (which has the binaries
and, AFAIK, the only binaries that ship with FreeBSD) doesn't
include Python. It's in the ports collection, though,
and for those you have the option of installing prebuilt
binaries of the packages via pkg_add.

Still, that's not exactly the FreeBSD way of doing things :)
See the big warning in the pkg_add man page, various discussions
on the net and the pros/cons in the handbook:
http://www.freebsd.org/doc/handbook/ports-overview.html

But in general you are right: if you use system provided Python
packages, chances are that your runtime OS version will be
identical or very close to the build time OS version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 20:24:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 18:24:43 +0000
Subject: [issue12795] Remove the major version from sys.platform
In-Reply-To: <1313857395.98.0.181903928708.issue12795@psf.upfronthosting.co.za>
Message-ID: <1314037483.99.0.701747654091.issue12795@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> But in general you are right: if you use system provided Python
> packages, chances are that your runtime OS version will be
> identical or very close to the build time OS version.

I asked on #freebsd-fr: even with pkg_add, the installed Python is compiled on the same major version than the running major version. So the problem is "hidden" (it doesn't affect) on FreeBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12795>
_______________________________________

From report at bugs.python.org  Mon Aug 22 20:51:40 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 22 Aug 2011 18:51:40 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
Message-ID: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>


New submission from Torsten Becker <torsten.becker at gmail.com>:

I have started an implementation of PEP 393 -- Flexible String Representation [1] on bitbucket [2].  Not all code is ported to use the new API yet, but the interpreter starts with the new unicode representation, all unit tests pass, and some micro benchmarks show potential.  Please see the related wiki page [3] for details of my implementation.

[1]: http://www.python.org/dev/peps/pep-0393/
[2]: https://bitbucket.org/t0rsten/pep-393
[2]: http://wiki.python.org/moin/SummerOfCode/2011/PEP393

----------
components: Unicode
files: pep-393-aug22.diff
keywords: patch
messages: 142741
nosy: torsten.becker
priority: normal
severity: normal
status: open
title: PEP 393 - Flexible Unicode String Representation
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23004/pep-393-aug22.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12819>
_______________________________________

From report at bugs.python.org  Mon Aug 22 20:52:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Aug 2011 18:52:09 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1313760783.84.0.770084926143.issue12409@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7FyA5og2bhMbqLJETwxgtT2MAH4QxVdnRpt+zqsBsBzA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

+1

----------
Added file: http://bugs.python.org/file23005/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________
-------------- next part --------------
+1<br>

From report at bugs.python.org  Mon Aug 22 21:37:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 19:37:39 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>
Message-ID: <1314041859.06.0.244592067256.issue12819@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, haypo, lemburg, loewis
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12819>
_______________________________________

From report at bugs.python.org  Mon Aug 22 21:43:45 2011
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 22 Aug 2011 19:43:45 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1314042225.12.0.803879474771.issue12589@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,
what information do you need to advance on this bug?
Cheers,
Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Mon Aug 22 21:54:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 19:54:33 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>
Message-ID: <1314042873.29.0.384284438766.issue12819@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
hgrepos: +62

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12819>
_______________________________________

From report at bugs.python.org  Mon Aug 22 22:03:24 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Aug 2011 20:03:24 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314043404.41.0.564958597281.issue9200@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This issue and #5127 should not be backported to 2.7: narrow builds don't even accept unichar(0x10000).
Only python 3 can slowly pretend to implement utf-16 features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 22:20:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 20:20:52 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314044452.22.0.555334848278.issue9200@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This issue and #5127 should not be backported to 2.7:
> narrow builds don't even accept unichar(0x10000).

I agee.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 22:46:41 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 20:46:41 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <E1QvbOK-0004HQ-Dt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 75a4941d4d61 by Ezio Melotti in branch '2.7':
#9200: backport tests but run them on wide builds only.
http://hg.python.org/cpython/rev/75a4941d4d61

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 22:52:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 20:52:26 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314046346.59.0.22686146345.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Backporting #5127 is not possible anyway, because it would be necessary to recompile.
I backported only the tests, skipping them on wide builds.

----------
dependencies:  -Py_UNICODE_NEXT and other macros for surrogates
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/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 22:55:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 20:55:18 +0000
Subject: [issue9200] Make the str.is* methods work with non-BMP chars on
	narrow builds
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1314046518.04.0.989161882078.issue9200@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

s/skipping them on wide builds/skipping them on narrow builds/
On wide builds they work fine, on narrow builds they don't work and they can't be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:18:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Aug 2011 21:18:46 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314047926.09.0.285756069566.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I improved UTF16.__getitem__ to handle negative indexes and slices. The later uses the same adjustment as for indexes. An __iter__ method is not needed as str.__iter__ used __getitem__. I will take further discussion of this prototype to python-ideas list.

----------
Added file: http://bugs.python.org/file23006/utf16.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:19:53 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 22 Aug 2011 21:19:53 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314047993.89.0.176786831608.issue12729@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file22900/utf16.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:28:13 2011
From: report at bugs.python.org (Julian Berman)
Date: Mon, 22 Aug 2011 21:28:13 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
	for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1314048493.27.0.873878988141.issue12782@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

>  we explicitly advise against importing too many modules in a single import statement, but importing multiple names from a single location is often a useful thing to do.

Cool. I imagined this had to do with it.

> there may be a grammar ambiguity problem in this case, since (unlike from-import) with statements allow arbitrary subexpressions.

Sorry, can you possibly clarify where the ambiguity might come in?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:28:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 21:28:48 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314048528.38.0.0162333969991.issue12729@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:29:04 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 21:29:04 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <E1Qvc3L-0007aE-2I@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default':
#12191: add shutil.chown() to change user and/or group owner of a given path also specifying their names.
http://hg.python.org/cpython/rev/d1fd0f0f8e68

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:30:01 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 22 Aug 2011 21:30:01 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1314048601.59.0.193593481895.issue12191@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

At last, it's in :) thanks a lot to all the people that helped me in the process!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:33:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 21:33:46 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1314048826.57.0.487434363173.issue12191@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default'

You may add shutil.chmod to the "What's New in Python 3.3?" document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:36:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 21:36:56 +0000
Subject: [issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
In-Reply-To: <1292677994.04.0.897235439769.issue10730@psf.upfronthosting.co.za>
Message-ID: <1314049016.57.0.138865936618.issue10730@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10730>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:38:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 21:38:51 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1314049131.89.0.579907766534.issue12191@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Raymond, are you still taking care of the whatsnew?
Do you want people to update it when they add something new?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:40:53 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 22 Aug 2011 21:40:53 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314049253.01.0.927898946008.issue12409@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Removed file: http://bugs.python.org/file23005/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:43:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Aug 2011 21:43:43 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1314049283.3863.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, is it correct that io.BytesIO should only be used with bytearray
> buffers?

BytesIO does a copy of the original object, it does not touch the
original buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:47:07 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 22 Aug 2011 21:47:07 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314049627.85.0.177237048279.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Can you replace "_2G" with "_4G" in the decorator for that test?

When I do that, it pushes the memory usage for the test up to 16GB, which is
beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4),
that was enough to make it swap heavily (and in the end the test still failed).

As an aside, it turns out the problem with -M being ignored wasn't due to me
being stupid; it seems that -j doesn't pass the memlimit on to subprocesses.
I'll open a separate issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:56:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 21:56:12 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <E1QvcTa-0001OF-UI@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5d317e38da44 by Sandro Tosi in branch 'default':
#12191: fix build failures, explicitly passing group argument when I want to test it
http://hg.python.org/cpython/rev/5d317e38da44

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:57:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 21:57:09 +0000
Subject: [issue12792] Document the "type" field of the tracker in the devguide
In-Reply-To: <1313833836.82.0.3738367738.issue12792@psf.upfronthosting.co.za>
Message-ID: <1314050229.59.0.365554576917.issue12792@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in aa627513fb23.  I also moved the 'behavior' at the beginning of the list.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12792>
_______________________________________

From report at bugs.python.org  Mon Aug 22 23:57:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Aug 2011 21:57:58 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1314049627.85.0.177237048279.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314050139.3863.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Can you replace "_2G" with "_4G" in the decorator for that test?
> 
> When I do that, it pushes the memory usage for the test up to 16GB, which is
> beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4),
> that was enough to make it swap heavily (and in the end the test still failed).

Uh, does it? With 4G it should raise OverflowError, and not try to do
anything else.
Could I ask you to try to take a look? :S

> As an aside, it turns out the problem with -M being ignored wasn't due to me
> being stupid; it seems that -j doesn't pass the memlimit on to subprocesses.
> I'll open a separate issue for this.

Running bigmem tests in parallel doesn't make much sense IMO. You want
to run as many of them as you can, which requires that you allocate all
memory to *one* test process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:03:44 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 22 Aug 2011 22:03:44 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314050624.78.0.544337719651.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> Uh, does it? With 4G it should raise OverflowError, and not try to do
> anything else.
> Could I ask you to try to take a look? :S

Sure; I'll see what I can figure out tomorrow.

> Running bigmem tests in parallel doesn't make much sense IMO. You want
> to run as many of them as you can, which requires that you allocate all
> memory to *one* test process.

Yeah, actually running them in parallel isn't a sensible use. But it bit me
because I was just using "make test EXTRATESTOPTS='-uall -M11G test_pickle'".
It would be nice to have a warning so other people don't get confused by the
same problem. I guess that shouldn't be too hard to arrange.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:05:06 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 22 Aug 2011 22:05:06 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314050706.5.0.808608585953.issue12409@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

@Fred: thanks about it :)

@?ric: I just want to have clear in mind what you mean; my original proposal was to move completely, the whole section "Documenting python" to devguide since it contains building instructions and how's the markup works for python. Is your proposal different and so, as I can read, to just move the building part to devguide and the rest of it be left in python documentation with links to sphinx upstream documentation?

But one aspect I think it needs to be done as a prerequisite to this migration is: standardizing the sphinx/tools versions used to build the doc.

devguide is version-agnostic, so we can talk about (without convoluted sentences) only about one way to build the doc.

This was raised several times, even recently, on python-dev so I'm going to resurrect that thread so we can discuss there the pros/cons and then see from the outcome how we can move forward.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:13:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Aug 2011 22:13:44 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1314051224.17.0.559794390981.issue12326@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I don't know how to update this documentation. Can someone update the 
> doc, or suggest a patch?

This is a strange statement. You changed the implementation, so you should be able to change the documentation accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:18:29 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Aug 2011 22:18:29 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1313651389.0.0.265213391291.issue11715@psf.upfronthosting.co.za>
Message-ID: <20110822181822.762a17cb@resist.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Aug 18, 2011, at 07:09 AM, Nick Coghlan wrote:

>I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my
>netbook and updating to the latest Py3k code, I got a lot of test errors,
>even after a make distclean and ./configure.

Hi Nick.  Would this be Kubuntu 11.04 or some other release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11715>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:18:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 22:18:43 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <1314051523.43.0.28487978806.issue12191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ezio: I think that Raymond is in charge of the 3.3 whatsnew too.  The rules in a comment at the top of the file still apply: there are already around 30 notes to the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:25:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 22:25:40 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1314051940.12.0.843181719905.issue9993@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the doc patch, which looks good.  I have one question: if a relative symlink is copied, should the resulting symlink be relative too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:39:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Aug 2011 22:39:18 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1314052758.32.0.489349132579.issue12326@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Something like:

diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -699,20 +699,21 @@ always available.
    This string contains a platform identifier that can be used to append
    platform-specific components to :data:`sys.path`, for instance.
 
-   For Unix systems, this is the lowercased OS name as returned by ``uname -s``
-   with the first part of the version as returned by ``uname -r`` appended,
-   e.g. ``'sunos5'`` or ``'linux2'``, *at the time when Python was built*.
-   Unless you want to test for a specific system version, it is therefore
-   recommended to use the following idiom::
+   For Unix systems, except on Linux, this is the lowercased OS name as
+   returned by ``uname -s`` with the first part of the version as returned by
+   ``uname -r`` appended, e.g. ``'sunos5'`` or ``'linux2'``, *at the time when
+   Python was built*.  Unless you want to test for a specific system version,
+   it is therefore recommended to use the following idiom::
 
-      if sys.platform.startswith('linux'):
-          # Linux-specific code here...
+      if sys.platform.startswith('freebsd'):
+          # Freebsd-specific code here...
 
    For other systems, the values are:
 
    ================ ===========================
    System           :data:`platform` value
    ================ ===========================
+   Linux            ``'linux2'``
    Windows          ``'win32'``
    Windows/Cygwin   ``'cygwin'``
    Mac OS X         ``'darwin'``

?

I don't think that I need a :versionchanged:`2.7.3`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:39:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 22:39:34 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <E1Qvd9Y-0004By-FU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a1bb07d67a24 by Ezio Melotti in branch 'default':
#6484: refactor a bit the tests.
http://hg.python.org/cpython/rev/a1bb07d67a24

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:41:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 22:41:26 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1314052886.25.0.915684640897.issue12713@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reviewed.  Steven: the patch is complete, pending a few doc editions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:56:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Aug 2011 22:56:59 +0000
Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za>
Message-ID: <1314053819.36.0.0544047352885.issue12326@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think the doc patch should mention that:
 1) it's 'linux2' also on Linux 3;
 2) why it's not 'linux3';
The why can be done in a footnote and explain that Linux 3 doesn't introduce new major features and that changing the string to 'linux3' would have just broken needlessly code that was checking for sys.platform == 'linux2'.
It should probably also mention that in future versions (i.e. 3.3+) this string has been changed to be just 'linux' and that keep checking for sys.platform == 'linux2' is therefore discouraged even after this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12326>
_______________________________________

From report at bugs.python.org  Tue Aug 23 00:59:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 22 Aug 2011 22:59:05 +0000
Subject: [issue12191] Add shutil.chown to allow to use user and group name
	(and not only uid/gid)
In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za>
Message-ID: <E1QvdSR-0005an-SN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f2cb733c9a37 by Sandro Tosi in branch 'default':
#12191: added entry in What's New (+ small editing on shutil section)
http://hg.python.org/cpython/rev/f2cb733c9a37

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12191>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:15:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:15:34 +0000
Subject: [issue9893] Usefulness of the Misc/Vim/ files?
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1314054934.15.0.379753435693.issue9893@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> To download the current release of python.vim, which is an enhanced
> version of the python syntax highlighting script that conforms with
> PEP 8, and is actively maintained by the Vim community.
s/python/Python/

I think the bit about ?enhanced version? could be puzzling.  Either say ?an enhanced version of the python.vim file that used to be included in the Python repository?, or just delete that part (my preference).

> To update your .vimrc configuration file with Python-appropriate
> settings, use the sample file from Misc/Vim/vimrc.
The idea is to delete all of Misc/Vim.

> More comprehensive integration of Vim with Python tools and
> frameworks can be found at:
>
>    http://sontek.net/turning-vim-into-a-modern-python-ide
I?m not sure we want to add links to specific articles; for example, I had to combine tips from many websites/blogs to have an efficient setup.  I suggest our README.vim only points to wim.org pages, and other links can be added to the Vim wikis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:16:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:16:05 +0000
Subject: [issue9893] Removing the Misc/Vim/ files
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1314054965.39.0.623777312199.issue9893@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +None -Demos and Tools
title: Usefulness of the Misc/Vim/ files? -> Removing the Misc/Vim/ files
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:30:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:30:42 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314055842.92.0.789970580184.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> Looks like the patch is not enough:
> That's a 3.2 builder. You only committed Jeremy's fix to default.
*puts on the stupid hat*

> I also tried backporting Jeremy's fix to 2.7, but that doesn't seem to
> have worked; the sdist tests is still failing there.
I?ll commit the tmp-debug patch so that we can get info from the buildbot, unless Jeremy or someone can investigate.

> test_record_extensions still needs attention, though.
I was hoping 49b4b4ba9f93 would be enough :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:31:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:31:17 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314055877.31.0.511002651124.issue12785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Can you test again after removing these two lines:

        # XXX see first if we need to convert at all
        prefix = self.path

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:31:19 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 23:31:19 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1314055879.1.0.815182125445.issue12808@psf.upfronthosting.co.za>


Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Thanks for the review. Here is a patch incorporating the two comments being to move some comments.

----------
Added file: http://bugs.python.org/file23007/codecs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:32:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:32:44 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314055964.23.0.322672089164.issue12785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ahem, I read your message too fast.

> With the patch applied, I still get failures in test_old_record_extensions
> and test_record_basic, so it doesn't seem to work.
These are unrelated, I?m only interested in test_database for this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:33:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:33:50 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1314056030.32.0.0408074947659.issue12721@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> While writing my tests I realized, it would be really useful to make
> write_file() return the path it wrote to.
Sure, please open another 3.3 report for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12721>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:38:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:38:20 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314056300.6.0.0554640165983.issue12409@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My comment was ambiguous, let me rephrase it: I am in favor of moving cpython/Doc/documenting to the devguide.  Then, in the devguide, I would like to remove all the doc that?s just duplicating the upstream Sphinx docs, keeping only links and Python-specific parts.

> But one aspect I think it needs to be done as a prerequisite to this migration is:
> standardizing the sphinx/tools versions used to build the doc.
If this gets rejected, we can move the Documenting tree to the devguide anyway, we?ll just have to add a few paragraphs for 2.7 differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:40:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:40:19 +0000
Subject: [issue12394] packaging: generate scripts from callable (dotted paths)
In-Reply-To: <1308906864.25.0.392964418022.issue12394@psf.upfronthosting.co.za>
Message-ID: <1314056419.15.0.423847132814.issue12394@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23008/7099110c8f14.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12394>
_______________________________________

From report at bugs.python.org  Tue Aug 23 01:40:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:40:36 +0000
Subject: [issue8668] Packaging: add a 'develop' command
In-Reply-To: <1273367946.24.0.0664676682922.issue8668@psf.upfronthosting.co.za>
Message-ID: <1314056436.99.0.810214453202.issue8668@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23009/5359c895f841.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8668>
_______________________________________

From report at bugs.python.org  Tue Aug 23 03:56:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 01:56:44 +0000
Subject: [issue9893] Removing the Misc/Vim/ files
In-Reply-To: <1284827686.39.0.471855984875.issue9893@psf.upfronthosting.co.za>
Message-ID: <1314064604.51.0.526369373531.issue9893@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9893>
_______________________________________

From report at bugs.python.org  Tue Aug 23 03:57:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 01:57:01 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314064621.82.0.745424616642.issue12678@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 04:57:46 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 02:57:46 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314068266.11.0.0634051080813.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: rhettinger -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 05:01:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 03:01:32 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314068492.95.0.463750125324.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening to track buildbot failures (at least on Windows) - at a glance, it looks like the SSL socket wrapper is still adding (and trying to test) the send/receivemsg methods even when they're missing from the socket object on the current platform.

----------
assignee:  -> ncoghlan
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 05:54:19 2011
From: report at bugs.python.org (John Chandler)
Date: Tue, 23 Aug 2011 03:54:19 +0000
Subject: [issue12820] Tests for Lib/xml/dom/minicompat.py
Message-ID: <1314071659.09.0.625804560965.issue12820@psf.upfronthosting.co.za>


New submission from John Chandler <therealmetaljoe at gmail.com>:

The Lib/xml/dom/minicompat.py module doesn't appear to have any test coverage, probably because it's not the largest or most exciting of modules! :-) I therefore attach a patch to add test coverage for the EmptyNodeList and NodeList classes. I can add tests for the defproperty function if this patch proves acceptable.

The patch adds a new file (Lib/test/test_xml_dom_minicompat.py) and modifies one line of an existing file (Lib/test/xmltests.py)

I've used Python 3.3.0a0, courtesy of Brett's devinabox, but should be back-portable to older versions of Python.

----------
components: Tests
files: minicompat_tests.patch
keywords: patch
messages: 142779
nosy: John.Chandler
priority: normal
severity: normal
status: open
title: Tests for Lib/xml/dom/minicompat.py
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23010/minicompat_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12820>
_______________________________________

From report at bugs.python.org  Tue Aug 23 06:21:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 04:21:35 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314073295.87.0.25437792813.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attached patch (ssl_fixes_v1) makes the presence of the sendmsg/recvmsg methods in the ssl module conditional on their being present in the underlying socket module.

However, in doing this, I noticed that these methods will, at best, work during the time between connection and the socket going secure and were not added to the list of methods that the SSL is documented as exposing. Perhaps we should just ditch them entirely?

----------
Added file: http://bugs.python.org/file23011/issue6560_ssl_fixes_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 07:49:58 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 05:49:58 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314078598.94.0.439230471024.issue12785@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> These are unrelated, I?m only interested in test_database for this patch.

I see. I'll re-run the tests this evening, and see whether that failure
crops up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Tue Aug 23 08:02:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 06:02:00 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314079320.38.0.678727123086.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> I?ll commit the tmp-debug patch so that we can get info from the buildbot,
> unless Jeremy or someone can investigate.

If you can wait until this evening (CEST), I'll run the tests with that
patch applied locally. It might be easier to get to the bottom of this if
we co-ordinate via IRC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 08:05:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 06:05:43 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314079543.67.0.781563234315.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m in CEST too (France), but I?m not sure I?ll have Internet access this evening.  Would tomorrow afternoon work for you?  I don?t want you to have to dive in distutils more than you should :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 08:58:08 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 06:58:08 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
Message-ID: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,

test_fcntl failed on OpenBSD 5.0.
It's ok when we add openbsd5 in the tuple of sys.platform (patch attached).

Thanks a lot,

Remi.

----------
files: patch-Lib_test_test_fcntl_py
messages: 142784
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_fcntl failed on OpenBSD 5.x
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23012/patch-Lib_test_test_fcntl_py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:06:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 07:06:34 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <1314083194.42.0.543824583386.issue12821@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Note that it's been fixed in default with the recent sys.platform refactoring:

    26     if (sys.platform.startswith(('netbsd', 'freebsd', 'openbsd', 'bsdos'))
    27         or sys.platform == 'darwin'):
    28         if struct.calcsize('l') == 8:

I'll commit a patch for 2.7 and 3.2.

----------
components: +Tests
nosy: +neologix
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:11:07 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 07:11:07 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <1314083467.44.0.338074579765.issue12821@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Thanks a lot, I prefer to use sys.platform.startswith too.

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:12:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 07:12:55 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1314073295.87.0.25437792813.issue6560@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0DM1Jx+aH9ckJzuGho2G23EiDupbBzJJ_ZokZo_p_K1Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> However, in doing this, I noticed that these methods will, at best, work during the time between connection and the socket going secure and were not added to the list of methods that the SSL is documented as exposing. Perhaps we should just ditch them entirely?

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:24:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Aug 2011 07:24:54 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314084294.59.0.810766975389.issue12409@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1, and as Eric says, we can do it without changing versions of Sphinx used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:43:37 2011
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 23 Aug 2011 07:43:37 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
Message-ID: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
because settimeofday() may break the pthread_cond_timedwait().

Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know
how to write appropriate configure script.
"-lrt" is also needed to use clock_gettime() but I don't know how to add
it to LIBS.

----------
components: None
files: use_monotonic_clock.patch
keywords: patch
messages: 142789
nosy: naoki
priority: normal
severity: normal
status: open
title: NewGIL should use CLOCK_MONOTONIC if possible.
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23013/use_monotonic_clock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:50:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 07:50:13 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314085813.62.0.78022213724.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

higery: Would you have a bit of free time to help use here?

----------
nosy: +higery

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:59:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 07:59:35 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1314086375.7.0.934467276773.issue12822@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 09:59:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 07:59:59 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1314086399.42.0.364077727271.issue12822@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #10278.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:00:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 08:00:05 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1314086405.45.0.239470457835.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #12822.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:01:40 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Aug 2011 08:01:40 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1314055879.1.0.815182125445.issue12808@psf.upfronthosting.co.za>
Message-ID: <4E535E60.3030603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Tennessee Leeuwenburg wrote:
> 
> Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:
> 
> Thanks for the review. Here is a patch incorporating the two comments being to move some comments.

Hmm, the documentation patch doesn't appear to have changed. Did you
upload the right patch ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:02:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 08:02:21 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1314086541.6.0.471943687435.issue12808@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:05:20 2011
From: report at bugs.python.org (Roger Li)
Date: Tue, 23 Aug 2011 08:05:20 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
Message-ID: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>


New submission from Roger Li <wormreg at gmail.com>:

In http://docs.python.org/release/3.1.3/library/ssl.html
You will find a link at the bottom named "Introducing SSL and Certificates using OpenSSL", it's a broken link.

The server may be down or not exist, the only version I can find is http://web.archive.org/web/20090429050651/http://old.pseudonym.org/ssl/wwwj-index.html

Please consider to replace the link to the new one.

----------
assignee: docs at python
components: Documentation
messages: 142794
nosy: docs at python, iworm
priority: normal
severity: normal
status: open
title: Broken link in "SSL wrapper for socket objects" document
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:31:36 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 23 Aug 2011 08:31:36 +0000
Subject: [issue12824] Make the write_file() helper function in test_shutil
	return the file name it wrote to
Message-ID: <1314088296.33.0.827828554648.issue12824@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

test_shutil contains a handy helper function called write_file(filename. contents). If *filename* is a tuple, os.path.join() is used to concatenate it to a path.

To be really useful, the resulting file name should be returned, so the user can work with it.

So instead of:
fn = os.path.join(x,y)
write_file(fn, 'contents')

I'd prefer:
fn = write_file((x,y), 'contents')

I have attached a simple patch that achieves this and also applied the resulting simplification to some of the tests.

----------
components: Tests
files: write_file_returns_filename.diff
keywords: patch
messages: 142795
nosy: eric.araujo, hynek
priority: normal
severity: normal
status: open
title: Make the write_file() helper function in test_shutil return the file name it wrote to
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23014/write_file_returns_filename.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12824>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:32:19 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 23 Aug 2011 08:32:19 +0000
Subject: [issue12721] Chaotic use of helper functions in test_shutil for
	reading and writing files
In-Reply-To: <1312970950.41.0.661603105658.issue12721@psf.upfronthosting.co.za>
Message-ID: <1314088339.26.0.253827743221.issue12721@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Done in Issue12824.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12721>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:49:11 2011
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Aug 2011 08:49:11 +0000
Subject: [issue12825] Missing and incorrect link to a command line option.
Message-ID: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>


New submission from Kyle Simpson <illwhipyou at gmail.com>:

The documentation for the runpy module has a link to the -m command line option. In version 2.7.2 of the docs, the link doesn't exist.

http://docs.python.org/release/2.7/library/runpy.html
http://docs.python.org/release/2.7.2/library/runpy.html

If you run

    touch library/runpy.rst
    make html

then the link is created, but with an anchor of "cmdoption-unittest-discover-m" instead of "cmdoption-m".

http://docs.python.org/release/2.7.2/using/cmdline.html#cmdoption-unittest-discover-m

----------
assignee: docs at python
components: Documentation
messages: 142797
nosy: Kyle.Simpson, docs at python
priority: normal
severity: normal
status: open
title: Missing and incorrect link to a command line option.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12825>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:53:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 08:53:35 +0000
Subject: [issue12825] Missing and incorrect link to a command line option.
In-Reply-To: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>
Message-ID: <1314089615.06.0.296743715924.issue12825@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s weird that the docs under /release/2.7 has the link but not the one under /.

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12825>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:54:48 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 08:54:48 +0000
Subject: [issue12826] module _socket failed to build on OpenBSD
Message-ID: <1314089688.63.0.306061849323.issue12826@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,
I try to build Python 3.3 on OpenBSD, and it failed to build these modules: _socket (so _ssl too).

Errors are:
/home/remi/dev/cpython_test/Modules/socketmodule.c: In function 'sock_recvmsg':
/home/remi/dev/cpython_test/Modules/socketmodule.c:2935: error: storage size of 'iov' isn't known
/home/remi/dev/cpython_test/Modules/socketmodule.c:2935: warning: unused variable 'iov'
/home/remi/dev/cpython_test/Modules/socketmodule.c: In function 'sock_recvmsg_into':
/home/remi/dev/cpython_test/Modules/socketmodule.c:3023: error: invalid application of 'sizeof' to incomplete type 'struct iovec' 
/home/remi/dev/cpython_test/Modules/socketmodule.c:3023: warning: division by zero
/home/remi/dev/cpython_test/Modules/socketmodule.c:3023: error: invalid application of 'sizeof' to incomplete type 'struct iovec' 
/home/remi/dev/cpython_test/Modules/socketmodule.c:3034: error: invalid use of undefined type 'struct iovec'
/home/remi/dev/cpython_test/Modules/socketmodule.c:3034: error: dereferencing pointer to incomplete type
/home/remi/dev/cpython_test/Modules/socketmodule.c:3035: error: invalid use of undefined type 'struct iovec'
/home/remi/dev/cpython_test/Modules/socketmodule.c:3035: error: dereferencing pointer to incomplete type
/home/remi/dev/cpython_test/Modules/socketmodule.c: In function 'sock_sendmsg':
/home/remi/dev/cpython_test/Modules/socketmodule.c:3332: error: invalid application of 'sizeof' to incomplete type 'struct iovec' 
/home/remi/dev/cpython_test/Modules/socketmodule.c:3332: warning: division by zero
/home/remi/dev/cpython_test/Modules/socketmodule.c:3332: error: invalid application of 'sizeof' to incomplete type 'struct iovec' 
/home/remi/dev/cpython_test/Modules/socketmodule.c:3343: error: invalid use of undefined type 'struct iovec'
/home/remi/dev/cpython_test/Modules/socketmodule.c:3343: error: dereferencing pointer to incomplete type
/home/remi/dev/cpython_test/Modules/socketmodule.c:3344: error: invalid use of undefined type 'struct iovec'
/home/remi/dev/cpython_test/Modules/socketmodule.c:3344: error: dereferencing pointer to incomplete type
*** WARNING: renaming "_ssl" since importing it failed: No module named '_socket'

If I add a #include <sys/uio.h>, these 2 modules correcly build.

Attached file are:
-the diff
-the details of errors.

Thanks,
Remi.

----------
files: socketmodule_build_openbsd.diff
keywords: patch
messages: 142799
nosy: rpointel
priority: normal
severity: normal
status: open
title: module _socket failed to build on OpenBSD
versions: Python 3.3
Added file: http://bugs.python.org/file23015/socketmodule_build_openbsd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12826>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:55:31 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 08:55:31 +0000
Subject: [issue12826] module _socket failed to build on OpenBSD
In-Reply-To: <1314089688.63.0.306061849323.issue12826@psf.upfronthosting.co.za>
Message-ID: <1314089731.67.0.239484536437.issue12826@psf.upfronthosting.co.za>


Changes by Remi Pointel <python at xiri.fr>:


Added file: http://bugs.python.org/file23016/socketmodule_build_error_openbsd.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12826>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:57:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 08:57:51 +0000
Subject: [issue12826] module _socket failed to build on OpenBSD
In-Reply-To: <1314089688.63.0.306061849323.issue12826@psf.upfronthosting.co.za>
Message-ID: <E1Qvmnt-0006FB-Tm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b4b84e87dc6b by Victor Stinner in branch 'default':
Close #12826: fix socketmodule.c for OpenBSD, include sys/uio.h
http://hg.python.org/cpython/rev/b4b84e87dc6b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12826>
_______________________________________

From report at bugs.python.org  Tue Aug 23 10:59:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 08:59:04 +0000
Subject: [issue12826] module _socket failed to build on OpenBSD
In-Reply-To: <1314089688.63.0.306061849323.issue12826@psf.upfronthosting.co.za>
Message-ID: <1314089944.49.0.095234007167.issue12826@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's surprising that it works on FreeBSD but not on OpenBSD. Thanks for your patch.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12826>
_______________________________________

From report at bugs.python.org  Tue Aug 23 11:00:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 09:00:51 +0000
Subject: [issue12824] Make the write_file() helper function in test_shutil
	return the file name it wrote to
In-Reply-To: <1314088296.33.0.827828554648.issue12824@psf.upfronthosting.co.za>
Message-ID: <1314090051.48.0.391365474557.issue12824@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, I don?t think the patch makes the test easier to read or maintain.  As I wrote in the commit message for #12721:

> For simple open then read/write calls, I have left the usual idiom
> (with open + read/write), as it is short and readable enough.

In the current tests, sometimes os.path.join is called and the resulting name (e.g. src) is used to write contents and then as argument to a shutil function; I actually prefer that src paths are created right before dst and with similar code.

So I think I?ll reject this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12824>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:30:57 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 11:30:57 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
Message-ID: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,

/usr/tmp is not (used) on OpenBSD.

We have specific patch to do this, but I prefer to have this modification upstream.

2.5: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.5/patches/patch-Lib_tempfile_py
2.7: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Lib_tempfile_py
3.2: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python3/3.2/patches/patch-Lib_tempfile_py

Is it possible to add a specific location to remove /usr/tmp of the dirlist?

Attached file is the patch to do this:
--- Lib/tempfile.py.orig        Thu Aug  4 17:05:24 2011
+++ Lib/tempfile.py     Tue Aug 23 12:55:40 2011
@@ -138,6 +138,8 @@
     # Failing that, try OS-specific locations.
     if _os.name == 'nt':
         dirlist.extend([ r'c:\temp', r'c:\tmp', r'\temp', r'\tmp' ])
+    elif _sys.platform.startswith('openbsd'):
+        dirlist.extend([ '/tmp', '/var/tmp' ])
     else:
         dirlist.extend([ '/tmp', '/var/tmp', '/usr/tmp' ])
, '/var/tmp' ])

Thanks,
Remi.

----------
components: Library (Lib)
files: patch-Lib_tempfile_py
messages: 142803
nosy: rpointel
priority: normal
severity: normal
status: open
title: OS-specific location in Lib/tempfile.py for OpenBSD
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23017/patch-Lib_tempfile_py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:31:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 11:31:39 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1314073295.87.0.25437792813.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314098959.3485.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, in doing this, I noticed that these methods will, at best,
> work during the time between connection and the socket going secure
> and were not added to the list of methods that the SSL is documented
> as exposing. Perhaps we should just ditch them entirely?

Well, apparently the SSLSocket object is meant to be usable in clear
text mode. I'm not sure why it's like that, but your patch looks ok to
me (except that it has a debug print() call).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:34:34 2011
From: report at bugs.python.org (higery)
Date: Tue, 23 Aug 2011 11:34:34 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314099274.93.0.428998909689.issue12678@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>higery: Would you have a bit of free time to help use here?

Certainly yes.

I have run the test_packaging.py, the main error message is about "ValueError: path is on mount 'c:', start on mount 'D:'". One sample is:

ERROR: test_uses (packaging.tests.test_database.TestDistribution)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\add-develop-command\lib\packaging\tests\test_database.py", line 148, in setUp
    os.path.join(distinfo_dir, file)))
  File "D:\add-develop-command\lib\packaging\tests\test_database.py", line 36, in record_pieces
    path = relpath(file, sys.prefix)
  File "D:\add-develop-command\lib\ntpath.py", line 622, in relpath
    raise ValueError(error)
ValueError: path is on mount 'c:', start on mount 'D:'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:47:45 2011
From: report at bugs.python.org (higery)
Date: Tue, 23 Aug 2011 11:47:45 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314100065.15.0.863798126688.issue12678@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

For test_distutils.py, there is not an 'os.link()' function on Windows platform, so all the tests using this function will report error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:50:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 11:50:57 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314100257.74.0.859558829565.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks!  There?s a patch on #12785 that may fix the test_database bug.  Here we try to see the distutils test_sdist problem on 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 13:59:54 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 11:59:54 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314100794.6.0.250931264258.issue12827@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> /usr/tmp is not (used) on OpenBSD.

How is that a problem?
Those are just possible temporary directories to try, so if it doesn't exist, it won't be used (typically ENOENT will be catched when opening a tmpfile).
Also, since it's listed last, that's not a performance problem either.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:02:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 12:02:24 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314100944.62.0.000597414232746.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

That's the part I'm questioning though. I'm not clear why you'd ever do that instead of doing everything on the original socket before invoking ssl.wrap_socket.

What I missed on the original patch before committing it (mea culpa) is that the SSL part is neither documented nor tested properly (the tests only check that it is disallowed on a secured SSLSocket, not that it works on a connected-but-not-secured-yet SSLSocket object).

The absence of proper tests and documentation is the main reason I'm tempted to just revert those parts of the patch that touch the ssl module and its tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:05:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 12:05:47 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314101147.12.0.892013112535.issue12827@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Because it's not exactly a bug, can you only apply the patch to Python 3.3?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:16:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 12:16:18 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1314101778.1.0.501274955394.issue6484@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The buildbots are reporting a test failure on Windows:

======================================================================
FAIL: test_listmailcapfiles (test.test_mailcap.HelperFunctionTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_mailcap.py", line 74, in test_listmailcapfiles
    self.assertEqual(env_mailcaps, mcfiles)
AssertionError: Lists differ: ['/testdir1/.mailcap', '/testd... != ['/testdir1/.mailcap;/testdir2...

First differing element 0:
/testdir1/.mailcap
/testdir1/.mailcap;/testdir2/mailcap

First list contains 1 additional elements.
First extra element 1:
/testdir2/mailcap

- ['/testdir1/.mailcap', '/testdir2/mailcap']
?                     ^^^^

+ ['/testdir1/.mailcap;/testdir2/mailcap']
?                     ^

There's a discrepancy between the test (uses os.pathsep) and the mailcap module (hardcoded to use ':' on all platforms).

I suspect the test is actually right and the module is wrong, but I don't know enough about mailcap to be sure. Anyone else?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:20:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 12:20:46 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314102046.49.0.948085616687.issue6560@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's the part I'm questioning though. I'm not clear why you'd ever do 
> that instead of doing everything on the original socket before invoking 
> ssl.wrap_socket.
> 
> What I missed on the original patch before committing it (mea culpa) is 
> that the SSL part is neither documented nor tested properly (the tests 
> only check that it is disallowed on a secured SSLSocket, not that it
> works on a connected-but-not-secured-yet SSLSocket object).

Bill, do you know?

> The absence of proper tests and documentation is the main reason I'm tempted 
> to just revert those parts of the patch that touch the ssl module and its
> tests.

Then perhaps raise NotImplementedError, so that people know it's deliberate and not an oversight.

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:26:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 12:26:43 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314102403.75.0.427893973007.issue12827@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> can you only apply the patch ...

Hum, I mean can *we* only apply ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:26:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 12:26:57 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <E1Qvq4F-00070H-Qm@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fd10d042b41d by Nick Coghlan in branch 'default':
Remove the SSLSocket versions of sendmsg/recvmsg due to lack of proper tests and documentation in conjunction with lack of any known use cases (see issue #6560 for details)
http://hg.python.org/cpython/rev/fd10d042b41d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:30:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 12:30:18 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314102618.33.0.317621371319.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As you can see, I just pushed a change that removed the new methods from SSLSocket objects. If anyone wants to step up with a valid use case (not already covered by wrap_socket), preferably with a patch to add them back that includes proper tests and documentation changes, please open a new feature request and attach the new patch to that issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:32:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 12:32:45 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314102765.45.0.882984484329.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regarding the 'missing methods' aspect, the SSL docs are already pretty clear that SSLSocket objects don't expose the full socket API:

http://docs.python.org/dev/library/ssl#ssl-sockets

Those docs are actually what really got me started down the path of wondering whether or not these new methods even belong on SSLSocket in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:44:01 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 12:44:01 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1314103441.87.0.609620301805.issue12817@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've come to think that PyBUF_SIMPLE requests were really intended
as a way of casting contiguous buffers with arbitrary formats to
one-dimensional buffers of unsigned bytes. At least that is what Numpy
does. 

Then test_multiprocessing would be correct. I've asked the general
question on the Numpy mailing list:

http://mail.scipy.org/pipermail/numpy-discussion/2011-August/058189.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:47:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 12:47:09 +0000
Subject: [issue12817] test_multiprocessing: io.BytesIO() requires bytearray
	buffers
In-Reply-To: <1314011611.8.0.941911218938.issue12817@psf.upfronthosting.co.za>
Message-ID: <1314103629.27.0.465163596391.issue12817@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please also see issue5231.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12817>
_______________________________________

From report at bugs.python.org  Tue Aug 23 14:59:14 2011
From: report at bugs.python.org (higery)
Date: Tue, 23 Aug 2011 12:59:14 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314104354.86.0.569386539813.issue12678@psf.upfronthosting.co.za>


higery <shoulderhigher at gmail.com> added the comment:

>>Here we try to see the distutils test_sdist problem on 2.7.

So sorry that there is not a developed cpython 2.7 on my pc, and my currently installed Python2.7 has not installed the _msi module, so the running of the tests does not work well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:10:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 13:10:41 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314105041.26.0.783764134984.issue5231@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think this would be useful and I'll try it out in features/pep-3118#memoryview.

Syntax options that I'd prefer:

a = array.array('i', [1,2,3])
m = memoryview(a, 'B')


Or go all the way and make memoryview take any flag:

a = array.array('i', [1,2,3])
m = memoryview(a, getbuf=PyBUF_SIMPLE)


This is what I currently do in _testbuffer.c:


>>> from _testbuffer import *
>>> import array
>>> a = array.array('i', [1,2,3])
>>> nd = ndarray(a, getbuf=PyBUF_SIMPLE)
>>> nd.format
''
>>> nd.len
12
>>> nd.shape
()
>>> nd.strides
()
>>> nd.itemsize # XXX array_getbuf should set this to 1.
4



We would need to fix various getbuffer() methods to adhere to
strict rules that I've posed here:

http://mail.scipy.org/pipermail/numpy-discussion/2011-August/058189.html

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:24:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 13:24:17 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1314105041.26.0.783764134984.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314105717.3485.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Or go all the way and make memoryview take any flag:
> 
> a = array.array('i', [1,2,3])
> m = memoryview(a, getbuf=PyBUF_SIMPLE)

This is good for testing, but Python developers shouldn't have to know
about the low-level flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:27:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 13:27:23 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314106043.46.0.805191596752.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

And the Windows buildbots are now happy (at least with respect to this change, anyway - they're still griping about a few other issues).

I don't know if it's feasible to support these new APIs at the socket module level on Windows, but any patches along those lines should also be placed in a new issue rather than being added to this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:40:51 2011
From: report at bugs.python.org (Gregory Nofi)
Date: Tue, 23 Aug 2011 13:40:51 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1314106851.07.0.83970518301.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

There's a bug for that test failure: #9923. I submitted a patch with it. Committing that should fix the failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:41:38 2011
From: report at bugs.python.org (Jonathan Niehof)
Date: Tue, 23 Aug 2011 13:41:38 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1314106898.72.0.554053448575.issue9993@psf.upfronthosting.co.za>


Jonathan Niehof <jniehof at lanl.gov> added the comment:

?ric: I think copying a relative symlink should also be relative, and that's the behaviour of this patch. That was the use case that tripped me up with the original behaviour of shutil.move: a relative symlink which was dangling in its original location, but not once moved. (This was, believe it or not, intentional design....)

This is also the behaviour when src and dst are on the same filesystem. Basically my intention was to remove the distinction between "same filesystem" and "different filesystem."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:43:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 13:43:14 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1314106994.7.0.0438719929457.issue9993@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:50:24 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Aug 2011 13:50:24 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314107424.2.0.842583574842.issue11816@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Nick, I still want to work on this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:51:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 13:51:58 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1314105717.3485.24.camel@localhost.localdomain>
Message-ID: <20110823134915.GA15186@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> > Or go all the way and make memoryview take any flag:
> > 
> > a = array.array('i', [1,2,3])
> > m = memoryview(a, getbuf=PyBUF_SIMPLE)
> 
> This is good for testing, but Python developers shouldn't have to know
> about the low-level flags.

Hmm, indeed. How about:

1) memoryview(a, format='B')

Shadows a builtin function; annoying syntax highlighting in current Vim.

2) memoryview(a, fmt='B')

I'm fully expecting a comment about 'strpbrk' again, but I like it. :)

Also, we've to see about speed implications. My current version of memoryview
(not pushed yet to the public repo) also solves #10227, but is pretty sensitive
even to small changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:53:01 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 13:53:01 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1314107581.64.0.989907251026.issue6484@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, cheers - closing this one again.

/me wanders off to meta-tracker to ask for a list of "dependency of" and "superseder of" issues in the issue header...

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6484>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:56:34 2011
From: report at bugs.python.org (Eugene Toder)
Date: Tue, 23 Aug 2011 13:56:34 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314107794.42.0.65909770471.issue11816@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


----------
nosy:  -eltoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 15:58:43 2011
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Aug 2011 13:58:43 +0000
Subject: [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1314107923.1.0.781541881598.issue12602@psf.upfronthosting.co.za>


Changes by Kyle Simpson <illwhipyou at gmail.com>:


----------
nosy: +Kyle.Simpson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12602>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:01:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 14:01:41 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1314108101.93.0.0768423507568.issue9923@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:02:27 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 14:02:27 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1314108147.17.0.608725479965.issue9923@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage: test needed -> patch review
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:06:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 14:06:34 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <20110823134915.GA15186@sleipnir.bytereef.org>
Message-ID: <1314108254.3485.27.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hmm, indeed. How about:
> 
> 1) memoryview(a, format='B')
> 
> Shadows a builtin function; annoying syntax highlighting in current Vim.
> 
> 2) memoryview(a, fmt='B')
> 
> I'm fully expecting a comment about 'strpbrk' again, but I like it. :)

I really prefer "format", it's the natural word to use there.
I don't think this the only place where we shadow a builtin function.
There are probably variables named "dict" in many places.

> Also, we've to see about speed implications. My current version of memoryview
> (not pushed yet to the public repo) also solves #10227, but is pretty sensitive
> even to small changes.

Well, solving #10227 would be nice, but I don't think it's critical
either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:07:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 14:07:38 +0000
Subject: [issue9993] shutil.move fails on symlink source
In-Reply-To: <1285801392.69.0.814963089991.issue9993@psf.upfronthosting.co.za>
Message-ID: <1314108458.96.0.00118358909446.issue9993@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9993>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:28:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 14:28:07 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314109687.25.0.557105750734.issue5231@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Good, I'll use 'format'. I was mainly worried about the shadowing
issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:29:41 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 14:29:41 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314109781.63.0.00995416384816.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file23018/7cead6bf5832.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:33:47 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 14:33:47 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314110027.2.0.135545488194.issue11816@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file23018/7cead6bf5832.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 16:50:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 14:50:49 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1314111049.77.0.25326987454.issue11816@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The diff generator didn't work - I've uploaded the current patch manually to make it easier to review than it is in my bitbucket repo.

I just noticed there's a missing element in the docs patch at the moment - to make testing easier, Ryan added a 'file' argument to the various print-based dis functions so the output can easily be captured in a StringIO object. The docs updates don't currently reflect that, they only cover the OpInfo and get_opinfo additions (along with a clarification of the dis module's slightly odd use of the term 'free').

Aside from that, the core concept of the patch is pretty simple:
- add dis.OpInfo and dis.get_opinfo() to make it easier to walk the bytecode programmatically
- eliminate a lot of the logic duplication inside dis by refactoring more of the operations to internally rely on get_opinfo()
- add a new test.bytecode_helper.BytecodeTestCase with some convenient assertions for checking code generation
- update test_peepholer to be independent of the disassembly formatting details
- add tests for the new features to test_dis (but keep the old detailed formatting tests)

One potential criticism is the complexity of the 'expected output' for the new OpInfoTestCase, but it seemed worth it to vet the way the new code handles several cases. The programmatic nature makes the opcode sequences much easier to read and maintain than the corresponding formatted output tests would have been.

These new tests also cover an error that the previous incarnation of the test suite missed completely (I had a bug at one point where I had incorrectly omitted the second half of the list of cell names - there was no test to check that the disassembler handled references to such names correctly)

----------
assignee: ncoghlan -> rhettinger
Added file: http://bugs.python.org/file23019/issue11816_get_opinfo_branch_20110824.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:15:02 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 15:15:02 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314112502.07.0.747366773276.issue5231@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Rethinking a bit: Casting to arbitrary formats might go a bit far.

Currently, the combination (format=NULL, shape=NULL) can serve as
a warning "This buffer has been cast to unsigned bytes".

If we allow casts from bytes to int32, we'll have (format="i", shape=x)
and consumers of that buffer have no indication that the original
exporter had a different format.

If you know what you are doing, fine. On the other hand following
the buffer paths in #12817 quickly turned into a very complex
maze of getbuffer requests.


So, an option would be to try out the cast to bytes first and
disallow other casts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:22:39 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Aug 2011 15:22:39 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314112959.68.0.451269179975.issue5231@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Casting to a flat 1-D array of bytes is reasonable (it's essentially saying 'look, just give me the raw data, it's on my own head if I stuff up the formatting').

However, requiring an explicit two-step process for any other casting (i.e. take a 1-D view, then a shaped view of that flat 1-D view) also sounds reasonable.

So I agree with Victor that 1-D bytes -> any shape/format and any shape/format -> 1-D bytes should be allowed, but I think we should hold off on allowing arbitrary transformations in a single step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:31:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 15:31:53 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1314112959.68.0.451269179975.issue5231@psf.upfronthosting.co.za>
Message-ID: <1314113374.3485.31.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, requiring an explicit two-step process for any other casting
> (i.e. take a 1-D view, then a shaped view of that flat 1-D view) also
> sounds reasonable.
> 
> So I agree with Victor that 1-D bytes -> any shape/format and any
> shape/format -> 1-D bytes should be allowed, but I think we should
> hold off on allowing arbitrary transformations in a single step.

Converting to 1-D bytes is my main motivation for this feature request,
so I'm fine with such a limitation.

The point is to be able to do in Python what we can do in C, take an
arbitrary buffer and handle it as pure bytes (for I/O or cryptography
purposes, for example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:45:57 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 15:45:57 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314102403.75.0.427893973007.issue12827@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2vVPKng6372Bin8WKKSnwFeFHjr5oHe05AHaEw-A-_3Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Because it's not exactly a bug, can you only apply the patch to Python 3.3?

Well, we could, but:
- it doesn't fix a bug
- it doesn't bring any obvious benefit (performance, security, etc)
- it introduces an OS-specific case for no reason

I'm open to changing my mind though, maybe I'm missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:52:26 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 15:52:26 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314114746.15.0.979927827856.issue12827@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

I was reporting this because I thought it was better to include this upstream.
However, I understand if you don't want to include this specific case.

We can keep this patch in our tree, I understand your position.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:53:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 15:53:59 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1314114839.93.0.926760327931.issue11657@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For 3.3, it may be relevant that send/recvmsg are now available via 
> the socket API (see #6560)

I think sendfds/recvfds helper methods could be added to the socket type, so that programmers don't have to get the incantations right by themselves (note the plural, because passing several fds at once is more generic :-)).

That said, +1 on committing Petri's patch. Will do it in a hour or two if noone is faster.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:56:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 15:56:28 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1314114988.99.0.425365696701.issue11657@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 17:59:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 15:59:03 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314115143.69.0.609430771216.issue12827@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> We can keep this patch in our tree, I understand your position.

I could be missing something, but why do you have this patch in the first place?
If it turns out to be useful, then it's of course better to include it upstream, I just don't see what this patch is supposed to solve/improve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 18:00:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 16:00:37 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1314115237.36.0.735236787194.issue11657@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now that I think of it, it would be nice to add some simple tests for recvfd and sendfd in test_multiprocessing.
(also, when os.dup2() is available, you can easily generate an arbitrary big file descriptor)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 18:06:13 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 16:06:13 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314115573.52.0.322081475973.issue12827@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

> I could be missing something, but why do you have this patch in the first place?

I'm recently working on porting Python for OpenBSD, and this patch exists since python2.5 (since 4 years in our tree). So I don't have all responses, but I think this issue could be closed/rejected, and it seems that this patch could be safely removed from our port tree.

Thanks for all information.

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 18:09:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 16:09:37 +0000
Subject: [issue12827] OS-specific location in Lib/tempfile.py for OpenBSD
In-Reply-To: <1314099057.22.0.804371186211.issue12827@psf.upfronthosting.co.za>
Message-ID: <1314115777.45.0.749352028156.issue12827@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> it seems that this patch could be safely removed from our port tree.

Alright, I'm closing then.

> Thanks for all information.

And thanks for your help and bug reports concerning OpenBSD-specific issues!

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12827>
_______________________________________

From report at bugs.python.org  Tue Aug 23 18:27:04 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Aug 2011 16:27:04 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1314112959.68.0.451269179975.issue5231@psf.upfronthosting.co.za>
Message-ID: <20110823162420.GA16027@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Nick Coghlan <report at bugs.python.org> wrote:
> So I agree with Victor that 1-D bytes -> any shape/format and any
> shape/format -> 1-D bytes should be allowed, but I think we should
> hold off on allowing arbitrary transformations in a single step.

1-D bytes -> any shape/format would work if everyone agrees on the
Numpy mailing list post that I linked to in an earlier message.

[Summary: PyBUF_SIMPLE may downcast any C-contiguous array to unsigned bytes.]

Otherwise a PyBUF_SIMPLE getbuffer call to the newly shaped memoryview
would be required to fail, and these calls are almost certain to occur
somewhere, e.g. in PyObject_AsWriteBuffer().

But then memoryview would also need a 'shape' parameter:

m = memoryview(x, format='L', shape=[3, 4])

In that case, making it a method might indeed be more clear to underline
that something extraordinary is going on:

m = memoryview(x).cast(format='L', shape=[3, 4])

It also takes away a potential speed loss for regular uses.

1-D bytes would then be defined as 'b', 'B' and 'c', I presume? Being able
to cast to 'c' would also solve certain memoryview index assignment problems
that arise if we opt for strict typing as the struct module does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:41:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 17:41:07 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <E1QvuyG-0003UR-DB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f1f1d9f4b14e by Charles-Fran?ois Natali in branch '2.7':
Issue #12821: Fix test_fcntl failures on OpenBSD 5.
http://hg.python.org/cpython/rev/f1f1d9f4b14e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:44:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 17:44:10 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <1314121450.43.0.789924387623.issue12821@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:45:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 17:45:38 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <E1Qvv2f-00042V-8m@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9157a9e77740 by Charles-Fran?ois Natali in branch '3.2':
Issue #12821: Fix test_fcntl failures on OpenBSD 5.
http://hg.python.org/cpython/rev/9157a9e77740

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:46:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 17:46:57 +0000
Subject: [issue12828] xml.dom.minicompat is not documented
Message-ID: <1314121617.5.0.895410943337.issue12828@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

There's no documentation for xml.dom.minicompat - it's a public module and it should have (even a brief) doc.

----------
assignee: docs at python
components: Documentation
messages: 142845
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
status: open
title: xml.dom.minicompat is not documented
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12828>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:51:26 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 17:51:26 +0000
Subject: [issue12821] test_fcntl failed on OpenBSD 5.x
In-Reply-To: <1314082688.53.0.490286129891.issue12821@psf.upfronthosting.co.za>
Message-ID: <1314121886.45.0.15792220723.issue12821@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Committed to 3.2 and 2.7.
R?mi, thanks for the report.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12821>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:52:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 17:52:08 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <E1Qvv8x-0004Zz-EG@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5b2f357989bb by Antoine Pitrou in branch '3.2':
Issue #11657: Fix sending file descriptors over 255 over a multiprocessing Pipe.
http://hg.python.org/cpython/rev/5b2f357989bb

New changeset 4e7a4e098f38 by Antoine Pitrou in branch 'default':
Issue #11657: Fix sending file descriptors over 255 over a multiprocessing Pipe.
http://hg.python.org/cpython/rev/4e7a4e098f38

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:54:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 17:54:27 +0000
Subject: [issue12828] xml.dom.minicompat is not documented
In-Reply-To: <1314121617.5.0.895410943337.issue12828@psf.upfronthosting.co.za>
Message-ID: <1314122067.78.0.678833264538.issue12828@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure at all this module should be treated as anything but an internal detail.  The docstring of xml.dom only mentions two submodules.

----------
components: +XML
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12828>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:56:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 17:56:43 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <E1QvvDO-00054n-2C@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d4d9a3e71897 by Antoine Pitrou in branch '2.7':
Issue #11657: Fix sending file descriptors over 255 over a multiprocessing Pipe.
http://hg.python.org/cpython/rev/d4d9a3e71897

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:57:09 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 17:57:09 +0000
Subject: [issue12828] xml.dom.minicompat is not documented
In-Reply-To: <1314122067.78.0.678833264538.issue12828@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj1NmCG6UEqGzKmAaXy=obRN_KzK4twxg063Yo7gYHM90g@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I?m not sure at all this module should be treated as anything but an internal detail. ?The docstring of xml.dom only mentions two submodules.

If it's an implementation detail, then probably a small reference in
the module docstring could be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12828>
_______________________________________

From report at bugs.python.org  Tue Aug 23 19:57:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 17:57:34 +0000
Subject: [issue11657] multiprocessing_{send,recv}fd fail with fds > 256
In-Reply-To: <1300928246.81.0.834552598366.issue11657@psf.upfronthosting.co.za>
Message-ID: <1314122254.89.0.535640997809.issue11657@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed a patch with some tests. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11657>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:00:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 18:00:42 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314122442.83.0.94123043738.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would add it in test_exceptions, since errno mapping is ultimately used by exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:05:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 18:05:10 +0000
Subject: [issue12823] Broken link in "SSL wrapper for socket objects" document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <1314122710.26.0.416155489511.issue12823@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would simply remove the link, or point it to a similar document

----------
keywords: +easy
nosy: +pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12823>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:35:50 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 18:35:50 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314124550.61.0.389151959862.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I was playing around with pickling large Unicode strings in an interactive
interpreter, and it seems that you have to have at least 4G chars (not bytes)
to trigger the OverflowError. Consider the following snippet of code:

    out = dumps(data)
    del data
    result = loads(out)
    assert isinstance(result, str)
    assert len(result) == _1G 

With data as (b"a" * _4G) the result is as expected:

    Traceback (most recent call last):
      File "pickle-bigmem-test.py", line 5, in <module>
        out = dumps(data)
    OverflowError: cannot serialize a string larger than 4GB

But with (b"a" * _2G), I get this:

    Traceback (most recent call last):
      File "pickle-bigmem-test.py", line 7, in <module>
        result = loads(out)
    _pickle.UnpicklingError: BINUNICODE pickle has negative byte count

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:41:59 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 18:41:59 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314124919.19.0.636348794036.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Some more info: the first few bytes of the output for the _2G case are this:

    b'\x80\x03X\x00\x00\x00\x80aaaaaa'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:54:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 18:54:29 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1314125669.3.0.498159085449.issue12822@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
> because settimeofday() may break the pthread_cond_timedwait().

Indeed.
A couple remarks:
- regular locks and conditions variables exposed by the threading module suffer from the same problem
- POSIX semaphores are also affected, but you can't select an alternative clock source
- actually, CLOCK_MONOTONIC is affected by NTP adjustements: while it's guaranteed not to go backward, its rate can be affected

Did you really encounter this problem, or is this just a theoretical concern?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 20:58:47 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 18:58:47 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314125927.39.0.314009835487.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

> With data as (b"a" * _4G) the result is as expected:
>
>     Traceback (most recent call last):
>       File "pickle-bigmem-test.py", line 5, in <module>
>         out = dumps(data)
>     OverflowError: cannot serialize a string larger than 4GB
>
> But with (b"a" * _2G), I get this:
>
>     Traceback (most recent call last):
>       File "pickle-bigmem-test.py", line 7, in <module>
>         result = loads(out)
>     _pickle.UnpicklingError: BINUNICODE pickle has negative byte count

Correction: these should be ("a" * _4G) and ("a" * _2G).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Tue Aug 23 21:03:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 19:03:42 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1314126222.99.0.693231288196.issue12822@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 21:15:13 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Aug 2011 19:15:13 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314126222.99.0.693231288196.issue12822@psf.upfronthosting.co.za>
Message-ID: <4E53FC3B.3080509@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.

I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether the deployment
platform supports the clock, plus a fallback solution in case
it is not available.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Tue Aug 23 21:42:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 19:42:05 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QvwrM-0005j7-8y@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa27461759f2 by ?ric Araujo in branch 'default':
Try to fix packaging tests using build_ext on Windows (#12678)
http://hg.python.org/cpython/rev/aa27461759f2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 22:09:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 20:09:35 +0000
Subject: [issue12820] Tests for Lib/xml/dom/minicompat.py
In-Reply-To: <1314071659.09.0.625804560965.issue12820@psf.upfronthosting.co.za>
Message-ID: <1314130175.2.0.482299592923.issue12820@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, I just left a very light review on rietveld (the 'review' link below). I think in the next run you can add the tests for defproperty. Thanks for working on code coverage!

----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12820>
_______________________________________

From report at bugs.python.org  Tue Aug 23 22:38:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 20:38:11 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314131891.7.0.740662726855.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nadeem, please try this patch.

----------
Added file: http://bugs.python.org/file23020/windows-build_ext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 23:16:37 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 21:16:37 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314134197.95.0.795833419682.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure :/

It does change the traceback for the exception, though.

Before:

    ======================================================================
    ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 647, in link
        self.spawn([self.linker] + ld_args)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 909, in spawn
        spawn(cmd, dry_run=self.dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 34, in spawn
        _spawn_nt(cmd, search_path, dry_run=dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 75, in _spawn_nt
        "command '%s' failed with exit status %d" % (cmd[0], rc))
    distutils.errors.DistutilsExecError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\tests\test_install.py", line 207, in test_record_extensions
        buildcmd.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 345, in run
        self.build_extensions()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 454, in build_extensions
        self.build_extension(ext)
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 541, in build_extension
        target_lang=language)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 717, in link_shared_object
        extra_preargs, extra_postargs, build_temp, target_lang)
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 649, in link
        raise LinkError(msg)
    distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

After:

    ======================================================================
    ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 647, in link
        self.spawn([self.linker] + ld_args)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 909, in spawn
        spawn(cmd, dry_run=self.dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 34, in spawn
        _spawn_nt(cmd, search_path, dry_run=dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 75, in _spawn_nt
        "command '%s' failed with exit status %d" % (cmd[0], rc))
    distutils.errors.DistutilsExecError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\tests\test_install.py", line 207, in test_record_extensions
        buildcmd.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 345, in run
        self.build_extensions()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 454, in build_extensions
        self.build_extension(ext)
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 541, in build_extension
        target_lang=language)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 717, in link_shared_object
        extra_preargs, extra_postargs, build_temp, target_lang)
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 649, in link
        raise LinkError(msg)
    distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 23:20:26 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 21:20:26 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314134426.58.0.0580435787812.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure :/

It does change the traceback for the exception, though.

Before:

    ======================================================================
    ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 647, in link
        self.spawn([self.linker] + ld_args)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 909, in spawn
        spawn(cmd, dry_run=self.dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 34, in spawn
        _spawn_nt(cmd, search_path, dry_run=dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 75, in _spawn_nt
        "command '%s' failed with exit status %d" % (cmd[0], rc))
    distutils.errors.DistutilsExecError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\tests\test_install.py", line 207, in test_record_extensions
        buildcmd.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 345, in run
        self.build_extensions()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 454, in build_extensions
        self.build_extension(ext)
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 541, in build_extension
        target_lang=language)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 717, in link_shared_object
        extra_preargs, extra_postargs, build_temp, target_lang)
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 649, in link
        raise LinkError(msg)
    distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104


After:

    ======================================================================
    ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 647, in link
        self.spawn([self.linker] + ld_args)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 909, in spawn
        spawn(cmd, dry_run=self.dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 34, in spawn
        _spawn_nt(cmd, search_path, dry_run=dry_run)
      File "C:\Code\cpython\python-3.2\lib\distutils\spawn.py", line 75, in _spawn_nt
        "command '%s' failed with exit status %d" % (cmd[0], rc))
    distutils.errors.DistutilsExecError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "C:\Code\cpython\python-3.2\lib\distutils\tests\test_install.py", line 221, in test_record_extensions
        cmd.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\install.py", line 569, in run
        self.run_command('build')
      File "C:\Code\cpython\python-3.2\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Code\cpython\python-3.2\lib\distutils\dist.py", line 936, in run_command
        cmd_obj.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build.py", line 126, in run
        self.run_command(cmd_name)
      File "C:\Code\cpython\python-3.2\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Code\cpython\python-3.2\lib\distutils\dist.py", line 936, in run_command
        cmd_obj.run()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 345, in run
        self.build_extensions()
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 454, in build_extensions
        self.build_extension(ext)
      File "C:\Code\cpython\python-3.2\lib\distutils\command\build_ext.py", line 541, in build_extension
        target_lang=language)
      File "C:\Code\cpython\python-3.2\lib\distutils\ccompiler.py", line 717, in link_shared_object
        extra_preargs, extra_postargs, build_temp, target_lang)
      File "C:\Code\cpython\python-3.2\lib\distutils\msvc9compiler.py", line 649, in link
        raise LinkError(msg)
    distutils.errors.LinkError: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 23:21:27 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Aug 2011 21:21:27 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314134487.72.0.256922367404.issue12678@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
Removed message: http://bugs.python.org/msg142863

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Tue Aug 23 23:28:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 23 Aug 2011 21:28:14 +0000
Subject: [issue12810] Remove check for negative unsigned value in
	socketmodule.c
In-Reply-To: <1313990634.15.0.242436957417.issue12810@psf.upfronthosting.co.za>
Message-ID: <1314134894.83.0.531948689884.issue12810@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks.
I'll commit this patch tomorrow.
I noticed you didn't indicate your full name: do you mind being listed in Misc/ACKS?

----------
components: +Extension Modules
keywords: +easy
nosy: +neologix
stage:  -> commit review
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12810>
_______________________________________

From report at bugs.python.org  Tue Aug 23 23:56:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 21:56:21 +0000
Subject: [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1314136581.49.0.559188560858.issue12798@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here attached a new patch incorporating Ezio & Eric suggestions.

----------
Added file: http://bugs.python.org/file23021/mimetypes_doc_update-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12798>
_______________________________________

From report at bugs.python.org  Wed Aug 24 00:26:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Aug 2011 22:26:49 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>
Message-ID: <1314138409.35.0.736875818449.issue12819@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

utf8_fast.patch: fast path for pure ASCII string in the UTF-8 decoder.

----------
Added file: http://bugs.python.org/file23022/utf8_fast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12819>
_______________________________________

From report at bugs.python.org  Wed Aug 24 00:45:04 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 23 Aug 2011 22:45:04 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
Message-ID: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>


New submission from David H. Gutteridge <dhgutteridge at sympatico.ca>:

I stumbled across this bug because of a misunderstanding I had about how the pyexpat module works.  I'd inferred that a given instance could be reused to parse multiple files, which is apparently not supported.  (There's already a documentation bug open on this, see http://bugs.python.org/issue6676 -- a few other people made the same mistaken assumption as me.)  I found that given the right input, a segmentation fault occurs when one attempts to reuse the parser instance on more than one file.

The sample test case I've attached derives from what I'm using pyexpat for, which involves the parsing of Microsoft Office Open XML Excel files.  I found that the specific content in the initial file can influence whether the submission of subsequent files triggers a segmentation fault.

I'm reporting this against Python 2.7.2 on Mac OS X 10.6.8; it also occurs with Python 2.6.1 that's bundled with the OS.  I can also duplicate it on the development branch of NetBSD (my other development platform), specifically 5.99.47/amd64 with Python 2.6.7.

----------
components: Library (Lib)
files: pyexpat_crash_isolation_osx.py
messages: 142868
nosy: dhgutteridge
priority: normal
severity: normal
status: open
title: pyexpat segmentation fault caused by multiple calls to Parse()
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file23023/pyexpat_crash_isolation_osx.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:06:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 23:06:47 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314140807.79.0.696003392418.issue12678@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file23024/windows-build_ext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:06:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 23:06:56 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314140816.29.0.712258775723.issue12678@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file23020/windows-build_ext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:10:59 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 23 Aug 2011 23:10:59 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314141059.38.0.772119472379.issue12829@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

I believe this may be an OS-specific bug somehow, albeit one that affects multiple OSes.  I cannot duplicate the crash on NetBSD 5.1_STABLE/i386 with Python 2.6.7, or on OpenSuSE 11.3 with Python 2.6.5.  (It's interesting that it doesn't crash on the older branch of NetBSD, but it does on the newer, both with the same version of Python and underlying Expat...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:15:54 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 23 Aug 2011 23:15:54 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314141354.92.0.452503246959.issue12829@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

Here's the (non-debug) trace under OS X:

Process:         Python [4604]
Path:            /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  bash [1461]

Date/Time:       2011-08-23 19:14:48.148 -0400
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          366485 sec
Crashes Since Last Report:           29
Per-App Crashes Since Last Report:   29
Anonymous UUID:                      5504B203-8C24-427A-B74C-EDBD3EF8DB51

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000100569000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   pyexpat.so                    	0x000000010050e439 normal_updatePosition + 57
1   pyexpat.so                    	0x00000001004f9314 PyExpat_XML_GetCurrentLineNumber + 84
2   pyexpat.so                    	0x00000001004f374e set_error + 62
3   pyexpat.so                    	0x00000001004f4588 xmlparse_Parse + 200
4   org.python.python             	0x00000001000c102d PyEval_EvalFrameEx + 22397
5   org.python.python             	0x00000001000c2d29 PyEval_EvalCodeEx + 2137
6   org.python.python             	0x00000001000c0b6a PyEval_EvalFrameEx + 21178
7   org.python.python             	0x00000001000c2d29 PyEval_EvalCodeEx + 2137
8   org.python.python             	0x00000001000c2e46 PyEval_EvalCode + 54
9   org.python.python             	0x00000001000e7b6e PyRun_FileExFlags + 174
10  org.python.python             	0x00000001000e7e29 PyRun_SimpleFileExFlags + 489
11  org.python.python             	0x00000001000fe77c Py_Main + 2940
12  org.python.python             	0x0000000100000f14 0x100000000 + 3860

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00000000fffffffb  rbx: 0x000000010037bbc0  rcx: 0x000000010037bec8  rdx: 0x00000001008cd39f
  rdi: 0x00000001005256c0  rsi: 0x0000000100569000  rbp: 0x00007fff5fbfedf0  rsp: 0x00007fff5fbfedf0
   r8: 0x000000010050e458   r9: 0x00000001008caa00  r10: 0x0000000000000800  r11: 0x0000000100542dda
  r12: 0x0000000000000000  r13: 0x00000001003037e0  r14: 0x0000000000000009  r15: 0x00000001004aca70
  rip: 0x000000010050e439  rfl: 0x0000000000010293  cr2: 0x0000000100569000

Binary Images:
       0x100000000 -        0x100000fff +org.python.python 2.7.2 (2.7.2) <639E72E4-F205-C034-8E34-E59DE9C46369> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x10016cfef +org.python.python 2.7.2, (c) 2004-2011 Python Software Foundation. (2.7.2) <49D18B1A-C92D-E32E-A7C1-086D0B14BD76> /Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1002ec000 -        0x1002efff7 +strop.so ??? (???) <F7857283-F427-7CF7-9B0D-7619AA0A82F1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
       0x1004f0000 -        0x100524fe7 +pyexpat.so ??? (???) <E5FD4237-8D59-8B8E-E229-19601A03F18E> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/pyexpat.so
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <B536F2F1-9DF1-3B6C-1C2C-9075EA219A06> /usr/lib/dyld
    0x7fff8005d000 -     0x7fff801d4fe7  com.apple.CoreFoundation 6.6.5 (550.43) <31A1C118-AD96-0A11-8BDF-BD55B9940EDC> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff822f0000 -     0x7fff824b1fef  libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
    0x7fff82781000 -     0x7fff82792ff7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <FB5EE53A-0534-0FFA-B2ED-486609433717> /usr/lib/libz.1.dylib
    0x7fff8376d000 -     0x7fff837eafef  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
    0x7fff85577000 -     0x7fff8557bff7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff86259000 -     0x7fff86417fff  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <4274FC73-A257-3A56-4293-5968F3428854> /usr/lib/libicucore.A.dylib
    0x7fff86526000 -     0x7fff865dcff7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib
    0x7fff8739a000 -     0x7fff873e6fff  libauto.dylib ??? (???) <F7221B46-DC4F-3153-CE61-7F52C8C293CF> /usr/lib/libauto.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:58:05 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Aug 2011 23:58:05 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314143885.77.0.859427256908.issue12729@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Added file: http://bugs.python.org/file23025/utf16.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Wed Aug 24 01:59:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Aug 2011 23:59:23 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1Qw0sL-0000VQ-Uk@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 20944ea49392 by ?ric Araujo in branch '3.2':
Fix distutils tests on Windows (#12678).
http://hg.python.org/cpython/rev/20944ea49392

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Wed Aug 24 02:15:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 00:15:36 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1Qw183-0001gs-20@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1696e2789d91 by ?ric Araujo in branch 'default':
Fix test_packaging on Windows (#12678).
http://hg.python.org/cpython/rev/1696e2789d91

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Wed Aug 24 02:18:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Aug 2011 00:18:26 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1314145106.29.0.394320659363.issue12678@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If the 3.x buildbots are smiling tomorrow, I will backport to 2.7 and distutils2.

----------
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Wed Aug 24 02:26:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 00:26:07 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314145567.59.0.969715769023.issue6560@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The OS X buildbots show some failures:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%203.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Aug 24 03:05:23 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 24 Aug 2011 01:05:23 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314147923.15.0.0747321257852.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached unit test.

----------
Added file: http://bugs.python.org/file23026/issue12802_unittest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Wed Aug 24 04:16:25 2011
From: report at bugs.python.org (Joel)
Date: Wed, 24 Aug 2011 02:16:25 +0000
Subject: [issue12810] Remove check for negative unsigned value in
	socketmodule.c
In-Reply-To: <1313990634.15.0.242436957417.issue12810@psf.upfronthosting.co.za>
Message-ID: <1314152185.33.0.894018437474.issue12810@psf.upfronthosting.co.za>


Joel <joel at jms.id.au> added the comment:

My full name is Joel Stanley, and yep, please add me to Misc/ACKS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12810>
_______________________________________

From report at bugs.python.org  Wed Aug 24 08:34:37 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 24 Aug 2011 06:34:37 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1314167677.34.0.0158644760067.issue10408@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


----------
nosy: +jcon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Wed Aug 24 09:04:54 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 24 Aug 2011 07:04:54 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314169494.19.0.645054311323.issue12729@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

In msg142098  Ezio said:
> Keep in mind that we should be able to access and use lone surrogates too, therefore:
> s = '\ud800'  # should be valid
> len(s)  # should this raise an error? (or return 0.5 ;)?

I say:
For streams and data types in which lone surrogates are permitted, a lone surrogate should be treated as and counted as a character (codepoint).

For streams and data types in which lone surrogates are not permitted, the assigned should be invalid, and raise an error; len would then never see it, and has no quandary.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Wed Aug 24 09:12:45 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 24 Aug 2011 07:12:45 +0000
Subject: [issue6584] gzip module has no custom exception
In-Reply-To: <1248675050.27.0.747048824781.issue6584@psf.upfronthosting.co.za>
Message-ID: <1314169965.2.0.6871266013.issue6584@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6584>
_______________________________________

From report at bugs.python.org  Wed Aug 24 09:13:11 2011
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 24 Aug 2011 07:13:11 +0000
Subject: [issue6669] TarFile.getmembers fails at struct.unpack: unpack
	requires a string argument of length 4
In-Reply-To: <1249679476.65.0.0604043126333.issue6669@psf.upfronthosting.co.za>
Message-ID: <1314169991.54.0.382641127764.issue6669@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6669>
_______________________________________

From report at bugs.python.org  Wed Aug 24 11:50:50 2011
From: report at bugs.python.org (trevor)
Date: Wed, 24 Aug 2011 09:50:50 +0000
Subject: [issue12388] cannot specify recursive extra_files in packaging
	setup.cfg
In-Reply-To: <1308778662.94.0.774064324312.issue12388@psf.upfronthosting.co.za>
Message-ID: <1314179450.65.0.81013337267.issue12388@psf.upfronthosting.co.za>


Changes by trevor <trevor at well.com>:


----------
nosy: +trevor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12388>
_______________________________________

From report at bugs.python.org  Wed Aug 24 11:53:59 2011
From: report at bugs.python.org (trevor)
Date: Wed, 24 Aug 2011 09:53:59 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314179639.3.0.468747231442.issue12386@psf.upfronthosting.co.za>


Changes by trevor <trevor at well.com>:


----------
nosy: +trevor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Wed Aug 24 12:18:09 2011
From: report at bugs.python.org (trevor)
Date: Wed, 24 Aug 2011 10:18:09 +0000
Subject: [issue12830] --install-data doesn't effect resources destination
Message-ID: <1314181089.71.0.14845741215.issue12830@psf.upfronthosting.co.za>


New submission from trevor <trevor at well.com>:

attempting to point the relative destination with "--install-data" does not seem to have an effect. the specified directory is created, but resources are still installed relative to the present working directory.

setup.cfg:

[files]
resources =
    externalfiles/tobemoved.txt = support


% pysetup3 run install_dist --install-data /tmp/example


/tmp/example is created with no files, ./support/tobemoved.txt is created

----------
assignee: tarek
components: Distutils2
messages: 142878
nosy: alexis, eric.araujo, tarek, trevor
priority: normal
severity: normal
status: open
title: --install-data doesn't effect resources destination
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12830>
_______________________________________

From report at bugs.python.org  Wed Aug 24 14:31:04 2011
From: report at bugs.python.org (=?utf-8?q?Alexander_R=C3=B8dseth?=)
Date: Wed, 24 Aug 2011 12:31:04 +0000
Subject: [issue12831] 2to3 and integer division
Message-ID: <1314189064.26.0.312921037596.issue12831@psf.upfronthosting.co.za>


New submission from Alexander R?dseth <rodseth at gmail.com>:

Hi,

2to3 is a great tool, but I think I found one case it doesn't catch, which is this change:

-        half = self.maxstars / 2
+        half = self.maxstars // 2

"/ 2" is an integer division, so it should be "// 3" in Python 3.

Thanks.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 142879
nosy: alexander256
priority: normal
severity: normal
status: open
title: 2to3 and integer division
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12831>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:10:03 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Wed, 24 Aug 2011 13:10:03 +0000
Subject: [issue1666318] shutil.copytree doesn't give control over directory
	permissions
Message-ID: <1314191403.14.0.843944699819.issue1666318@psf.upfronthosting.co.za>


Changes by Ugra D?niel <daniel.ugra at gmail.com>:


----------
nosy: +daniel.ugra

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1666318>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:18:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:18:14 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
Message-ID: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

A common problem encountered when using python3 is writing non-ascii to stdout.  This will work fine if stdout is a terminal and the terminal encoding handles the characters, but will fail if stdout is later redirected to a pipe.  The docs for sys.stdout and for print should contain or point to an explanation of why, and how to solve the problem (ie: how to set the encoding for sys.stdout/sys.stderr).

Note that IMO it makes more sense for sys.stdout to default to the LOCALE encoding, but that should be a separate issue.

----------
assignee: docs at python
components: Documentation
messages: 142880
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: The documentation for the print function should explain/point to how to control the sys.stdout encoding
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:21:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:21:21 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314192081.17.0.0838750904308.issue12832@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor says it defaults to LOCALE in 3.3.  The documentation should still be expanded to mention this even in 3.3, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:32:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 13:32:13 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1314192733.43.0.923458063158.issue12807@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+    if (len == 0) {
+        if (PyByteArray_CheckExact(self)) {
+            Py_INCREF(self);
+            return (PyObject *)self;
+        }
+        return PyByteArray_FromStringAndSize(NULL, 0);
+    }

This looks like a dubious micro-optimization. If len == 0,
all loops will exit early anyway (same for similar snippets in bytesobject.c and unicodeobject.c).

+    if (i == 0 && j == len && PyByteArray_CheckExact(self)) {
+        Py_INCREF(self);
+        return (PyObject *)self;
+    }

bytearray objects are mutable, so you can't return the same object without breaking expected semantics. e.g.:

>>> a = bytearray()
>>> b = a.strip()
>>> b.append(49)
>>> a
bytearray(b'')
>>> b
bytearray(b'1')

> diff -r b5ccdf7c032a Python/bltinmodule.c
> Binary file Python/bltinmodule.c has changed

Uh, what's this? bltinmodule.c shouldn't be considered a binary file.
It probably means you added a NUL byte in it by mistake.

> Looking at just how similar these 3 implementations are I feel that we 
> could also unify/generalize them into one generic helper implementation 
> and leave the object marshaling up to the type specific methods.

You could put it in Objects/stringlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:36:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:36:16 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314192976.85.0.94018944527.issue12832@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, this was actually fixed in 3.2, so it is only 2.7 where there is the different (and long standing) problem of output of unicode to a pipe.

So, the doc issue boils down to mentioning how the encoding for stdout/stderr is derived (LOCALE, overridden by PYTHONIOENCODING if set, as far as I can tell).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Wed Aug 24 15:46:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 13:46:48 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314193608.13.0.918183535502.issue12803@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch. This is a generally useful functionality and the patch looks mostly good.
I have a couple comments:

- in _pwinfo_set(), you need to decref password_bytes when you're finished
- you check the password size in _password_callback() but not in _pwinfo_set(), is it expected? is the size limit only meaningful with a callback rather than a predefined password?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Wed Aug 24 16:26:47 2011
From: report at bugs.python.org (Conley Owens)
Date: Wed, 24 Aug 2011 14:26:47 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1314196007.64.0.418497715641.issue3244@psf.upfronthosting.co.za>


Changes by Conley Owens <xcco3x at gmail.com>:


----------
nosy: +cco3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Wed Aug 24 18:43:48 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 16:43:48 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1314145567.59.0.969715769023.issue6560@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3FYKi8Pfy5HP-6mrcTCjg6SpwFxJ2-P+R7QF-TKYtTig@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch skipping testFDPassSeparate and
testFDPassSeparateMinSpace on OS X < 10.5, due to known kernel bugs
(see http://developer.apple.com/library/mac/#qa/qa1541/_index.html).
For InterruptedSendTimeoutTest and testInterruptedSendmsgTimeout, it
also looks like a kernel bug.
There could be another explanation, though: if, for some reason, other
threads are running at that time, the signal might be delivered to
another thread, and our main thread remains stuck on sendto/sendmsg
once the socket buffer is full. I'm however not sure why this would
only affect OS X (since FreeBSD behaves in the same way when it comes
to signals, contrarily to Linux). Also, I'm not sure why this would
not affect recv/recvmsg.

----------
Added file: http://bugs.python.org/file23027/pass_fds_osx.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________
-------------- next part --------------
diff -r 1696e2789d91 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Wed Aug 24 02:15:25 2011 +0200
+++ b/Lib/test/test_socket.py	Wed Aug 24 18:36:22 2011 +0200
@@ -2090,7 +2090,9 @@
     def _testFDPassCMSG_LEN(self):
         self.createAndSendFDs(1)
 
+    # Passing multiple FDs at once isn't reliable on OS X < 10.5.
     @requireAttrs(socket, "CMSG_SPACE")
+    @support.requires_mac_ver(10, 5)
     def testFDPassSeparate(self):
         # Pass two FDs in two separate arrays.  Arrays may be combined
         # into a single control message by the OS.
@@ -2111,6 +2113,7 @@
             len(MSG))
 
     @requireAttrs(socket, "CMSG_SPACE")
+    @support.requires_mac_ver(10, 5)
     def testFDPassSeparateMinSpace(self):
         # Pass two FDs in two separate arrays, receiving them into the
         # minimum space for two arrays.

From report at bugs.python.org  Wed Aug 24 18:51:52 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 16:51:52 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1314204712.46.0.313440758426.issue12333@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

More occurrences:
http://www.python.org/dev/buildbot/all/builders/sparc solaris10 gcc 3.x/builds/3555/steps/test/logs/stdio

"""
======================================================================
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/distutils/tests/support.py", line 63, in tearDown
    shutil.rmtree(d, os.name in ('nt', 'cygwin'))
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 280, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 289, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/home2/buildbot/slave/3.x.loewis-sun/build/Lib/shutil.py", line 287, in rmtree
    os.rmdir(path)
OSError: [Errno 22] Invalid argument: '/tmp/tmp2horib/foo'
"""

----------
nosy: +neologix
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Wed Aug 24 19:00:12 2011
From: report at bugs.python.org (Idan Kamara)
Date: Wed, 24 Aug 2011 17:00:12 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
Message-ID: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>


New submission from Idan Kamara <idankk86 at gmail.com>:

import sys, readline

sys.stdout.write('foo ')
raw_input()

When trying the above on Debian, 2.6.6 using gnome-terminal, typing a character then hitting backspace deletes "foo " as well.

I'm not sure if this is a bug or the expected behavior when writing to stdout directly rather than passing the string to raw_input() (for my particular use case that's not an option though).

One possible workaround seems to be to delete the trailing space from write() and move it to raw_input:

sys.stdout.write('foo')
raw_input(' ')

Then backspace seems to work properly. This has something to do with readline because when it's not imported, it also works as expected (but other things break obviously).

----------
components: Library (Lib)
messages: 142887
nosy: idank
priority: normal
severity: normal
status: open
title: raw_input misbehaves when readline is imported
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Wed Aug 24 19:00:39 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 24 Aug 2011 17:00:39 +0000
Subject: [issue12824] Make the write_file() helper function in test_shutil
	return the file name it wrote to
In-Reply-To: <1314088296.33.0.827828554648.issue12824@psf.upfronthosting.co.za>
Message-ID: <1314205239.6.0.396757989969.issue12824@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

ok. it would have saved some LOC for me, but it's nothing essential of course.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12824>
_______________________________________

From report at bugs.python.org  Wed Aug 24 19:29:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Aug 2011 17:29:47 +0000
Subject: [issue12830] --install-data doesn't effect resources destination
In-Reply-To: <1314181089.71.0.14845741215.issue12830@psf.upfronthosting.co.za>
Message-ID: <1314206987.85.0.495131828821.issue12830@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is one of the things that were left under-specified when the resources subsystem was introduced by adding working code instead of a PEP.  I think that --install-data is obsolete now, and that there should be another way to override specific sysconfig variables or paths (which are used to install data files/resources) from the command line and config files, to replace --install-data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12830>
_______________________________________

From report at bugs.python.org  Wed Aug 24 19:51:24 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 24 Aug 2011 17:51:24 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1314208284.35.0.398128360862.issue12715@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

What started as a 2 lines fix, grew to a patch of ~400 lines. :)

It's mostly tests though:

Lib/shutil.py           |  102 +++++++++++++++++++++++++++++----------
Lib/test/test_shutil.py |  220 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Misc/ACKS               |    1 +
3 files changed, 297 insertions(+), 26 deletions(-)

I've AFAIS implemented the desired behavior and hope for feedback/bug reports.

It's tested on Linux & FreeBSD 8.2 and applies cleanly against default/tip.

Please let me know if I've done something stupid.

----------
hgrepos: +63

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Aug 24 19:52:03 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 24 Aug 2011 17:52:03 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1314208323.33.0.692949301887.issue12715@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23028/e126ceae5ba9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:06:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 18:06:38 +0000
Subject: [issue12810] Remove check for negative unsigned value in
	socketmodule.c
In-Reply-To: <1313990634.15.0.242436957417.issue12810@psf.upfronthosting.co.za>
Message-ID: <E1QwHqT-0006PU-HB@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4736e172fa61 by Charles-Fran?ois Natali in branch 'default':
Issue12810: Remove check for negative unsigned value in socketmodule.c. Patch
http://hg.python.org/cpython/rev/4736e172fa61

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12810>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:07:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 18:07:31 +0000
Subject: [issue12810] Remove check for negative unsigned value in
	socketmodule.c
In-Reply-To: <1313990634.15.0.242436957417.issue12810@psf.upfronthosting.co.za>
Message-ID: <1314209251.46.0.924668608369.issue12810@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
Thanks Joel!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12810>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:14:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 18:14:22 +0000
Subject: [issue12715] Add symlink support to shutil functions
In-Reply-To: <1312891582.66.0.716309232823.issue12715@psf.upfronthosting.co.za>
Message-ID: <1314209662.05.0.330226100788.issue12715@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12715>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:35:03 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Wed, 24 Aug 2011 18:35:03 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314210903.85.0.515967562127.issue12803@psf.upfronthosting.co.za>


Adam Simpkins <adam at adamsimpkins.net> added the comment:

Good catch.  Here's an updated patch to fix the missing decref in
_pwinfo_set()

The length check in _password_callback() applies to both callback
functions and predefined strings.  The C API always uses a callback,
so _password_callback() is used even when the python caller has passed
in a string.  We can't check the length in _pwinfo_set() since it depends
on the buffer length argument that openssl will pass to
_password_callback().

----------
Added file: http://bugs.python.org/file23029/ssl-password.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:45:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Aug 2011 18:45:05 +0000
Subject: [issue12834] memoryview.tobytes() incorrect for non-contiguous arrays
Message-ID: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

memoryview.tobytes() converts a non-contiguous array to
a contiguous representation. This result is not right:


>>> from numpy import *
>>> x = array([1,2,3,4,5], dtype="B")
>>> y = x[::-1]
>>> y
array([5, 4, 3, 2, 1], dtype=uint8)
>>> m = memoryview(y)
>>> m.tobytes()
'\x04\x03\x02\x01\x05'
>>>

----------
assignee: skrah
components: Interpreter Core
messages: 142894
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview.tobytes() incorrect for non-contiguous arrays
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Aug 24 20:46:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 18:46:54 +0000
Subject: [issue12834] memoryview.tobytes() incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1314211614.4.0.474562959359.issue12834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's rather funky. What should the right result be?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:01:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 19:01:16 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1314212476.19.0.283892102159.issue4106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't seem to reproduce this under 3.3. Should it be closed?

----------
nosy: +pitrou
resolution:  -> out of date
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:04:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:04:33 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <CAH_1eM3FYKi8Pfy5HP-6mrcTCjg6SpwFxJ2-P+R7QF-TKYtTig@mail.gmail.com>
Message-ID: <CAH_1eM0QbJwAoG131A0N6SqD6EprycB=G=6aCYXDWe0aPfSwYg@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

As noted by Antoine, the OS X 10.5 buildbots are also failing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:07:36 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 24 Aug 2011 19:07:36 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1314212476.19.0.283892102159.issue4106@psf.upfronthosting.co.za>
Message-ID: <CACQrdOmx2CTH7qno6LJUwFdLAZ4KDwRBwZDazyEcF2-TBJxmjw@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Wed, Aug 24, 2011 at 3:01 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> I can't seem to reproduce this under 3.3. Should it be closed?

I don't think so; it's still applicable to 2.x, and a fix should go
into 2.7 ideally. http://bugs.python.org/issue9207 is the source of
the issue AFAIR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:09:59 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Aug 2011 19:09:59 +0000
Subject: [issue12834] memoryview.tobytes() incorrect for non-contiguous arrays
In-Reply-To: <1314211614.4.0.474562959359.issue12834@psf.upfronthosting.co.za>
Message-ID: <20110824190713.GA23660@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> That's rather funky. What should the right result be?

Basically [5, 4, 3, 2, 1] as bytes:

'\x05\x04\x03\x02\x01'

Looks like an off-by-one error.

I was a bit surprised that tobytes() automatically converts anything
to a C-contiguous array. The result can be completely disconnected
from the raw memory.

[The bug also exists for forward strides.]

array([1, 3, 5], dtype=uint64)
>>> m = memoryview(y)
>>> m.tobytes()
'\x03\x00\x00\x00\x00\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:11:34 2011
From: report at bugs.python.org (David Watson)
Date: Wed, 24 Aug 2011 19:11:34 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
Message-ID: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

Changeset fd10d042b41d removed the wrappers on ssl.SSLSocket for 
the new socket.send/recvmsg() methods (since I forgot to check 
for the existence of the underlying methods - see issue #6560), 
but this leaves SSLSocket with send/recvmsg() methods inherited 
from the underlying socket type; thus SSLSocket.sendmsg() will 
insert the given data into the stream without encrypting it (or 
wrapping it in SSL in any way). 
 
This immediately screws up the SSL connection, resulting in 
receive errors at both ends ("SSL3_GET_RECORD:wrong version 
number" and the like), but the data is clearly visible in a 
packet capture, so it's too late if it was actually something 
secret. 
 
Correspondingly, recvmsg() and recvmsg_into() return the 
encrypted data, and screw up the connection by removing it from 
the SSL stream. 
 
Of course, these methods don't make sense over SSL anyway, but if 
the programmer naively assumes they do, then ideally they should 
not expose any secret information. 
 
Attaching a patch implementing Antoine Pitrou's suggestion that 
the methods should simply raise NotImplementedError.  I don't 
know if these versions should also be added only if present on 
the underlying socket - they're Not Implemented either way :-)

----------
components: Library (Lib)
files: ssl_sendrecvmsg_notimplemented.diff
keywords: patch
messages: 142900
nosy: baikie
priority: normal
severity: normal
status: open
title: Missing SSLSocket.sendmsg() wrapper allows programs to send unencrypted data by mistake
versions: Python 3.3
Added file: http://bugs.python.org/file23030/ssl_sendrecvmsg_notimplemented.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:13:28 2011
From: report at bugs.python.org (David Watson)
Date: Wed, 24 Aug 2011 19:13:28 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1314102618.33.0.317621371319.issue6560@psf.upfronthosting.co.za>
Message-ID: <20110824191325.GA5015@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Tue 23 Aug 2011, Nick Coghlan wrote:
> As you can see, I just pushed a change that removed the new
> methods from SSLSocket objects. If anyone wants to step up with
> a valid use case (not already covered by wrap_socket),
> preferably with a patch to add them back that includes proper
> tests and documentation changes, please open a new feature
> request and attach the new patch to that issue.

Hi, sorry about the trouble caused by the broken tests, but
SSLSocket should at least override sendmsg() to stop misguided
programs sending data in the clear:

http://bugs.python.org/issue12835

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:14:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:14:09 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1314213249.56.0.324395036003.issue12786@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +pitrou, rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:16:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 19:16:29 +0000
Subject: [issue12834] memoryview.tobytes() incorrect for non-contiguous arrays
In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za>
Message-ID: <1314213389.58.0.948042985112.issue12834@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12834>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:18:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:18:34 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313683595.52.0.268324784337.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM25opowouQ1e-X8p2epg4vXiRZQpwA6jHzU-7HS-V4uzw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

So, what was the conclusion of the discussion brought up on python-dev?
I had a feeling some core devs were opposed to this (I'm personally -0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:22:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 19:22:55 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1314213775.42.0.326789213536.issue4106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, 2.7 seems still affected.

----------
resolution: out of date -> 
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:40:36 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:40:36 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1310627755.45.0.158603921709.issue12287@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1ui3bwpr2L8Q2CLtXkw_rP+uAAiaf4ycAhEqUnUzDK=Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

So, what should I do with is_selectable.diff?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:45:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:45:40 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1314215140.71.0.754692680317.issue12656@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:47:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:47:24 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314215244.53.0.685990789893.issue5113@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Wed Aug 24 21:53:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:53:55 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1314215635.61.0.140502772251.issue6419@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

R?mi, can you reproduce this problem?
Could you test the patch attached?
(It's maybe already part of OPenBSD's tree, in which case it would certainly be nice to include it).

----------
nosy: +rpointel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:02:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:02:20 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1314216140.44.0.83646994083.issue12287@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> So, what should I do with is_selectable.diff?

It looks ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:02:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:02:48 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1314216168.26.0.0491510025585.issue4106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I think the reason this doesn't appear in 3.2/3.3 is the fix for issue1856. In 2.x (and 3.1) daemon threads can continue executing after the interpreter's internal structures have started being destroyed.

The least intrusive solution is to always join the helper thread before shutting down the interpreter. Patch attached.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file23031/mpqshutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:10:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:10:06 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1314216606.84.0.291640288403.issue12656@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps bind_af_aware() should find its place in test.support. Also, using test.support.unlink means it filters out acceptable errnos.

Also, do we want an IPv6 test with poll, or is it overkill?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:11:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 20:11:59 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314216719.12.0.736879801191.issue12801@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> It would probably be simpler, safer and more efficient to simply call
> the POSIX function instead (but it most be exposed somewhere, by
> posixmodule.c I suppose).

Indeed.

> Would it be a good idea to use the full docstring of posixpath.realpath
> to os.realpath and then just do ?realpath = os.realpath? in posixpath?

Yes. That would also be a way to add the '.' default argument.

> An initial patch.

I'm actually concerned because realpath doesn't seem as portable as I first thought. Here's what my man page says:
"""
OSIX.1-2001 says that the behavior if resolved_path is NULL is implementation-defined.  POSIX.1-2008 specifies the behavior described in this page.
"""

So I'm not sure that all implementations support passing a NULL buffer as argument.

Also:
"""
Solaris may return a relative pathname when the path argument is relative.
"""

Well, I guess we can also commit this patch and see if a buildbot breaks...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:12:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:12:40 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314216760.49.0.0296941385575.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I haven't seen any discussion on python-dev. Have I missed something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:16:36 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 24 Aug 2011 20:16:36 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1314216996.96.0.161068207246.issue4106@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

In Antoine's patch, ISTM that the line

created_by_this_process = ...

could also be deleted, as the patch no longer uses that value and it's not used anywhere later in the method.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:17:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 20:17:22 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1314216760.49.0.0296941385575.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2tfERAErgJLb5dBW0X3ritgQyaZRTYy=RQPsTyTn7tjw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I haven't seen any discussion on python-dev. Have I missed something?

It was on Python-ideas actually:
http://mail.python.org/pipermail/python-ideas/2011-August/011183.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:18:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 20:18:44 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314217124.58.0.246057718738.issue12801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

i12801.patch is not correct: on Windows, you should never encode a filename to bytes. Use PyUnicode_Decode() + _Py_wrealpath(), or a #ifdef (as many other posixmodule functions).

I prefer to reuse _Py_wrealpath because we will have to add special cases: realpath(NULL) and also maybe canonicalize_file_name().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:19:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:19:54 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1314217194.95.0.701074187129.issue12786@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You might want to add a comment in the patch that the cloexec flag is removed from the child's pipes by calling dup2() before exec() :) I was a bit baffled at first when reading the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:30:27 2011
From: report at bugs.python.org (Ask Solem)
Date: Wed, 24 Aug 2011 20:30:27 +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: <1314217827.85.0.60373330166.issue8713@psf.upfronthosting.co.za>


Ask Solem <ask at celeryproject.org> added the comment:

I have suspected that this may be necessary, not just merely useful, for some time, and issue6721 seems to verify that.  In addition to adding the keyword arg to Process, it should also be added to Pool and Manager.

Is anyone working on a patch? If not I will work on a patch asap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:35:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:35:55 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314218155.01.0.812761232737.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, right. Well I think all arguments against it were quite weak (or even wrong). Let's see:

- it's not cross-platform: actually it is (OS_EXCL has been POSIX since at least 1997 (*), and Windows also has it)

- os.open followed by os.fdopen is easy: it isn't that easy to get the incantation right (the pure Python open() in _pyio is 70 lines of code), especially if you want the file object to have the right "name" attribute

- it doesn't fill a use case: actually, avoiding race conditions is an important use case, even though many people may never encounter it (I must admit I myself never really cared about this)

So this looks like a reasonable feature request IMHO.

(*) http://pubs.opengroup.org/onlinepubs/007908799/xsh/open.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:38:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 20:38:35 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1314217194.95.0.701074187129.issue12786@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2cxNdrWcFZDasaAB82n_giwGjasHntSP_aS0G9ONXf-w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

With comment.
I'll add a similar comment to default.

----------
Added file: http://bugs.python.org/file23032/subprocess_cloexec-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________
-------------- next part --------------
diff -r d4d9a3e71897 Lib/subprocess.py
--- a/Lib/subprocess.py	Tue Aug 23 19:54:20 2011 +0200
+++ b/Lib/subprocess.py	Wed Aug 24 22:36:58 2011 +0200
@@ -1035,7 +1035,7 @@
             if stdin is None:
                 pass
             elif stdin == PIPE:
-                p2cread, p2cwrite = os.pipe()
+                p2cread, p2cwrite = self._pipe2()
             elif isinstance(stdin, int):
                 p2cread = stdin
             else:
@@ -1045,7 +1045,7 @@
             if stdout is None:
                 pass
             elif stdout == PIPE:
-                c2pread, c2pwrite = os.pipe()
+                c2pread, c2pwrite = self._pipe2()
             elif isinstance(stdout, int):
                 c2pwrite = stdout
             else:
@@ -1055,7 +1055,7 @@
             if stderr is None:
                 pass
             elif stderr == PIPE:
-                errread, errwrite = os.pipe()
+                errread, errwrite = self._pipe2()
             elif stderr == STDOUT:
                 errwrite = c2pwrite
             elif isinstance(stderr, int):
@@ -1082,6 +1082,19 @@
                 fcntl.fcntl(fd, fcntl.F_SETFD, old & ~cloexec_flag)
 
 
+        def _pipe2(self, cloexec=True):
+            """Ad-hoc pipe2() implementation."""
+            # Pipes are set CLOEXEC by default because we don't want them to be
+            # inherited by other subprocesses: the CLOEXEC flag is removed from
+            # the child's pipes by _dup2(), between fork() and exec().
+            # This is not atomic: we would need the pipe2() syscall for that.
+            r, w = os.pipe()
+            if cloexec:
+                self._set_cloexec_flag(r)
+                self._set_cloexec_flag(w)
+            return r, w
+
+
         def _close_fds(self, but):
             if hasattr(os, 'closerange'):
                 os.closerange(3, but)
@@ -1120,11 +1133,9 @@
             # For transferring possible exec failure from child to parent
             # The first char specifies the exception type: 0 means
             # OSError, 1 means some other error.
-            errpipe_read, errpipe_write = os.pipe()
+            errpipe_read, errpipe_write = self._pipe2()
             try:
                 try:
-                    self._set_cloexec_flag(errpipe_write)
-
                     gc_was_enabled = gc.isenabled()
                     # Disable gc to avoid bug where gc -> file_dealloc ->
                     # write to stderr -> hang.  http://bugs.python.org/issue1336
diff -r d4d9a3e71897 Lib/test/test_subprocess.py
--- a/Lib/test/test_subprocess.py	Tue Aug 23 19:54:20 2011 +0200
+++ b/Lib/test/test_subprocess.py	Wed Aug 24 22:36:58 2011 +0200
@@ -995,6 +995,37 @@
         self.assertRaises(OSError, os.waitpid, pid, 0)
         self.assertNotIn(ident, [id(o) for o in subprocess._active])
 
+    def test_pipe_cloexec(self):
+        # Issue 12786: check that the parent-end FDs of the communication pipes
+        # are set CLOEXEC, and not inherited by another child process.
+        p1 = subprocess.Popen([sys.executable, "-c",
+                               'import os;'
+                               'os.read(0)'
+                              ],
+                              stdin=subprocess.PIPE, stdout=subprocess.PIPE,
+                              stderr=subprocess.PIPE)
+
+        p2 = subprocess.Popen([sys.executable, "-c", """if True:
+                               import os, errno, sys
+                               for fd in %r:
+                                   try:
+                                       os.close(fd)
+                                   except OSError as e:
+                                       if e.errno != errno.EBADF:
+                                           raise
+                                   else:
+                                       sys.exit(1)
+                               sys.exit(0)
+                               """ % [f.fileno() for f in (p1.stdin, p1.stdout,
+                                                           p1.stderr)]
+                              ],
+                              stdin=subprocess.PIPE, stdout=subprocess.PIPE,
+                              stderr=subprocess.PIPE, close_fds=False)
+        p1.communicate('foo')
+        _, stderr = p2.communicate()
+
+        self.assertEqual(p2.returncode, 0, "Unexpected error: " + repr(stderr))
+
 
 @unittest.skipUnless(mswindows, "Windows specific tests")
 class Win32ProcessTestCase(BaseTestCase):

From report at bugs.python.org  Wed Aug 24 22:41:43 2011
From: report at bugs.python.org (Jesse Noller)
Date: Wed, 24 Aug 2011 20:41:43 +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: <1314218503.23.0.865764602736.issue8713@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

No one is currently working on a patch AFAIK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:43:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 20:43:57 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <E1QwKIl-00036F-69@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d316315a8781 by Antoine Pitrou in branch '2.7':
Issue #4106: Fix occasional exceptions printed out by multiprocessing on interpreter shutdown.
http://hg.python.org/cpython/rev/d316315a8781

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 22:52:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:52:15 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1314219135.8.0.960550099059.issue4106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This should hopefully be fixed now. Feel free to reopen if it isn't.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:02:08 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 21:02:08 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1314216606.84.0.291640288403.issue12656@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2H9O5z08emQzeySWUsR4PK_=WWj25cpVOfeXLHtymVoA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

New patch.

> Perhaps bind_af_aware() should find its place in test.support.

I'm not sure, it's really specific to this test.

> Also, using test.support.unlink means it filters out acceptable errnos.

Thanks, I didn't know about this.

> Also, do we want an IPv6 test with poll, or is it overkill?

Let's add it (especially since test_asyncore is really fast).

----------
Added file: http://bugs.python.org/file23033/test_ayncore-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________
-------------- next part --------------
diff -r c53db7dc4b8f Lib/test/test_asyncore.py
--- a/Lib/test/test_asyncore.py	Wed Aug 24 21:40:53 2011 +0200
+++ b/Lib/test/test_asyncore.py	Wed Aug 24 23:00:33 2011 +0200
@@ -87,6 +87,13 @@
         serv.close()
         evt.set()
 
+def bind_af_aware(sock, addr):
+    """Helper function to bind a socket according to its family."""
+    if sock.family == socket.AF_UNIX:
+        # Make sure the path doesn't exist.
+        unlink(addr)
+    sock.bind(addr)
+
 
 class HelperFunctionTests(unittest.TestCase):
     def test_readwriteexc(self):
@@ -467,22 +474,22 @@
         raise
 
 
-class TCPServer(asyncore.dispatcher):
+class BaseServer(asyncore.dispatcher):
     """A server which listens on an address and dispatches the
     connection to a handler.
     """
 
-    def __init__(self, handler=BaseTestHandler, host=HOST, port=0):
+    def __init__(self, family, addr, handler=BaseTestHandler):
         asyncore.dispatcher.__init__(self)
-        self.create_socket()
+        self.create_socket(family)
         self.set_reuse_addr()
-        self.bind((host, port))
+        bind_af_aware(self.socket, addr)
         self.listen(5)
         self.handler = handler
 
     @property
     def address(self):
-        return self.socket.getsockname()[:2]
+        return self.socket.getsockname()
 
     def handle_accepted(self, sock, addr):
         self.handler(sock)
@@ -493,9 +500,9 @@
 
 class BaseClient(BaseTestHandler):
 
-    def __init__(self, address):
+    def __init__(self, family, address):
         BaseTestHandler.__init__(self)
-        self.create_socket()
+        self.create_socket(family)
         self.connect(address)
 
     def handle_connect(self):
@@ -525,8 +532,8 @@
             def handle_connect(self):
                 self.flag = True
 
-        server = TCPServer()
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     def test_handle_accept(self):
@@ -534,18 +541,18 @@
 
         class TestListener(BaseTestHandler):
 
-            def __init__(self):
+            def __init__(self, family, addr):
                 BaseTestHandler.__init__(self)
-                self.create_socket()
-                self.bind((HOST, 0))
+                self.create_socket(family)
+                bind_af_aware(self.socket, addr)
                 self.listen(5)
-                self.address = self.socket.getsockname()[:2]
+                self.address = self.socket.getsockname()
 
             def handle_accept(self):
                 self.flag = True
 
-        server = TestListener()
-        client = BaseClient(server.address)
+        server = TestListener(self.family, self.addr)
+        client = BaseClient(self.family, server.address)
         self.loop_waiting_for_flag(server)
 
     def test_handle_accepted(self):
@@ -553,12 +560,12 @@
 
         class TestListener(BaseTestHandler):
 
-            def __init__(self):
+            def __init__(self, family, addr):
                 BaseTestHandler.__init__(self)
-                self.create_socket()
-                self.bind((HOST, 0))
+                self.create_socket(family)
+                bind_af_aware(self.socket, addr)
                 self.listen(5)
-                self.address = self.socket.getsockname()[:2]
+                self.address = self.socket.getsockname()
 
             def handle_accept(self):
                 asyncore.dispatcher.handle_accept(self)
@@ -567,8 +574,8 @@
                 sock.close()
                 self.flag = True
 
-        server = TestListener()
-        client = BaseClient(server.address)
+        server = TestListener(self.family, self.addr)
+        client = BaseClient(self.family, server.address)
         self.loop_waiting_for_flag(server)
 
 
@@ -584,8 +591,8 @@
                 BaseTestHandler.__init__(self, conn)
                 self.send(b'x' * 1024)
 
-        server = TCPServer(TestHandler)
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr, TestHandler)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     def test_handle_write(self):
@@ -595,8 +602,8 @@
             def handle_write(self):
                 self.flag = True
 
-        server = TCPServer()
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     def test_handle_close(self):
@@ -619,8 +626,8 @@
                 BaseTestHandler.__init__(self, conn)
                 self.close()
 
-        server = TCPServer(TestHandler)
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr, TestHandler)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     @unittest.skipIf(sys.platform.startswith("sunos"),
@@ -629,6 +636,8 @@
         # Make sure handle_expt is called on OOB data received.
         # Note: this might fail on some platforms as OOB data is
         # tenuously supported and rarely used.
+        if self.family == socket.AF_UNIX:
+            self.skipTest("Not applicable to AF_UNIX sockets.")
 
         class TestClient(BaseClient):
             def handle_expt(self):
@@ -639,8 +648,8 @@
                 BaseTestHandler.__init__(self, conn)
                 self.socket.send(bytes(chr(244), 'latin-1'), socket.MSG_OOB)
 
-        server = TCPServer(TestHandler)
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr, TestHandler)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     def test_handle_error(self):
@@ -657,13 +666,13 @@
                 else:
                     raise Exception("exception not raised")
 
-        server = TCPServer()
-        client = TestClient(server.address)
+        server = BaseServer(self.family, self.addr)
+        client = TestClient(self.family, server.address)
         self.loop_waiting_for_flag(client)
 
     def test_connection_attributes(self):
-        server = TCPServer()
-        client = BaseClient(server.address)
+        server = BaseServer(self.family, self.addr)
+        client = BaseClient(self.family, server.address)
 
         # we start disconnected
         self.assertFalse(server.connected)
@@ -693,25 +702,29 @@
 
     def test_create_socket(self):
         s = asyncore.dispatcher()
-        s.create_socket()
-        self.assertEqual(s.socket.family, socket.AF_INET)
+        s.create_socket(self.family)
+        self.assertEqual(s.socket.family, self.family)
         SOCK_NONBLOCK = getattr(socket, 'SOCK_NONBLOCK', 0)
         self.assertEqual(s.socket.type, socket.SOCK_STREAM | SOCK_NONBLOCK)
 
     def test_bind(self):
+        if self.family == socket.AF_UNIX:
+            self.skipTest("Not applicable to AF_UNIX sockets.")
         s1 = asyncore.dispatcher()
-        s1.create_socket()
-        s1.bind((HOST, 0))
+        s1.create_socket(self.family)
+        s1.bind(self.addr)
         s1.listen(5)
         port = s1.socket.getsockname()[1]
 
         s2 = asyncore.dispatcher()
-        s2.create_socket()
+        s2.create_socket(self.family)
         # EADDRINUSE indicates the socket was correctly bound
-        self.assertRaises(socket.error, s2.bind, (HOST, port))
+        self.assertRaises(socket.error, s2.bind, (self.addr[0], port))
 
     def test_set_reuse_addr(self):
-        sock = socket.socket()
+        if self.family == socket.AF_UNIX:
+            self.skipTest("Not applicable to AF_UNIX sockets.")
+        sock = socket.socket(self.family)
         try:
             sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
         except socket.error:
@@ -719,11 +732,11 @@
         else:
             # if SO_REUSEADDR succeeded for sock we expect asyncore
             # to do the same
-            s = asyncore.dispatcher(socket.socket())
+            s = asyncore.dispatcher(socket.socket(self.family))
             self.assertFalse(s.socket.getsockopt(socket.SOL_SOCKET,
                                                  socket.SO_REUSEADDR))
             s.socket.close()
-            s.create_socket()
+            s.create_socket(self.family)
             s.set_reuse_addr()
             self.assertTrue(s.socket.getsockopt(socket.SOL_SOCKET,
                                                  socket.SO_REUSEADDR))
@@ -731,18 +744,44 @@
             sock.close()
 
 
-class TestAPI_UseSelect(BaseTestAPI):
+class TestAPI_UseIPv4Sockets(BaseTestAPI):
+    family = socket.AF_INET
+    addr = (HOST, 0)
+
+ at unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 support required')
+class TestAPI_UseIPv6Sockets(BaseTestAPI):
+    family = socket.AF_INET6
+    addr = ('::1', 0)
+
+ at unittest.skipUnless(hasattr(socket, 'AF_UNIX'), 'Unix sockets required')
+class TestAPI_UseUnixSockets(BaseTestAPI):
+    family = socket.AF_UNIX
+    addr = support.TESTFN
+    use_poll = False
+
+    def tearDown(self):
+        unlink(self.addr)
+        BaseTestAPI.tearDown(self)
+
+class TestAPI_UseIPv4Select(TestAPI_UseIPv4Sockets):
     use_poll = False
 
 @unittest.skipUnless(hasattr(select, 'poll'), 'select.poll required')
-class TestAPI_UsePoll(BaseTestAPI):
+class TestAPI_UseIPv4Poll(TestAPI_UseIPv4Sockets):
     use_poll = True
 
+class TestAPI_UseIPv6Select(TestAPI_UseIPv6Sockets):
+    use_poll = False
+
+ at unittest.skipUnless(hasattr(select, 'poll'), 'select.poll required')
+class TestAPI_UseIPv6Poll(TestAPI_UseIPv6Sockets):
+    use_poll = True
 
 def test_main():
     tests = [HelperFunctionTests, DispatcherTests, DispatcherWithSendTests,
-             DispatcherWithSendTests_UsePoll, TestAPI_UseSelect,
-             TestAPI_UsePoll, FileWrapperTest]
+            DispatcherWithSendTests_UsePoll, FileWrapperTest,
+            TestAPI_UseIPv4Select, TestAPI_UseIPv4Poll, TestAPI_UseIPv6Select,
+            TestAPI_UseIPv6Poll, TestAPI_UseUnixSockets]
     run_unittest(*tests)
 
 if __name__ == "__main__":

From report at bugs.python.org  Wed Aug 24 23:05:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 21:05:00 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1314219900.35.0.129797858027.issue12656@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:19:02 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Aug 2011 21:19:02 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314220742.96.0.20537441288.issue12760@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> - os.open followed by os.fdopen is easy: it isn't that easy to get
> the incantation right (the pure Python open() in _pyio is 70 lines
> of code), especially if you want the file object to have the right
> "name" attribute

What if we can override the inner call to os.open()?
For example, io.open() could grow an additional argument "fd_opener" which defaults to the equivalent of os.open.

Then creation mode can be expressed like this:
    open(filename, 'w',
         fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT)
Another use case with openat (see #12797):
    open(filename,
         fd_opener=lambda path, mode: os.openat(fd, path, mode)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:20:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 21:20:48 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314220848.83.0.912727150975.issue12803@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have one last concern: what is the character set of an OpenSSL password? I see you are using PyUnicode_AsEncodedString(x, NULL, NULL), which basically returns a utf8-encoded bytestring. Since the OpenSSL doc don't specify anything, we could accept it as a best-effort thing.
Or perhaps we should use PyUnicode_EncodeFSDefault(), which uses the "filesystem encoding", which is usually the same as the current terminal (assuming the password is typed on a terminal).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:22:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 21:22:15 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314220935.87.0.996192069008.issue12801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch to get #ifdef REALPATH_SUPPORT_NULL:

diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -1539,6 +1539,17 @@ if test "$have_pthread_t" = yes ; then
 #endif
   ])
 fi
+
+AC_MSG_CHECKING(for realpath with NULL)
+realpath_support_null=no
+AC_COMPILE_IFELSE([
+  AC_LANG_PROGRAM([[#include <stdlib.h>]], [[char *p = realpath(__FILE__, NULL);]])
+],[realpath_support_null=yes],[])
+AC_MSG_RESULT($realpath_support_null)
+if test "$have_pthread_t" = yes ; then
+  AC_DEFINE(REALPATH_SUPPORT_NULL, 1,
+  [Define if the realpath() function supports NULL as the second argument])
+fi
 CC="$ac_save_cc"
 
 AC_SUBST(OTHER_LIBTOOL_OPT)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:23:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 21:23:09 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <E1QwKuY-0006Vb-6T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b07b0b7517da by Charles-Fran?ois Natali in branch 'default':
Issue #12656: Add tests for IPv6 and Unix sockets to test_asyncore.
http://hg.python.org/cpython/rev/b07b0b7517da

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:24:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 21:24:06 +0000
Subject: [issue1298813] sysmodule.c: realpath() is unsafe
Message-ID: <1314221046.57.0.974703329373.issue1298813@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See issue #12801: it has a more recent patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1298813>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:27:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 21:27:01 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314221221.11.0.154973863685.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What if we can override the inner call to os.open()?
> For example, io.open() could grow an additional argument "fd_opener"
> which defaults to the equivalent of os.open.

I agree it would be a much better situation than what we have now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:28:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 21:28:34 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314221314.28.0.779602901289.issue12801@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I prefer to reuse _Py_wrealpath because we will have
> to add special cases: realpath(NULL) and also maybe
> canonicalize_file_name().

I read that canonicalize_file_name(name) just calls realpath(name, NULL), so we can maybe avoid this GNU exception.

I realized that _Py_wrealpath() returns wchar_t*, so it's maybe better to take the first approach (#ifdef MS_WINDOWS).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:31:04 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Wed, 24 Aug 2011 21:31:04 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314221464.3.0.81554766357.issue12801@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santoso.wijaya at gmail.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:31:25 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Aug 2011 21:31:25 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1314221485.61.0.776674868506.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file23034/python-py3k-20110825-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:34:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 21:34:40 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314221680.79.0.0220620448642.issue12760@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>    open(filename, 'w',
>         fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT)

I prefer open(name, "c").

> it doesn't fill a use case: actually, avoiding race conditions
> is an important use case, ...

It may help the issue #8604 (and maybe #8828).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12760>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:36:03 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Aug 2011 21:36:03 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1314221763.39.0.193495079783.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

follow recent changes to distutils and packaging modules and platform tests without os major version ...
(require python-py3k-20110825-CROSS.patch from #3754)

----------
Added file: http://bugs.python.org/file23035/python-py3k-20110825-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:45:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 21:45:00 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1314220935.87.0.996192069008.issue12801@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM04w8b6xqUd_Ej-8zbPkh4Og5vAiq4hstafa7FuzUZUfw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Patch to get #ifdef REALPATH_SUPPORT_NULL:

I'm not really familiar with autotools, but I have the impression that
this will only check that the given code snippet compiles (and it
will), and we want to check that a NULL buffer is supported at
runtime.
Am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:53:55 2011
From: report at bugs.python.org (Benjamin Gilbert)
Date: Wed, 24 Aug 2011 21:53:55 +0000
Subject: [issue12836] cast() creates circular reference in original object
Message-ID: <1314222835.27.0.518600149254.issue12836@psf.upfronthosting.co.za>


New submission from Benjamin Gilbert <bgilbert at backtick.net>:

Section 15.17.1.15 of the ctypes documentation illustrates the use of cast() thusly:

>>> a = (c_byte * 4)()
>>> cast(a, POINTER(c_int))
<ctypes.LP_c_long object at ...>
>>>

Executing the cast() causes a._objects to gain a reference back to a:

>>> a = (c_byte * 4)()
>>> a._objects
>>> cast(a, POINTER(c_int))
<__main__.LP_c_int object at 0x7fb879065b90>
>>> a._objects
{140430281170384: <__main__.c_byte_Array_4 object at 0x7fb879065dd0>}
>>> a
<__main__.c_byte_Array_4 object at 0x7fb879065dd0>
>>> 

If large temporary arrays are allocated, cast, used, and discarded in a tight inner loop, a lot of memory can thus be consumed by self-referencing objects before the garbage collector has a chance to run.  Even if this behavior is correct from the perspective of ctypes, it is surprising.

----------
components: ctypes
messages: 142933
nosy: bgilbert
priority: normal
severity: normal
status: open
title: cast() creates circular reference in original object
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12836>
_______________________________________

From report at bugs.python.org  Wed Aug 24 23:56:45 2011
From: report at bugs.python.org (David Watson)
Date: Wed, 24 Aug 2011 21:56:45 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
Message-ID: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>


New submission from David Watson <baikie at users.sourceforge.net>:

Changeset 4736e172fa61 for issue #12810 removed the test 
"msg->msg_controllen < 0" from socketmodule.c, where 
msg_controllen happened to be unsigned on the reporter's system. 
 
I included this test deliberately, because msg_controllen may be 
of signed type (POSIX allows socklen_t to be signed, as objects 
of that type historically were - as the Rationale says: "All 
socklen_t types were originally (in BSD UNIX) of type int."). 
 
Attaching a patch to replace the check and add an accompanying 
comment.

----------
components: Extension Modules
files: restore_controllen_check.diff
keywords: patch
messages: 142934
nosy: baikie
priority: normal
severity: normal
status: open
title: Patch for issue #12810 removed a valid check on socket ancillary data
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23036/restore_controllen_check.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:04:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 22:04:58 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1314223498.68.0.785530183838.issue12837@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/issue12837>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:13:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 22:13:45 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1314224025.08.0.334496745114.issue12837@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I included this test deliberately, because msg_controllen may be 
> of signed type [...] POSIX allows socklen_t to be signed

http://pubs.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
"""
<sys/socket.h> makes available a type, socklen_t, which is an unsigned opaque integral type of length of at least 32 bits. To forestall portability problems, it is recommended that applications should not use values larger than 2**32 - 1.
"""

It seems pretty clear to me.
Did you actually encounter this problem on any OS?
Furthermore, even if it was the case, I don't see how we could end up with a negative value for msg_controllen (it's a buffer length), since it's set by the kernel.
Also, I'm not convinced by this:

   /* Check for empty ancillary data as old CMSG_FIRSTHDR()
       implementations didn't do so. */
    for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
         cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {

Did you really have reports of CMSG_NXTHDR not returning NULL upon empty ancillary data (it's also raquired by POSIX)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:35:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 22:35:12 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1314225312.16.0.808983714386.issue12837@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I checked in glibc, FreeBSD and OpenBSD source codes, and they all define socklen_t as an unsigned integer.
I think the confusion arises from this:
"""
       The  third argument of accept() was originally declared as an int * (and is that under libc4 and libc5 and on many other systems like 4.x BSD, SunOS 4, SGI); a POSIX.1g
       draft standard wanted to change it into a size_t *, and that is what it is for SunOS 5.  Later POSIX drafts have socklen_t *, and so do the  Single  Unix  Specification
       and glibc2.
"""

But this only implies that sizeof(socklen_t) == sizeof(int).

> since it's set by the kernel.

The only place where we compute it is in sock_sendmsg, but it would be catched by overflow checks:
        if (controllen > SOCKLEN_T_LIMIT || controllen < controllen_last) {
            PyErr_SetString(socket_error, "too much ancillary data");
            goto finally;
        }

And we use it as malloc() and memset() argument before it's checked by cmsg_min_space...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:37:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:37:28 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1314225448.59.0.646356488502.issue12786@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

subprocess_cloexec-1.diff: I'm too tired too review the test. The subprocess.py part looks correct, except the pipe2 name. Python 3 uses "_create_pipe = _posixsubprocess.cloexec_pipe". Pick one of those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:49:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:49:02 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226142.53.0.0581224751951.issue5113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It's surprising to raise a SkipTest *at the end* of the test. Here is another patch.

----------
Added file: http://bugs.python.org/file23037/chown_hpux-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:49:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 22:49:31 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <E1QwMGI-0004Um-40@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 603025e2d39d by Charles-Fran?ois Natali in branch 'default':
Issue #12656: Fix test_asyncore failures on Windows buildbots.
http://hg.python.org/cpython/rev/603025e2d39d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:50:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:50:19 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226219.48.0.624265762483.issue5113@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file23038/chown_hpux-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:50:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:50:31 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226231.52.0.0433773023126.issue5113@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23037/chown_hpux-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:52:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:52:18 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226338.5.0.204865325387.issue5113@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file23039/chown_hpux-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:53:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:53:19 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226399.86.0.0928411519283.issue5113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Using chown_hpux-4.diff, we don't skip anything on HP-UX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:53:52 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 24 Aug 2011 22:53:52 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1314192733.43.0.923458063158.issue12807@psf.upfronthosting.co.za>
Message-ID: <CABCbifVcvAUz-tpVB-6FiN6PprR0rr9FzZJGjMeyqW7h+BTJwQ@mail.gmail.com>


John O'Connor <tehjcon at gmail.com> added the comment:

You are right about those lines in particular; 'dubious' as you say.
Though, the point overall was that the general implementation was noticeably
faster (regardless of those smaller changes).

However, I do think that the single check for len == 0 saves time
particularly
from do_xstrip where we call _getbuffer().

I see. I must have been trigger happy.

> > diff -r b5ccdf7c032a Python/bltinmodule.c
> > Binary file Python/bltinmodule.c has changed
>
> Uh, what's this? bltinmodule.c shouldn't be considered a binary file.
> It probably means you added a NUL byte in it by mistake.
>
> I didn't touch that file at all. I'm not sure what that is. :-P

> Looking at just how similar these 3 implementations are I feel that we
> > could also unify/generalize them into one generic helper implementation
> > and leave the object marshaling up to the type specific methods.
>
> You could put it in Objects/stringlib.
>

I figured. I will when I am able to get to it.

- John

----------
Added file: http://bugs.python.org/file23040/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________
-------------- next part --------------
<div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Antoine Pitrou &lt;<a href="mailto:pitrou at free.fr">pitrou at free.fr</a>&gt; added the comment:<br>
<br>
+ ?? ??if (len == 0) {<br>
+ ?? ?? ?? ??if (PyByteArray_CheckExact(self)) {<br>
+ ?? ?? ?? ?? ?? ??Py_INCREF(self);<br>
+ ?? ?? ?? ?? ?? ??return (PyObject *)self;<br>
+ ?? ?? ?? ??}<br>
+ ?? ?? ?? ??return PyByteArray_FromStringAndSize(NULL, 0);<br>
+ ?? ??}<br>
<br>
This looks like a dubious micro-optimization. If len == 0,<br>
all loops will exit early anyway (same for similar snippets in bytesobject.c and unicodeobject.c).<br>
<br></blockquote><br class="Apple-interchange-newline">You are right about those lines in particular; &#39;dubious&#39; as you say.??<div>Though, the point overall was that the general implementation was??noticeably</div><div>
faster??(regardless of those smaller changes).??</div><div><br></div><div>However, I do think that the single check??for len == 0 saves time particularly</div><div>from do_xstrip where we call _getbuffer().</div><div><br></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
+ ?? ??if (i == 0 &amp;&amp; j == len &amp;&amp; PyByteArray_CheckExact(self)) {<br>
+ ?? ?? ?? ??Py_INCREF(self);<br>
+ ?? ?? ?? ??return (PyObject *)self;<br>
+ ?? ??}<br>
<br>
bytearray objects are mutable, so you can&#39;t return the same object without breaking expected semantics. e.g.:<br>
<br></blockquote><div><br></div><div>I see. I must have been trigger happy.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
&gt; diff -r b5ccdf7c032a Python/bltinmodule.c<br>
&gt; Binary file Python/bltinmodule.c has changed<br>
<br>
Uh, what&#39;s this? bltinmodule.c shouldn&#39;t be considered a binary file.<br>
It probably means you added a NUL byte in it by mistake.<br>
<div class="im"><br></div></blockquote><div>I didn&#39;t touch that file at all. I&#39;m not sure what that is. :-P</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
&gt; Looking at just how similar these 3 implementations are I feel that we<br>
&gt; could also unify/generalize them into one generic helper implementation<br>
&gt; and leave the object marshaling up to the type specific methods.<br>
<br>
</div>You could put it in Objects/stringlib.<br></blockquote><div><br></div><div>I figured. I will when I am able to get to it.</div><div><br></div><div><br></div><div>- John</div></div></div>

From report at bugs.python.org  Thu Aug 25 00:56:08 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 24 Aug 2011 22:56:08 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1314226568.03.0.465274890191.issue12807@psf.upfronthosting.co.za>


Changes by John O'Connor <tehjcon at gmail.com>:


Removed file: http://bugs.python.org/file23040/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:57:40 2011
From: report at bugs.python.org (John O'Connor)
Date: Wed, 24 Aug 2011 22:57:40 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1314226660.07.0.0414636259993.issue12807@psf.upfronthosting.co.za>


John O'Connor <tehjcon at gmail.com> added the comment:

Antoine Pitrou <pitrou at free.fr> added the comment:

> This looks like a dubious micro-optimization. If len == 0,
> all loops will exit early anyway (same for similar snippets in bytesobject.c and unicodeobject.c).

You are right about those lines in particular; 'dubious' as you say. 
Though, the point overall was that the general implementation was noticeably
faster (regardless of those smaller changes). 

However, I do think that the single check for len == 0 saves time particularly
from do_xstrip where we call _getbuffer().


> bytearray objects are mutable, so you can't return the same object without breaking expected semantics. e.g.:

I see. I must have been trigger happy.


> diff -r b5ccdf7c032a Python/bltinmodule.c
> Binary file Python/bltinmodule.c has changed

> Uh, what's this? bltinmodule.c shouldn't be considered a binary file.
> It probably means you added a NUL byte in it by mistake.

I didn't touch that file at all. I'm not sure what that is. :-P

> You could put it in Objects/stringlib.

I figured. I will when I am able to get to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12807>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:59:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 22:59:22 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <CAH_1eM04w8b6xqUd_Ej-8zbPkh4Og5vAiq4hstafa7FuzUZUfw@mail.gmail.com>
Message-ID: <201108250058.53249.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 24 ao?t 2011 23:45:00, vous avez ?crit :
> Charles-Fran?ois Natali <neologix at free.fr> added the comment:
> > Patch to get #ifdef REALPATH_SUPPORT_NULL:
> I'm not really familiar with autotools, but I have the impression that
> this will only check that the given code snippet compiles (and it
> will), and we want to check that a NULL buffer is supported at
> runtime.
> Am I missing something?

Oh, you are right. I don't know autotools, I'm trying to learn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Thu Aug 25 00:59:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 22:59:40 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226780.3.0.633923077655.issue5113@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Using chown_hpux-4.diff, we don't skip anything on HP-UX.

Victor, I don't understand your patch: if we try chown()ing a file to root, then this will fail on HP-UX (because chown won't fail with EPERM). That's the whole point of the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:01:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 23:01:13 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226873.64.0.19171973614.issue5113@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file23039/chown_hpux-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:02:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 23:02:26 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314226946.21.0.538478096188.issue5113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> if we try chown()ing a file to root, then this will fail on HP-UX

Oooh, I'm confused. I removed this stupid patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:04:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 23:04:11 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314227051.15.0.974357967041.issue5113@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

# HP-UX and Solaris allow a non-root user to chown to root

I didn't see failure on our Solaris / OpenIndiana buildbot. Should we really skip the test on Solaris?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:07:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 23:07:22 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1314227242.97.0.898569341505.issue12287@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You might replace "#if defined(_MSC_VER)" with "#if defined(MS_WINDOWS)", but in another commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:15:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 23:15:28 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1314227051.15.0.974357967041.issue5113@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Zg944qGaRYnS1=0Rkmnoscfw0_YNg2=Q6hyb6dTY9pQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Well, IIRC, I read in the Solaris man pages that it behaves like HP-UX
in this regard. But this it can be changed with `setprivgrp`, so it
might work on some machines, and fail on others.
According to http://unix.derkeiler.com/Newsgroups/comp.unix.solaris/2004-03/2579.html,
the test should work with the default setting (maybe the OP was
testing on a HP-UX machine with the non-default setting).
Anyway, since it depends on the system configuration, I wanted to stay
on the safe side, and just skip on both OS.
But I honestly don't have a strong opinion about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 01:21:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Aug 2011 23:21:39 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <E1QwMlN-0006Y5-N4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f3444d795062 by Charles-Fran?ois Natali in branch 'default':
Issue #12656: Really fix test_asyncore failures on Windows buildbots...
http://hg.python.org/cpython/rev/f3444d795062

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Thu Aug 25 02:57:13 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Thu, 25 Aug 2011 00:57:13 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1314233833.55.0.198770167315.issue6676@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

The documentation should definitely be updated to clarify that a parser instance is not reusable with more than one file.  I had a look at the equivalent documentation for Perl and TCL, and Perl's implementation explicitly does not allow attempts to reuse the parser instance (which is clearly noted in the documentation), and TCL's implementation (or one of them, anyway) offers a reset call that explicitly resets the parser in preparation for another file to be submitted.

----------
nosy: +dhgutteridge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Thu Aug 25 03:17:39 2011
From: report at bugs.python.org (Nayuta Taga)
Date: Thu, 25 Aug 2011 01:17:39 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1314235059.8.0.166335501572.issue7983@psf.upfronthosting.co.za>


Changes by Nayuta Taga <ganaware+bugs.python.org at gmail.com>:


Removed file: http://bugs.python.org/file16301/cp932_roundtrip.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Thu Aug 25 03:25:59 2011
From: report at bugs.python.org (Nayuta Taga)
Date: Thu, 25 Aug 2011 01:25:59 +0000
Subject: [issue7983] The encoding map from Unicode to CP932 is different from
	that of Windows'
In-Reply-To: <1266844323.37.0.847298507631.issue7983@psf.upfronthosting.co.za>
Message-ID: <1314235559.77.0.177155369761.issue7983@psf.upfronthosting.co.za>


Nayuta Taga <ganaware+bugs.python.org at gmail.com> added the comment:

I have updated the tables about the latest Pythons (2.7.2, 3.2.1).
The patches for 2.7a3 can be applied to 2.7.2 and 3.2.1 successfully.

The latest Pythons still have the problem.
Their encoding maps from Unicode to CP932 are different from those of Windows'.

----------
Added file: http://bugs.python.org/file23041/cp932_roundtrip.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7983>
_______________________________________

From report at bugs.python.org  Thu Aug 25 04:50:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 25 Aug 2011 02:50:38 +0000
Subject: [issue12838] FAQ/Programming typo: range[3] is used
Message-ID: <1314240637.99.0.384249238245.issue12838@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User report from docs at python:


On
http://docs.python.org/faq/programming.html

for i in range[3]:

Should be:

for i in range(3):

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142952
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: FAQ/Programming typo: range[3] is used
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12838>
_______________________________________

From report at bugs.python.org  Thu Aug 25 05:13:23 2011
From: report at bugs.python.org (Zachary Richey)
Date: Thu, 25 Aug 2011 03:13:23 +0000
Subject: [issue12832] The documentation for the print function should
	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314242003.75.0.641347985456.issue12832@psf.upfronthosting.co.za>


Zachary Richey <mach1723 at gmail.com> added the comment:

I'm not sure if this is good documentation, but it explains how the encoding is gotten for stdout and stderr.

----------
keywords: +patch
nosy: +mach1723
Added file: http://bugs.python.org/file23042/functions_print_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12832>
_______________________________________

From report at bugs.python.org  Thu Aug 25 07:21:49 2011
From: report at bugs.python.org (rmtew)
Date: Thu, 25 Aug 2011 05:21:49 +0000
Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
Message-ID: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za>


New submission from rmtew <richard.m.tew at gmail.com>:

zlibmodule.c calling inflateInit2 and deflateInit2 will subsequently proceed to crash in the case where these functions return Z_VERSION_ERROR.

zlib implementation note:

When you compile against zlib, several functions (actually macros) like inflateInit2 and deflateInit2 compile the version of zlib you are compiling against into the actual call of the underlying real zlib API function.

Our situation:

We are compiling Python as a static library.  When we link Python against our main project,  it links against the version of zlib used by that main project.  The version numbers are different, and rather than getting a nice exception we get a crash.

Expected result:

Proper error handling in zlibmodule.c, and not crash.  Unhandled errors in zlibmodule.c are passed into the custom function zlib_error which looks at the msg field of the zst struct.  In the case of Z_VERSION_ERROR the msg field is not initialised and a crash will result from use of the nonsense value in msg.

----------
components: None
messages: 142954
nosy: rmtew
priority: normal
severity: normal
status: open
title: zlibmodule cannot handle Z_VERSION_ERROR zlib error
type: crash
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12839>
_______________________________________

From report at bugs.python.org  Thu Aug 25 07:43:28 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Thu, 25 Aug 2011 05:43:28 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314251008.43.0.367839411281.issue12803@psf.upfronthosting.co.za>


Adam Simpkins <adam at adamsimpkins.net> added the comment:

OpenSSL doesn't appear to do any special handling for i18n, and just
treats the strings as binary data.  It uses fgets() to read the password
from the terminal, so it will receive it however the terminal encodes
it.

It's not clear to me that PyUnicode_EncodeFSDefault() is quite the right
thing to do.  The initfsencoding() routine seems different from how
initstdio() works (which checks the PYTHONIOENCODING environment
variable, and then appears to fall back to os.device_encoding()).

I'm leaning towards just updating the docs to specify that if a string
is supplied it will be encoded using UTF-8.  I'm happy to do either way
you recommend, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Thu Aug 25 07:55:52 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Thu, 25 Aug 2011 05:55:52 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314251752.28.0.795145071841.issue12803@psf.upfronthosting.co.za>


Adam Simpkins <adam at adamsimpkins.net> added the comment:

Here's a patch with updates to the documentation to more fully specify the
behavior of the password field, including specifying that strings will be
encoded using UTF-8.

----------
Added file: http://bugs.python.org/file23043/ssl-password.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Thu Aug 25 08:57:44 2011
From: report at bugs.python.org (Remi Pointel)
Date: Thu, 25 Aug 2011 06:57:44 +0000
Subject: [issue6419] Broken test_kqueue.py on OpenBSD
In-Reply-To: <1246742581.68.0.218952543803.issue6419@psf.upfronthosting.co.za>
Message-ID: <1314255464.92.0.0902644090305.issue6419@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,
I think this issue is relied to issue 12181.

I have made tests.

################
1)with no patch:
################
testPair (__main__.TestKQueue) ... ok
test_create_event (__main__.TestKQueue) ... FAIL
test_create_queue (__main__.TestKQueue) ... ok
test_queue_event (__main__.TestKQueue) ... FAIL

======================================================================
FAIL: test_create_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 28, in test_create_event
    self.assertEqual(ev.ident, fd)
AssertionError: 562945658454018L != 2

======================================================================
FAIL: test_queue_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 129, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(1688841270329350L, -2, 5L), ... != [(6, -2, 0), (7, -2, 0)]

First differing element 0:
(1688841270329350L, -2, 5L)
(6, -2, 0)

- [(1688841270329350L, -2, 5L), (1688841270329351L, -2, 5L)]
+ [(6, -2, 0), (7, -2, 0)]

----------------------------------------------------------------------
Ran 4 tests in 0.002s

FAILED (failures=2)
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 196, in <module>
    test_main()
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 193, in test_main
    test_support.run_unittest(TestKQueue)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

#####################################
2)with patch-Lib_test_test_kqueue_py:
#####################################
testPair (__main__.TestKQueue) ... ok
test_create_event (__main__.TestKQueue) ... FAIL
test_create_queue (__main__.TestKQueue) ... ok
test_queue_event (__main__.TestKQueue) ... FAIL

======================================================================
FAIL: test_create_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 28, in test_create_event
    self.assertEqual(ev.ident, fd)
AssertionError: 562945658454018L != 2

======================================================================
FAIL: test_queue_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 130, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(1688841270329350L, -2, 5L), ... != [(6, -2, 5), (7, -2, 5)]

First differing element 0:
(1688841270329350L, -2, 5L)
(6, -2, 5)

- [(1688841270329350L, -2, 5L), (1688841270329351L, -2, 5L)]
+ [(6, -2, 5), (7, -2, 5)]

----------------------------------------------------------------------
Ran 4 tests in 0.002s

FAILED (failures=2)
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 197, in <module>
    test_main()
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 194, in test_main
    test_support.run_unittest(TestKQueue)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

#####################################################
3)with patch-Modules_selectmodule_c (see issue 12181)
#####################################################
testPair (__main__.TestKQueue) ... ok
test_create_event (__main__.TestKQueue) ... ERROR
test_create_queue (__main__.TestKQueue) ... ok
test_queue_event (__main__.TestKQueue) ... FAIL

======================================================================
ERROR: test_create_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 74, in test_create_event
    ev = select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum)
OverflowError: signed integer is greater than maximum

======================================================================
FAIL: test_queue_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 129, in test_queue_event
    (server.fileno(), select.KQ_FILTER_WRITE, flags)])
AssertionError: Lists differ: [(6L, -2, 5L), (7L, -2, 5L)] != [(6, -2, 0), (7, -2, 0)]

First differing element 0:
(6L, -2, 5L)
(6, -2, 0)

- [(6L, -2, 5L), (7L, -2, 5L)]
?    -      ^^     -      ^^

+ [(6, -2, 0), (7, -2, 0)]
?          ^           ^


----------------------------------------------------------------------
Ran 4 tests in 0.002s

FAILED (failures=1, errors=1)
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 196, in <module>
    test_main()
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 193, in test_main
    test_support.run_unittest(TestKQueue)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

#####################################################################
4)with patch-Modules_selectmodule_c and patch-Lib_test_test_kqueue_py
#####################################################################
BRARY_PATH=/usr/ports/pobj/Python-2.7.1/Python-2.7.1 /usr/ports/pobj/Python-2.7.1/Python-2.7.1/python /usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py
testPair (__main__.TestKQueue) ... ok
test_create_event (__main__.TestKQueue) ... ERROR
test_create_queue (__main__.TestKQueue) ... ok
test_queue_event (__main__.TestKQueue) ... ok

======================================================================
ERROR: test_create_event (__main__.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 74, in test_create_event
    ev = select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum)
OverflowError: signed integer is greater than maximum

----------------------------------------------------------------------
Ran 4 tests in 0.001s

FAILED (errors=1)
Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 197, in <module>
    test_main()
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 194, in test_main
    test_support.run_unittest(TestKQueue)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/ports/pobj/Python-2.7.1/Python-2.7.1/Lib/test/test_kqueue.py", line 74, in test_create_event
    ev = select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum)
OverflowError: signed integer is greater than maximum


Don't hesitate if you need more informations, but I think we must close issue 12181 before.

Thanks a lot,
Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6419>
_______________________________________

From report at bugs.python.org  Thu Aug 25 09:00:49 2011
From: report at bugs.python.org (rmtew)
Date: Thu, 25 Aug 2011 07:00:49 +0000
Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
In-Reply-To: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za>
Message-ID: <1314255649.6.0.894618281737.issue12839@psf.upfronthosting.co.za>


rmtew <richard.m.tew at gmail.com> added the comment:

Attached is a patch to fix the issue, generated using "p4 diff -du" which should hopefully be usable.

----------
keywords: +patch
Added file: http://bugs.python.org/file23044/zlibmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12839>
_______________________________________

From report at bugs.python.org  Thu Aug 25 09:22:35 2011
From: report at bugs.python.org (Luca Fabbri)
Date: Thu, 25 Aug 2011 07:22:35 +0000
Subject: [issue12840] "maintainer" value clear the "author" value when register
Message-ID: <1314256955.86.0.420020912731.issue12840@psf.upfronthosting.co.za>


New submission from Luca Fabbri <lucafbb at gmail.com>:

I reported this problem in the pypi site issue tracker (issue 3396924):
https://sourceforge.net/tracker/?func=detail&atid=513503&aid=3396924&group_id=66150

However it seems that is a python bug.

If in one package's setup.py I provide maintainer (with email) and author (whit email) after the "python setup.py register ... upload" I create a new package where I see the maintainer as a creator.

If I manually fix it through the pypi user interface all works, so seems that this is only a bug of the register procedure.

----------
assignee: tarek
components: Distutils
messages: 142959
nosy: eric.araujo, keul, tarek
priority: normal
severity: normal
status: open
title: "maintainer" value clear the "author" value when register
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12840>
_______________________________________

From report at bugs.python.org  Thu Aug 25 09:25:23 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Thu, 25 Aug 2011 07:25:23 +0000
Subject: [issue11576] timedelta subtraction glitch on big timedelta values
In-Reply-To: <1300300374.42.0.323592740228.issue11576@psf.upfronthosting.co.za>
Message-ID: <1314257123.49.0.815889258075.issue11576@psf.upfronthosting.co.za>


G?k?en Eraslan <gokcen at pardus.org.tr> added the comment:

I can still reproduce that error with Python 2.7.2:

Python 2.7.1 (r271:86832, Apr 27 2011, 15:42:42) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import *
>>> timedelta(999999999, 86399, 999999) - timedelta(999999999, 86399, 999998)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: days=-1000000000; must have magnitude <= 999999999
>>> 

and I see that patch is applied in 2.7.2.

----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11576>
_______________________________________

From report at bugs.python.org  Thu Aug 25 10:10:44 2011
From: report at bugs.python.org (Philipp Weinfurter)
Date: Thu, 25 Aug 2011 08:10:44 +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: <1314259844.76.0.0369750649631.issue2259@psf.upfronthosting.co.za>


Philipp Weinfurter <wirrwuzzi at gmail.com> added the comment:

>From AIFF-C Draft '91, Section 5, Sound Data Chunk:
"If soundData[] contains an odd number of bytes, a pad byte with a value of zero is added at the end to preserve an even length for this
Chunk."

So I think aifc.patch is wrong.

However, Chunk.skip() is broken for non-seekable files, I added a trivial patch

----------
nosy: +phew
Added file: http://bugs.python.org/file23045/chunk2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Thu Aug 25 10:19:16 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 25 Aug 2011 08:19:16 +0000
Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
In-Reply-To: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za>
Message-ID: <1314260356.51.0.588986072686.issue12839@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Thanks for the bug report and patch. I'll take a look at it over the weekend.

----------
assignee:  -> nadeem.vawda
components: +Extension Modules -None
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12839>
_______________________________________

From report at bugs.python.org  Thu Aug 25 11:53:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 09:53:17 +0000
Subject: [issue12838] FAQ/Programming typo: range[3] is used
In-Reply-To: <1314240637.99.0.384249238245.issue12838@psf.upfronthosting.co.za>
Message-ID: <E1QwWcO-0002nf-BR@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0abe03195d09 by Georg Brandl in branch '3.2':
Close #12838: fix range() call.
http://hg.python.org/cpython/rev/0abe03195d09

New changeset 16a90cdb5ee4 by Georg Brandl in branch '2.7':
Close #12838: fix range() call.
http://hg.python.org/cpython/rev/16a90cdb5ee4

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12838>
_______________________________________

From report at bugs.python.org  Thu Aug 25 13:32:38 2011
From: report at bugs.python.org (Yap Sok Ann)
Date: Thu, 25 Aug 2011 11:32:38 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1314271958.24.0.515501251754.issue5752@psf.upfronthosting.co.za>


Yap Sok Ann <sokann at gmail.com> added the comment:

Just want to mention that until the patch get included, it will be impossible to use the standard library to generate a working BCP (Bulk Copy Program) XML format file for SQL Server, which always requires a TERMINATOR="\r\n" or TERMINATOR="&#13;&#10;" attribute.

----------
nosy: +sayap

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Thu Aug 25 14:24:21 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 25 Aug 2011 12:24:21 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1314275061.48.0.982526314002.issue12786@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Patch looks good after Victor's comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Thu Aug 25 14:33:59 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 25 Aug 2011 12:33:59 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <1314275639.17.0.468153812559.issue12835@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
nosy: +ncoghlan, pitrou
priority: normal -> high
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Thu Aug 25 14:43:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Aug 2011 12:43:37 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <1314276217.44.0.0937144964658.issue12835@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Adding an explanation message to the NotImplementedError would be more helpful. Otherwise, good catch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Thu Aug 25 14:45:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 12:45:49 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <E1QwZJb-0004XL-UF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cdc6c1b072a5 by Antoine Pitrou in branch 'default':
Issue #12803: SSLContext.load_cert_chain() now accepts a password argument
http://hg.python.org/cpython/rev/cdc6c1b072a5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Thu Aug 25 14:46:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Aug 2011 12:46:35 +0000
Subject: [issue12803] SSLContext.load_cert_chain() should accept a password
	argument
In-Reply-To: <1313911706.89.0.687432161899.issue12803@psf.upfronthosting.co.za>
Message-ID: <1314276395.12.0.23159008814.issue12803@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your latest patch was committed, thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12803>
_______________________________________

From report at bugs.python.org  Thu Aug 25 16:17:14 2011
From: report at bugs.python.org (Sebastien Luttringer)
Date: Thu, 25 Aug 2011 14:17:14 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
Message-ID: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>


New submission from Sebastien Luttringer <seblu+python at seblu.net>:

This patch fix extraction of tarfile which override tarfile uid/gid 

tarfile.py extract function override uid/gid of a file if uid/gid is not
existant on the system.

When user is not root (uid 0), common behaviour of extracting is correct.
When user is root, python implementation try to preserve (like tar -p) ownership
from tarball, but if uid/gid doesn't exist it remplace by process uid/gid.
This leads to fake the expected behaviour of preservation!

By example, extracting tarball with a root filesystem will create incorrect
ownership for file where owner/group is not on the current filesystem.

----------
components: Library (Lib)
files: tarfile-bug.patch
keywords: patch
messages: 142969
nosy: seblu
priority: normal
severity: normal
status: open
title: Incorrect tarfile.py extraction
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23046/tarfile-bug.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Thu Aug 25 16:32:29 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 25 Aug 2011 14:32:29 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314282749.41.0.927567111384.issue12841@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Lars, any comment?

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Thu Aug 25 17:24:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Aug 2011 15:24:02 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314285842.5.0.745675811337.issue12841@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Thu Aug 25 17:47:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 15:47:39 +0000
Subject: [issue12840] "maintainer" value clear the "author" value when register
In-Reply-To: <1314256955.86.0.420020912731.issue12840@psf.upfronthosting.co.za>
Message-ID: <1314287259.31.0.901378008438.issue12840@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this is intended behavior.  When the author of a project is the one to register with PyPI, they use the author and author_email fields, which get displayed at PyPI.  When it is not the original author but someone else who packages and registers a project, then they fill author and maintainer entries, and PyPI uses the maintainer/maintainer_email values as person to contact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12840>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:05:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 16:05:43 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1314288343.14.0.80556769396.issue3754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Copy-pasting of a previous comment: I see some ?fix for issue #NNN is bogus? in your patch: would you open separate bug reports for those?  A diff file is not a very useful way to report bugs or express opinions <wink>.

Copy-pasting of many previous comments: distutils does not get new features (cross-compilation is a new feature), please focus on packaging.

----------
assignee:  -> tarek
components: +Distutils2
nosy: +alexis, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:07:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 16:07:45 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1314288465.54.0.73872952722.issue3871@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please read msg136382 and take it into account.  Also, I suggest you wait a bit for packaging patches: GSoC projects need to be reviewed and integrated, which may change large parts of the codebase.

----------
title: cross and native build of python for mingw32 with distutils -> cross and native build of python for mingw32 with packaging

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:08:26 2011
From: report at bugs.python.org (Luca Fabbri)
Date: Thu, 25 Aug 2011 16:08:26 +0000
Subject: [issue12840] "maintainer" value clear the "author" value when register
In-Reply-To: <1314256955.86.0.420020912731.issue12840@psf.upfronthosting.co.za>
Message-ID: <1314288506.23.0.904205065542.issue12840@psf.upfronthosting.co.za>


Luca Fabbri <lucafbb at gmail.com> added the comment:

I'm quite sure that after gettint ownership on an already existent package (with a different author inside) and I added the maintainer (with my name) I get the author override. But maybe I don't remember exactly...

Is not simpler (to understand) to keep always the approach to keep both?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12840>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:14:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 16:14:26 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QwcZV-0000Ex-6s@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 262e03bbe7a9 by ?ric Araujo in branch 'default':
Another (hopefully last) fix for test_packaging on Windws (#12678)
http://hg.python.org/cpython/rev/262e03bbe7a9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:19:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 16:19:03 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1314289143.49.0.251050590222.issue12333@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is strange; TempdirManager.tearDown already changes back to self._olddir (set to os.getcwd() in setUp).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:20:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 16:20:22 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314289222.94.0.249074724035.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Vinay: I don?t understand your message.

I wasn?t part of the effort that added the resources subsystem, so I will work on a patch for this bug to learn more about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:22:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 16:22:08 +0000
Subject: [issue12840] "maintainer" value clear the "author" value when register
In-Reply-To: <1314256955.86.0.420020912731.issue12840@psf.upfronthosting.co.za>
Message-ID: <1314289328.77.0.89712080844.issue12840@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Is not simpler (to understand) to keep always the approach to keep both?
Well, there needs to be one point of contact.  If someone takes the responsibility to make a project available on PyPI without asking the author to do it themselves, then that someone is responsible for the PyPI distribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12840>
_______________________________________

From report at bugs.python.org  Thu Aug 25 18:35:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 16:35:47 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <E1Qwcu7-0002hA-0I@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c0ec01c95a73 by Antoine Pitrou in branch '3.2':
Issue #12333: fix test_distutils failures under Solaris and derivatives
http://hg.python.org/cpython/rev/c0ec01c95a73

New changeset 80f814dca274 by Antoine Pitrou in branch 'default':
Issue #12333: fix test_distutils failures under Solaris and derivatives
http://hg.python.org/cpython/rev/80f814dca274

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:05:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Aug 2011 17:05:17 +0000
Subject: [issue12333] test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1314291917.06.0.702313446281.issue12333@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
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/issue12333>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:05:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Aug 2011 17:05:56 +0000
Subject: [issue12333] test_distutils and test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1314291956.67.0.700256369978.issue12333@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for applying the same fix to test_distutils!

----------
title: test_packaging failures under Solaris -> test_distutils and test_packaging failures under Solaris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12333>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:16:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Aug 2011 17:16:25 +0000
Subject: [issue3329] API for setting the memory allocator used by Python
In-Reply-To: <1215632933.18.0.0332019532518.issue3329@psf.upfronthosting.co.za>
Message-ID: <1314292585.93.0.115163994224.issue3329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

All this needs is a patch.
Note that there are some places where we call malloc()/free() without going through our abstraction API. This is not in allocation-heavy paths, though.

----------
nosy: +pitrou
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3329>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:22:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 25 Aug 2011 17:22:16 +0000
Subject: [issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX
	sockets
In-Reply-To: <1311962409.81.0.679396198329.issue12656@psf.upfronthosting.co.za>
Message-ID: <1314292936.98.0.800443312805.issue12656@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12656>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:28:01 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 25 Aug 2011 17:28:01 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314293281.07.0.192116643154.issue6560@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> The OS X buildbots show some failures:

It seems to fail consistently on every OS X version.
I've had another look both at the code and the test, and couldn't find anything wrong with it.
Since there are a number of known bugs pertaining to FD passing on OS X - even on recent versions - I'd suggest to skip those tests on this platform.
As for sendto/sendmsg not being interrupted by the signal, I'd be curious to see if running test_socket alone solves the problem (just to make sure no other thread is running, which might receive the signal).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Thu Aug 25 19:30:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 25 Aug 2011 17:30:12 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314293412.3.0.459241364344.issue12386@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

?ric: I only meant that when writing data resources, one might reasonably use 'wb', but when writing scripts, which are text, 'w' is more appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Aug 25 20:17:50 2011
From: report at bugs.python.org (trevor)
Date: Thu, 25 Aug 2011 18:17:50 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314296270.81.0.685993911561.issue12386@psf.upfronthosting.co.za>


trevor <trevor at well.com> added the comment:

i see the same behavior - the error occurs leaving an empty RESOURCES file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Aug 25 20:34:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 25 Aug 2011 18:34:46 +0000
Subject: [issue5113] 2.5.4.3 / test_posix failing on HPUX systems
In-Reply-To: <1233346333.57.0.365853135308.issue5113@psf.upfronthosting.co.za>
Message-ID: <1314297286.53.0.0196570910665.issue5113@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Oooh, I'm confused. I removed this stupid patch.

chown_hpux-3.diff has a problem too: it skips the successful chown call (that's why I put the SkipTest at the end).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5113>
_______________________________________

From report at bugs.python.org  Thu Aug 25 20:42:46 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 25 Aug 2011 18:42:46 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314297766.54.0.643176820763.issue12386@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

BTW, IIRC I have fixed it in the pythonv branch.

https://bitbucket.org/vinay.sajip/pythonv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Thu Aug 25 21:19:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 19:19:45 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <E1QwfSq-0001Qn-57@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 498b03a55297 by Charles-Fran?ois Natali in branch '2.7':
Issue #12786: Set communication pipes used by subprocess.Popen CLOEXEC to avoid
http://hg.python.org/cpython/rev/498b03a55297

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Thu Aug 25 21:27:23 2011
From: report at bugs.python.org (Philipp Weinfurter)
Date: Thu, 25 Aug 2011 19:27:23 +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: <1314300443.71.0.254843111233.issue2259@psf.upfronthosting.co.za>


Changes by Philipp Weinfurter <wirrwuzzi at gmail.com>:


Removed file: http://bugs.python.org/file23045/chunk2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Thu Aug 25 21:34:10 2011
From: report at bugs.python.org (Philipp Weinfurter)
Date: Thu, 25 Aug 2011 19:34:10 +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: <1314300850.28.0.686522211617.issue2259@psf.upfronthosting.co.za>


Philipp Weinfurter <wirrwuzzi at gmail.com> added the comment:

Oops. Misread the code, that part of skip() is fine. Patch removed. Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2259>
_______________________________________

From report at bugs.python.org  Thu Aug 25 22:15:34 2011
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Thu, 25 Aug 2011 20:15:34 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1314303334.07.0.200199173687.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

eric,

if you recall there was some discussion that it was acceptable to use distutils but *only* for python 2.N (on the basis that its use is so well entrenched that it would be impossible to force python2.N applications to start using distutils2), and i agreed wholeheartedly with you that the expectation to use distutils2 would be reasonable for python3.N

just as an aside: have all python 3.N packaging scripts, for all python-dev scripts *and* all 3rd party packages world-wide, been using distutils2 by default instead of distutils?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Aug 25 22:17:26 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 25 Aug 2011 20:17:26 +0000
Subject: [issue12786] subprocess wait() hangs when stdin is closed
In-Reply-To: <1313771462.57.0.438793303014.issue12786@psf.upfronthosting.co.za>
Message-ID: <1314303446.54.0.963723488571.issue12786@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Patch committed.
Idan, thanks for the report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12786>
_______________________________________

From report at bugs.python.org  Thu Aug 25 22:31:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Aug 2011 20:31:25 +0000
Subject: [issue12842] Docs: first parameter of tp_richcompare() always has the
	correct type
Message-ID: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

I've noticed that assumptions about the operand types in tp_richcompare()
are not always consistent. As far as I can see, the first parameter
in tp_richcompare() is guaranteed to be of the correct type.

But in some places the first parameter's type is still checked:

Objects/cellobject.c:

    if (!PyCell_Check(a) || !PyCell_Check(b)) {


The attached patch makes it clear that the first parameter has
the correct type.

----------
assignee: docs at python
components: Documentation
files: tp_richcompare.diff
keywords: patch
messages: 142991
nosy: docs at python, skrah
priority: normal
severity: normal
status: open
title: Docs: first parameter of tp_richcompare() always has the correct type
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23047/tp_richcompare.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12842>
_______________________________________

From report at bugs.python.org  Thu Aug 25 23:09:19 2011
From: report at bugs.python.org (David Watson)
Date: Thu, 25 Aug 2011 21:09:19 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314224025.08.0.334496745114.issue12837@psf.upfronthosting.co.za>
Message-ID: <20110825210917.GA3939@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Wed 24 Aug 2011, Charles-Fran?ois Natali wrote:
> > I included this test deliberately, because msg_controllen may be 
> > of signed type [...] POSIX allows socklen_t to be signed
> 
> http://pubs.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html
> """
> <sys/socket.h> makes available a type, socklen_t, which is an unsigned opaque integral type of length of at least 32 bits. To forestall portability problems, it is recommended that applications should not use values larger than 2**32 - 1.
> """

That has since been changed.  I'm reading from POSIX.1-2008,
which says:

   The <sys/socket.h> header shall define the socklen_t type,
   which is an integer type of width of at least 32 bits

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html

The warning against using values larger than 2**32 - 1 is still
there, I presume because they would not fit in a 32-bit signed
int.

> Also, I'm not convinced by this:
> 
>    /* Check for empty ancillary data as old CMSG_FIRSTHDR()
>        implementations didn't do so. */
>     for (cmsgh = ((msg.msg_controllen > 0) ? CMSG_FIRSTHDR(&msg) : NULL);
>          cmsgh != NULL; cmsgh = CMSG_NXTHDR(&msg, cmsgh)) {
> 
> Did you really have reports of CMSG_NXTHDR not returning NULL upon empty ancillary data (it's also raquired by POSIX)?

I take it you mean CMSG_FIRSTHDR here; RFC 3542 says that:

   One possible implementation could be

      #define CMSG_FIRSTHDR(mhdr) \
          ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \
            (struct cmsghdr *)(mhdr)->msg_control : \
            (struct cmsghdr *)NULL )

   (Note: Most existing implementations do not test the value of
   msg_controllen, and just return the value of msg_control...

IIRC, I saw an implementation in old FreeBSD headers that did not
check msg_controllen, and hence did not return NULL as RFC 3542
requires.

Now you come to mention it though, this check in the for loop
does actually protect against the kernel returning a negative
msg_controllen, so the only remaining possibility would be that
the CMSG_* macros fiddle with it.

That said, the fact remains that the compiler warning is spurious
if msg_controllen can be signed on some systems, and I still
don't think decreasing the robustness of the code (particularly
against any future modifications to that code) just for the sake
of silencing a spurious warning is a good thing to do.  People
can read the comment above the "offending" line and see that the
compiler has got it wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Thu Aug 25 23:10:28 2011
From: report at bugs.python.org (David Watson)
Date: Thu, 25 Aug 2011 21:10:28 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314276217.44.0.0937144964658.issue12835@psf.upfronthosting.co.za>
Message-ID: <20110825211026.GB3939@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

On Thu 25 Aug 2011, Antoine Pitrou wrote:
> Adding an explanation message to the NotImplementedError would be more helpful. Otherwise, good catch.

OK, I've copied the messages from the ValueErrors the other
methods raise.

----------
Added file: http://bugs.python.org/file23048/ssl_sendrecvmsg_notimplemented-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________
-------------- next part --------------
# HG changeset patch
# User David Watson <vcs at dbwatson.ukfsn.org>
# Date 1314305189 -3600
# Node ID 23cdc358bbfb0ad40607b1c54bda2f7b5abe39f0
# Parent  80f814dca274b5d848dbd306c1513263e69011ce
Make SSLSocket.sendmsg/recvmsg/recvmsg_into() raise NotImplementedError.

diff --git a/Lib/ssl.py b/Lib/ssl.py
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@ -355,6 +355,12 @@ class SSLSocket(socket):
         else:
             return socket.sendto(self, data, flags_or_addr, addr)
 
+    def sendmsg(self, *args, **kwargs):
+        # Ensure programs don't send data unencrypted if they try to
+        # use this method.
+        raise NotImplementedError("sendmsg not allowed on instances of %s" %
+                                  self.__class__)
+
     def sendall(self, data, flags=0):
         self._checkClosed()
         if self._sslobj:
@@ -413,6 +419,14 @@ class SSLSocket(socket):
         else:
             return socket.recvfrom_into(self, buffer, nbytes, flags)
 
+    def recvmsg(self, *args, **kwargs):
+        raise NotImplementedError("recvmsg not allowed on instances of %s" %
+                                  self.__class__)
+
+    def recvmsg_into(self, *args, **kwargs):
+        raise NotImplementedError("recvmsg_into not allowed on instances of "
+                                  "%s" % self.__class__)
+
     def pending(self):
         self._checkClosed()
         if self._sslobj:
diff --git a/Lib/test/test_ssl.py b/Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py
+++ b/Lib/test/test_ssl.py
@@ -1651,6 +1651,11 @@ else:
                         # consume data
                         s.read()
 
+                self.assertRaises(NotImplementedError, s.sendmsg, [b"data"])
+                self.assertRaises(NotImplementedError, s.recvmsg, 100)
+                self.assertRaises(NotImplementedError,
+                                  s.recvmsg_into, bytearray(100))
+
                 s.write(b"over\n")
                 s.close()
             finally:

From report at bugs.python.org  Fri Aug 26 00:27:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Aug 2011 22:27:33 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <1314311253.9.0.0364241709035.issue12835@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ncoghlan
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Fri Aug 26 00:54:44 2011
From: report at bugs.python.org (Mads Kiilerich)
Date: Thu, 25 Aug 2011 22:54:44 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314312884.35.0.374042855648.issue12833@psf.upfronthosting.co.za>


Changes by Mads Kiilerich <mads at kiilerich.com>:


----------
nosy: +kiilerix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Fri Aug 26 01:09:03 2011
From: report at bugs.python.org (Otacon Karurosu)
Date: Thu, 25 Aug 2011 23:09:03 +0000
Subject: [issue12843] file object read* methods in append mode overflows
Message-ID: <1314313743.28.0.803214021161.issue12843@psf.upfronthosting.co.za>


New submission from Otacon Karurosu <otacon.karurosu at gmail.com>:

When opening a file in append mode and attempting to read after doing a write operation causes the read method to overflow and read memory directly (instead of returning an empty string)

The following code prints garbage:

f2 = open("test", "w+b")
f2.write("python!")
print f2.readline()

However the following print empty lines:

f2 = open("test", "w+b")
print f2.readline()

f2 = open("test", "w+b")
f2.write("python!")
f2.seek(f2.tell())
print f2.readline()

This also happens with tempfiles:

f = tempfile.TemporaryFile()
f.write("python!")
print f.readline()

----------
components: Interpreter Core, Library (Lib)
messages: 142994
nosy: Otacon.Karurosu
priority: normal
severity: normal
status: open
title: file object read* methods in append mode overflows
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12843>
_______________________________________

From report at bugs.python.org  Fri Aug 26 04:42:58 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Fri, 26 Aug 2011 02:42:58 +0000
Subject: [issue12844] Support more than 255 arguments
Message-ID: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

This feels like an arbitrary restriction (obvious sequences have been replaced with ??? to save space in this report):

>>> zip([0], [1], [2], ?, [1999])
  File "<stdin>", line 1
SyntaxError: more than 255 arguments

especially when this works:

>>> zip(*[[0], [1], [2], ?, [1999]])
[(0, 1, 2, ?, 1999)]

Apparently that limit bites some people:
https://docs.djangoproject.com/en/1.3/topics/http/urls/#module-django.conf.urls.defaults

The bytecode format doesn?t support directly calling a function with more than 255 arguments.  But, it should still be pretty easy to compile such function calls by desugaring
  f(arg0, ?, arg999, k0=v0, ?, k999=v999)
into
  f(*(arg0, ?, arg999), **{'k0': 'v0', ?, 'k999': 'v999'})

----------
components: Interpreter Core
messages: 142995
nosy: andersk
priority: normal
severity: normal
status: open
title: Support more than 255 arguments
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12844>
_______________________________________

From report at bugs.python.org  Fri Aug 26 04:56:53 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Fri, 26 Aug 2011 02:56:53 +0000
Subject: [issue12844] Support more than 255 arguments
In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>
Message-ID: <1314327413.55.0.669531913229.issue12844@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

I guess the desugaring is slightly more complicated in the case where the original function call already used *args or **kwargs:
  f(arg0, ?, arg999, *args, k0=v0, ?, k999=v999, **kwargs)
becomes something like
  f(*((arg0, ?, arg999) + args),
    **dict({'k0': 'v0', ?, 'k999': 'v999'}, **kwargs))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12844>
_______________________________________

From report at bugs.python.org  Fri Aug 26 05:02:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 26 Aug 2011 03:02:23 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1314327743.1.0.573214598203.issue11241@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This patch was marked as accepted, but it doesn't seem to be committed.  Will someone commit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Fri Aug 26 05:28:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Aug 2011 03:28:34 +0000
Subject: [issue12844] Support more than 255 arguments
In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>
Message-ID: <1314329314.23.0.0866885488484.issue12844@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

On python-dev a few month ago, Guido agreed with you that this is an arbitrary limitation that should be removed at some point.  In particular, he worried that programmatically generated code would tend to run into this limitation.

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12844>
_______________________________________

From report at bugs.python.org  Fri Aug 26 05:49:03 2011
From: report at bugs.python.org (Otacon Karurosu)
Date: Fri, 26 Aug 2011 03:49:03 +0000
Subject: [issue12843] file object read* methods in append mode overflows
In-Reply-To: <1314313743.28.0.803214021161.issue12843@psf.upfronthosting.co.za>
Message-ID: <1314330543.36.0.32847932315.issue12843@psf.upfronthosting.co.za>


Otacon Karurosu <otacon.karurosu at gmail.com> added the comment:

I have confirmed that this only happens in windows.

----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12843>
_______________________________________

From report at bugs.python.org  Fri Aug 26 06:54:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 26 Aug 2011 04:54:24 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <1314334464.39.0.118007113367.issue12835@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Antoine said, good catch. I'll be able to incorporate this in the next couple of days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Fri Aug 26 08:53:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 26 Aug 2011 06:53:18 +0000
Subject: [issue12831] 2to3 and integer division
In-Reply-To: <1314189064.26.0.312921037596.issue12831@psf.upfronthosting.co.za>
Message-ID: <1314341598.51.0.665494105251.issue12831@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> "/ 2" is an integer division, so it should be "// 3" in Python 3.

No, I don't think that's right: 2to3 has no way of knowing that the programmer intended an integer division here (self.maxstars could be a float).

Instead, you should always use '//' in Python 2 code where an integer division is intended.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12831>
_______________________________________

From report at bugs.python.org  Fri Aug 26 08:54:51 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 26 Aug 2011 06:54:51 +0000
Subject: [issue12831] 2to3 and integer division
In-Reply-To: <1314189064.26.0.312921037596.issue12831@psf.upfronthosting.co.za>
Message-ID: <1314341691.55.0.815774307921.issue12831@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12831>
_______________________________________

From report at bugs.python.org  Fri Aug 26 09:42:24 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 26 Aug 2011 07:42:24 +0000
Subject: [issue12844] Support more than 255 arguments
In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>
Message-ID: <1314344544.58.0.420474879357.issue12844@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The approach looks fine to me. Would you like to work on a patch?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12844>
_______________________________________

From report at bugs.python.org  Fri Aug 26 12:15:04 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Fri, 26 Aug 2011 10:15:04 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1314353704.24.0.734841272288.issue12808@psf.upfronthosting.co.za>


Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Here is a stab at updated documentation. I would suggest that if further changes are recommended to the documentation, that a core committer go ahead and make them. I'm absolutely more than happy to keep taking "stabs" at it, but ultimately I probably don't understand the purpose of these classes as well as some of the rest of you, and I don't feel best placed to decide exactly how this should read....

----------
Added file: http://bugs.python.org/file23049/codecs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Fri Aug 26 12:20:29 2011
From: report at bugs.python.org (=?utf-8?q?Alexander_R=C3=B8dseth?=)
Date: Fri, 26 Aug 2011 10:20:29 +0000
Subject: [issue12831] 2to3 and integer division
In-Reply-To: <1314189064.26.0.312921037596.issue12831@psf.upfronthosting.co.za>
Message-ID: <1314354029.81.0.304126223471.issue12831@psf.upfronthosting.co.za>


Alexander R?dseth <rodseth at gmail.com> added the comment:

Even though it's hard to cover every case, it should be possible in quite a few cases:

self.maxstars = 4
half = self.maxstars / 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12831>
_______________________________________

From report at bugs.python.org  Fri Aug 26 12:29:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Aug 2011 10:29:45 +0000
Subject: [issue12845] PEP-3118: C-contiguity with zero strides
Message-ID: <1314354585.27.0.717961402517.issue12845@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Numpy and PyBuffer_IsContiguous() have different ideas of
C-contiguity if there is a zero in strides (this is allowed,
I asked Pauli Virtanen).


>>> from numpy import *
>>> nd = ndarray(shape=[10], strides=[0])
>>> nd.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : True
  WRITEABLE : True
  ALIGNED : True
  UPDATEIFCOPY : False
>>> 
>>> from _testbuffer import ndarray as pyarray
>>> from _testbuffer import PyBUF_FULL_RO
>>> x = pyarray(nd, getbuf=PyBUF_FULL_RO)
>>> x.c_contiguous
False

----------
assignee: skrah
components: Interpreter Core
messages: 143005
nosy: skrah
priority: normal
severity: normal
status: open
title: PEP-3118: C-contiguity with zero strides
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12845>
_______________________________________

From report at bugs.python.org  Fri Aug 26 12:57:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Aug 2011 10:57:30 +0000
Subject: [issue12831] 2to3 and integer division
In-Reply-To: <1314189064.26.0.312921037596.issue12831@psf.upfronthosting.co.za>
Message-ID: <1314356250.09.0.415769556935.issue12831@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Running python with the -3 command line option will warn about Python 3.x incompatibilities that 2to3 cannot trivially fix.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12831>
_______________________________________

From report at bugs.python.org  Fri Aug 26 13:44:05 2011
From: report at bugs.python.org (John Chandler)
Date: Fri, 26 Aug 2011 11:44:05 +0000
Subject: [issue12820] Tests for Lib/xml/dom/minicompat.py
In-Reply-To: <1314071659.09.0.625804560965.issue12820@psf.upfronthosting.co.za>
Message-ID: <1314359045.32.0.92767564738.issue12820@psf.upfronthosting.co.za>


John Chandler <therealmetaljoe at gmail.com> added the comment:

Cool, thanks for the feedback! :-)

I'll make the appropriate changes to the tests and add some coverage for defproperty as soon as I can.

John

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12820>
_______________________________________

From report at bugs.python.org  Fri Aug 26 15:53:27 2011
From: report at bugs.python.org (Cem YILDIZ)
Date: Fri, 26 Aug 2011 13:53:27 +0000
Subject: [issue12846] unicodedata.normalize turkish letter problem
Message-ID: <1314366807.15.0.0695174585608.issue12846@psf.upfronthosting.co.za>


New submission from Cem YILDIZ <cem at fizy.com>:

unicodedata.normalize cannot convert turkish letter "?" into "i":


import unicodedata
s = u"?f?r?k?? a?a? ve ?sl?k?? ?e?me"
print(shoehorn_unicode_into_ascii(s))
print unicodedata.normalize('NFKD', s).encode('ascii','ignore')

>> ufurukcu agac ve slkc cesme

but the result should be
>> ufurukcu agac ve islikci cesme

----------
components: Unicode
messages: 143008
nosy: fizymania
priority: normal
severity: normal
status: open
title: unicodedata.normalize turkish letter problem
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12846>
_______________________________________

From report at bugs.python.org  Fri Aug 26 15:53:37 2011
From: report at bugs.python.org (Cem YILDIZ)
Date: Fri, 26 Aug 2011 13:53:37 +0000
Subject: [issue12846] unicodedata.normalize turkish letter problem
In-Reply-To: <1314366807.15.0.0695174585608.issue12846@psf.upfronthosting.co.za>
Message-ID: <1314366817.93.0.760366957253.issue12846@psf.upfronthosting.co.za>


Changes by Cem YILDIZ <cem at fizy.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12846>
_______________________________________

From report at bugs.python.org  Fri Aug 26 15:54:44 2011
From: report at bugs.python.org (Cem YILDIZ)
Date: Fri, 26 Aug 2011 13:54:44 +0000
Subject: [issue12846] unicodedata.normalize turkish letter problem
In-Reply-To: <1314366807.15.0.0695174585608.issue12846@psf.upfronthosting.co.za>
Message-ID: <1314366884.35.0.911794080726.issue12846@psf.upfronthosting.co.za>


Cem YILDIZ <cem at fizy.com> added the comment:

unicodedata.normalize cannot convert turkish letter "?" into "i":


import unicodedata
s = u"?f?r?k?? a?a? ve ?sl?k?? ?e?me"

print unicodedata.normalize('NFKD', s).encode('ascii','ignore')

>> ufurukcu agac ve slkc cesme

but the result should be
>> ufurukcu agac ve islikci cesme

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12846>
_______________________________________

From report at bugs.python.org  Fri Aug 26 16:32:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:32:43 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <E1QwxSU-0000Wu-9F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 96f0ccb9716d by ?ric Araujo in branch '3.2':
Fix type information in distutils API reference (#9302).
http://hg.python.org/cpython/rev/96f0ccb9716d

New changeset a410b857efe3 by ?ric Araujo in branch 'default':
Merge from 3.2 (#9302 fix and other changes)
http://hg.python.org/cpython/rev/a410b857efe3

New changeset 59b3f845f7a3 by ?ric Araujo in branch 'default':
Synchronize packaging docs with distutils? (includes fix for #9302)
http://hg.python.org/cpython/rev/59b3f845f7a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Fri Aug 26 16:37:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:37:35 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <E1QwxXJ-0000xU-NO@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 78b26e7720c0 by ?ric Araujo in branch '2.7':
Fix type information in distutils API reference (#9302).
http://hg.python.org/cpython/rev/78b26e7720c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Fri Aug 26 16:37:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:37:35 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <E1QwxXJ-0000xU-N0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 8ad1670c0f1f by ?ric Araujo in branch '2.7':
Try to fix test_distutils on Windows (#12678)
http://hg.python.org/cpython/rev/8ad1670c0f1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12678>
_______________________________________

From report at bugs.python.org  Fri Aug 26 16:39:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:39:51 +0000
Subject: [issue11360] In documentation of getopt,
	advertise argparse instead of optparse
In-Reply-To: <1298982503.08.0.830578820579.issue11360@psf.upfronthosting.co.za>
Message-ID: <E1QwxZW-00014Q-0g@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 40f7a6e71930 by ?ric Araujo in branch '3.2':
Remove outdated pointer to optparse (fixes #11360).
http://hg.python.org/cpython/rev/40f7a6e71930

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11360>
_______________________________________

From report at bugs.python.org  Fri Aug 26 16:42:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:42:02 +0000
Subject: [issue11360] In documentation of getopt,
	advertise argparse instead of optparse
In-Reply-To: <1298982503.08.0.830578820579.issue11360@psf.upfronthosting.co.za>
Message-ID: <E1Qwxbd-0001Nn-77@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6d3c645fa52f by ?ric Araujo in branch '2.7':
Remove outdated pointer to optparse (fixes #11360).
http://hg.python.org/cpython/rev/6d3c645fa52f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11360>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:15:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:15:35 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314371735.45.0.018412059081.issue12833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe you need to call sys.stdin.flush() before raw_input?

In any way, 2.6 is in security mode, so we need to reproduce this with current versions: 2.7, 3.2 or 3.3.

----------
components: +IO, Interpreter Core -Library (Lib)
nosy: +eric.araujo, pitrou
stage:  -> test needed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:16:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:16:10 +0000
Subject: [issue12842] Docs: first parameter of tp_richcompare() always has the
	correct type
In-Reply-To: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>
Message-ID: <1314371770.72.0.434696450345.issue12842@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
stage:  -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12842>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:20:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:20:46 +0000
Subject: [issue9302] distutils API Reference: setup() and Extension
	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1314372046.88.0.964481109162.issue9302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Improved and committed, thanks again!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9302>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:43:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:43:59 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1314373439.28.0.179585535358.issue12759@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can reproduce in 3.3 (the file has been moved to Tools/demo/redemo.py).  The Tk application does not crash but there is a traceback.  Would you like to work on a patch?  If so, there are good guidelines in the devguide.

----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
title: "(?P=)" input for Tools/scripts/redemo.py throw an exception -> "(?P=)" input for Tools/scripts/redemo.py raises unnhandled exception
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:47:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:47:09 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1314373629.89.0.0763459542442.issue12806@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Steven: What do you think?

GraylinKim: You can open a feature request for message preview on the metatracker (see ?Report Tracker Problem? in the sidebar).

----------
nosy: +bethard, eric.araujo
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12806>
_______________________________________

From report at bugs.python.org  Fri Aug 26 17:53:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:53:56 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314374036.5.0.165457405362.issue12768@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have made a review on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Fri Aug 26 18:14:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 16:14:55 +0000
Subject: [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1314375295.96.0.736419482038.issue12195@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/issue12195>
_______________________________________

From report at bugs.python.org  Fri Aug 26 18:47:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Aug 2011 16:47:45 +0000
Subject: [issue12742] Add support for CESU-8 encoding
In-Reply-To: <1313157699.02.0.414540020258.issue12742@psf.upfronthosting.co.za>
Message-ID: <1314377265.99.0.101539064488.issue12742@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you provide some example?
The page you linked says "It should be used exclusively for internal processing and never for external data exchange.", so I'm not sure why these APIs would want to use it.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12742>
_______________________________________

From report at bugs.python.org  Fri Aug 26 18:49:11 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Aug 2011 16:49:11 +0000
Subject: [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1314377351.18.0.963573194409.issue12195@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> some simple examples showing the syntax would go a long way.

Sorry, there as just too many ways to go and we are intentionally not stating which way is preferred.  I've seen many variants  a:[Integral] for a list of integers, a:(int,str) for a 2-tuple of an int and a string, a:(str,file,None) for something that is a string or a file or None, a:'light_years' to indicate units of measure, a:range_check(10.5, 20.1) for range validation, and some variants for converters, adapters, factory functions, documentation aids, etc.

If you want to advance the state of the art, perhaps write a blog post on what you consider to be a best practice.  If a consensus emerges, we 
will follow.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12195>
_______________________________________

From report at bugs.python.org  Fri Aug 26 19:14:51 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 26 Aug 2011 17:14:51 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314378891.58.0.254588144548.issue12768@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, yeah I received an email. Hopefully Graeme did too.

It's a shame a new review isn't notified in the tracker instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Fri Aug 26 20:38:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Aug 2011 18:38:35 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314383915.1.0.070012237821.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Brian, Tim, I'd feel more comfortable if any of you confirmed this isn't a stupid proposal on my part :)

----------
components: +Interpreter Core
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 20:57:07 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Aug 2011 18:57:07 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314385027.1.0.732806228285.issue12802@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I could see how they'd use EINVAL, but to me ENOTDIR makes more sense here. However, I'm not sure if anyone is depending on this (or what they could depend on it for).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 20:57:46 2011
From: report at bugs.python.org (Idan Kamara)
Date: Fri, 26 Aug 2011 18:57:46 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314385066.47.0.978810366805.issue12833@psf.upfronthosting.co.za>


Idan Kamara <idankk86 at gmail.com> added the comment:

Reproduced on 2.7.

(flushing stdin/out doesn't help)

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Fri Aug 26 21:01:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Aug 2011 19:01:18 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1314385027.1.0.732806228285.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314385133.3822.23.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I could see how they'd use EINVAL, but to me ENOTDIR makes more sense
> here. However, I'm not sure if anyone is depending on this (or what
> they could depend on it for).

Right now I'm not sure, but if PEP 3151 is accepted it will make much
more sense to get a NotADirectoryError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 21:04:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Aug 2011 19:04:48 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314385488.4.0.381399195664.issue12802@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

With that PEP likely to be accepted, I say go ahead with the change for that benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 21:17:35 2011
From: report at bugs.python.org (Tim Golden)
Date: Fri, 26 Aug 2011 19:17:35 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1314385027.1.0.732806228285.issue12802@psf.upfronthosting.co.za>
Message-ID: <4E57F13C.2010700@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Obviously someone's code would break if it were relying on the Unix 
errno only in a Windows-only situation to determine the situation of 
opening a directory which isn't one. But that combination of events 
doesn't seem terribly likely.

Speaking for myself, since the exception is a WindowsError with the 
winerror attribute prominent, [Error 267] I'd be far more likely to be 
trapping that.

I say go ahead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 21:40:41 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Aug 2011 19:40:41 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314387641.89.0.513638555136.issue12802@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Note that this file is not written by hand. It's generated by PC/generrmap.c, which uses the _dosmaperr() function provided by the msvcrt.

If we want to modify it, this should be clearly marked somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 21:46:51 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Aug 2011 19:46:51 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314388011.65.0.939467436048.issue12802@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If you have a copy of Visual Studio, you can see the code of _dosmaperr() in VC/crt/src/dosmap.c.
Otherwise the Google query "inurl:dosmap.c" returns some online copies of this file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Fri Aug 26 22:11:17 2011
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 26 Aug 2011 20:11:17 +0000
Subject: [issue9262] IDLE: Use tabbed shell and edit windows
In-Reply-To: <1279128709.53.0.879340925848.issue9262@psf.upfronthosting.co.za>
Message-ID: <1314389477.21.0.536959796028.issue9262@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Attached is an extension which provides tabbed windows for IDLE. It supports drag-and-drop reordering and separate windows. 

The implementation relies on monkey-patching a few subroutines and duck-typing for the toplevel window. The extension emulates each tab as if it were its own toplevel object. 

There can be flickering when switching tabs due to swapping the toplevel menu bar. This seems to be a limitation of Tk.

----------
Added file: http://bugs.python.org/file23050/TabExtension.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9262>
_______________________________________

From report at bugs.python.org  Fri Aug 26 22:55:26 2011
From: report at bugs.python.org (resc)
Date: Fri, 26 Aug 2011 20:55:26 +0000
Subject: [issue11913] sdist should allow for README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1314392126.31.0.559711711017.issue11913@psf.upfronthosting.co.za>


resc <thomathom at gmail.com> added the comment:

Just wanted to note that this confuses other people too...

http://stackoverflow.com/questions/4384796/readme-extension-for-python-projects

Is this something that could be changed in 'distribute'?

----------
nosy: +Thomas.Smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11913>
_______________________________________

From report at bugs.python.org  Fri Aug 26 22:58:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 20:58:45 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314392325.36.0.245807311379.issue12729@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Wow.  A very educational discussion.  We will be referencing this issue for many years to come.

As long as the buck stops with me, I feel strongly that *today* changing indexing from O(1) to O(log N) is a bad idea, partly for technical reasons, partly because the Python culture isn't ready.  In 5 or 10 years we need to revisit this, and it wouldn't hurt if in the mean time we started seriously thinking about how to change our APIs so that O(1) indexing is not relied upon so much.  This may include rewriting tutorials to nudge users in the direction of using different idioms for text processing.

In the meantime, I think our best option is to switch CPython to the PEP 393 string implementation.  Despite its disadvantages (I understand the "spoiler" issue) is is generally no worse than a wide build, and there is working code today that we can optimize before 3.3 is released.

For Python implementations where this is not an option (I'm thinking Jython and IronPython, both of which are closely tied to a system string type that behaves like UTF-16) I hope that at least the regular expression behavior can be fixed so that "." matches a surrogate pair.  (Possibly they already behave that way, if they use a native regex library.)

In all cases, for future Python versions, we should tighten the codecs to reject data that the Unicode standard considers invalid (and we should offer separate non-strict codecs for situations where such invalid data needs to be processed).

I wish we could fix the codecs and the regex "." issue on narrow builds for Python versions before 3.3 (esp. 3.2 and 2.7), but I fear that this is considered too backwards incompatible (though for each specific fix we should consider this carefully).

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:04:04 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:04:04 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
	data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1314392644.0.0.971823116704.issue12728@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This bug could do with a little less attitude.  That said, I think it is a bug and should be fixed, at the very least for Python 3.3.  As always, it is a matter of much debate to what extent bugs can be fixed in previous Python versions (specifically, 2.7 and 3.2) without breaking more code than it fixes, and I don't want to jump the gun on that issue.  Let's first see what it takes to fix this for 3.3.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12728>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:06:49 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:06:49 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1314392809.06.0.51617717341.issue12735@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Sounds like a fair feature request for Python 3.3, as long as the intention is that users must import some module from the standard library and use functions defined in that module.  The operations and methods defined for str instances (e.g. ==, <, etc.) should not change their behavior.

Is there an existing 3rd party library that we could adopt (even if it isn't perfect yet)?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:11:24 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:11:24 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314393084.09.0.900456558475.issue12736@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I presume this applies to builtin str methods like .lower(), right?  I think it is a good thing to do for Python 3.3.

We'd need to define what should happen in edge cases, e.g. when (against all odds) a string happens to contain a lone surrogate or some other code point or sequence of code points that the Unicode standard considers illegal.  I think it should not fail but just leave those code points alone.

Does this require us to import more data files from the Unicode standard?  By itself that doesn't scare me.

Would this also affect .islower() and friends?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:15:23 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:15:23 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1314393323.17.0.504391404872.issue12749@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

We should at least get this fixed in 3.3.  Then we can discuss the benefits of backporting the fixes to 2.7 and 3.2 (though it sounds to me like the backports will fix more than they will break, since it is pretty much impossible to do the right thing in those versions today).

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:16:57 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:16:57 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1314393417.26.0.121501061547.issue12737@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yeah, this should be fixed in 3.3 and probably backported to 3.2 and 2.7.  (There is already no guarantee that len(s) == len(s.title()), right?)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:18:06 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:18:06 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1314393486.03.0.739515880448.issue12746@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yeah, we should fix this.  At least in 3.3, but (without knowing what exactly is involved) I think backporting to 2.7 and 3.2 makes sense too.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12746>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:22:26 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:22:26 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314393746.74.0.995031164333.issue12731@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Really?  The re module cannot be salvaged and we should add regex but keep the (buggy) re?  That does not make a lot of sense to me.  I think it should just be fixed in the re module.  Or the re module should be *replaced* by the code from the regex module (but renamed to re, and with certain backwards compatibilities restored, probably).  But I really hope the re module (really: the _sre extension module) can be fixed.  We should also make a habit in our docs of citing specific versions of the Unicode standard, and specific TR numbers and versions where they apply.  (And hopefully we can supply URLs to the Unicode consortium's canonical copies of those documents.)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:23:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:23:45 +0000
Subject: [issue12733] Request for grapheme support in Python re lib
In-Reply-To: <1313092793.79.0.645060327577.issue12733@psf.upfronthosting.co.za>
Message-ID: <1314393825.58.0.263695315838.issue12733@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Again, I would be disappointed if the re (_sre) module could not be fixed.  It is a reasonable feature request.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12733>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:25:19 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:25:19 +0000
Subject: [issue12734] Request for property support in Python re lib
In-Reply-To: <1313093654.08.0.307115391635.issue12734@psf.upfronthosting.co.za>
Message-ID: <1314393919.49.0.557250049717.issue12734@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

+1 on adding the feature to 3.3 in whichever way makes sense.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12734>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:26:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:26:45 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1314394005.41.0.126180067181.issue12753@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

+1 on the feature request.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12753>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:51:47 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 21:51:47 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1314392809.06.0.51617717341.issue12735@psf.upfronthosting.co.za>
Message-ID: <11583.1314395501@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

> Sounds like a fair feature request for Python 3.3, as long as the
> intention is that users must import some module from the standard
> library and use functions defined in that module.  The operations and
> methods defined for str instances (e.g. ==, <, etc.) should not change
> their behavior.

> Is there an existing 3rd party library that we could adopt (even if it isn't perfect yet)?

I *think* you could use ICU's.  

I'm pretty sure the Parrot people use ICU libraries.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Fri Aug 26 23:55:03 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:55:03 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1314395703.06.0.476748543825.issue12735@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I know I sound like NIH, but I'm always reluctant to add a big 3rd party lib like ICU to the permanent dependencies of all future Python distros.  If people want to use ICU they already can.  OTOH I don't have a better idea. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Sat Aug 27 00:00:18 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 22:00:18 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1314393417.26.0.121501061547.issue12737@psf.upfronthosting.co.za>
Message-ID: <9986.1314396010@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Fri, 26 Aug 2011 21:16:57 -0000: 

> Yeah, this should be fixed in 3.3 and probably backported to 3.2
> and 2.7.  (There is already no guarantee that len(s) ==
> len(s.title()), right?)

Well, *I* don't know of any such guarantee, 
but I don't know Python very well.

In general, Unicode makes very few guarantees about casing.  Under full
casemapping, which is the only way to do the silly Turkish stuff amongst
quite a bit else, any of the three casemappings can change the length of
the string.

Other things you can't rely on are round tripping and "single paths".  By
roundtripping, just look at the two lowercase sigmas and think about how
you can't get back to one of them if you uppercase them both.  By single
paths, I mean that code that does some sort of conversion where it first
lowercases everything and then titlecases the first letter can produce
something different from titlecasing just the original first letter and
then lowercasing the rest of them.  That's because tc(x) and tc(lc(x)) can
be different.

--tom

----------
title: str.title()  is overzealous by upcasing combining marks inappropriately -> str.title() is overzealous by upcasing combining marks inappropriately

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12737>
_______________________________________

From report at bugs.python.org  Sat Aug 27 00:00:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Aug 2011 22:00:42 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1313093897.54.0.111250936422.issue12735@psf.upfronthosting.co.za>
Message-ID: <1314396042.37.0.820991766424.issue12735@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would like to be involved in the design of the API for a UCA module and its routines for loading Unicode Collation Element Tables (not making the mistake of using global state like the locale module does).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Sat Aug 27 00:21:09 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 22:21:09 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1314396042.37.0.820991766424.issue12735@psf.upfronthosting.co.za>
Message-ID: <5347.1314397261@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I would like to be involved in the design of the API for a UCA module
> and its routines for loading Unicode Collation Element Tables (not
> making the mistake of using global state like the locale module does).

Is this the problem where a locale is global to a process (or thread)?

The way I'm used to using the UCA module in Perl, that's never a problem,
because it's completely object-oriented.  There's no global state.  You 
instantiate a collator object with all the state it needs, like

    collation_level
    upper_before_lower
    backwards_levels
    normalization
    override_CJK
    override_Hangul
    katakana_before_hiragana
    variable
    locale
    preprocess

And then you use that object for all your collation needs, including
not just sorting but also string comparison and even searches.

For example, you could instantiate a first collator object with its level
set to one, meaning just compare base alphanumerics not diacritics or case
or nonletters, and a second with the defaults so that it uses all four
levels or a different normalization.  I have on occasion had more than one
collator object around at once each with its own locale, like if I want to
compare different locales' comparisons.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Sat Aug 27 00:28:44 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 22:28:44 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <5347.1314397261@chthon>
Message-ID: <24872.1314397708@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

I should probably mention the importance in the design of a UCA module of
being able to specify which UCA version number you want it to behave like
in case you plan to override some of the DUCET entries.  That way if you
run under a later UCA with different DUCET weights, your own tailorings will
still make sense.  If you don't do this, your collation tailorings can break 
in a new release of the UCA.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Sat Aug 27 00:31:44 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 22:31:44 +0000
Subject: [issue12735] request full Unicode collation support in std python
	library
In-Reply-To: <1314395703.06.0.476748543825.issue12735@psf.upfronthosting.co.za>
Message-ID: <15556.1314396695@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Fri, 26 Aug 2011 21:55:03 -0000: 

> I know I sound like NIH, but I'm always reluctant to add a big 3rd
> party lib like ICU to the permanent dependencies of all future Python
> distros.  If people want to use ICU they already can.  OTOH I don't
> have a better idea. :-(

I know exactly what you mean.  I would not want to push that on anyone,
being dependent on a gigantic 3rd-party module.  I just tried to answer
the question.  The only two full UCA implementations I know of are ICU's
and Perl's, which does not use ICU (since we're UTF-8, etc).

I just wish Python had Unicode collation, is all.

--tom

PS: (I haven't had good luck the ICU bindings in 3.2.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12735>
_______________________________________

From report at bugs.python.org  Sat Aug 27 01:36:21 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 23:36:21 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314393084.09.0.900456558475.issue12736@psf.upfronthosting.co.za>
Message-ID: <19158.1314401763@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Fri, 26 Aug 2011 21:11:24 -0000: 

> Guido van Rossum <guido at python.org> added the comment:

> I presume this applies to builtin str methods like .lower(), right?  I
> think it is a good thing to do for Python 3.3.

Yes, the full casemaps are for upper, title, and lowercase.  There is 
also a full casefold and turkic case fold (which is full), but you
don't have a casefold function so I guess that doesn't matter.

> We'd need to define what should happen in edge cases, e.g. when
> (against all odds) a string happens to contain a lone surrogate or
> some other code point or sequence of code points that the Unicode
> standard considers illegal.  I think it should not fail but just leave
> those code points alone.

Well, it's a funny thing.  There are properties given for all
Unicode code points, even noncharacter code points.  This
includes the casing properties, oddly enough.

>From UnicodeData.txt, which has a few surrogate entries; notice
no casing is given:

    D800;<Non Private Use High Surrogate, First>;Cs;0;L;;;;;N;;;;;
    DB7F;<Non Private Use High Surrogate, Last>;Cs;0;L;;;;;N;;;;;
    DB80;<Private Use High Surrogate, First>;Cs;0;L;;;;;N;;;;;
    DBFF;<Private Use High Surrogate, Last>;Cs;0;L;;;;;N;;;;;
    DC00;<Low Surrogate, First>;Cs;0;L;;;;;N;;;;;
    DFFF;<Low Surrogate, Last>;Cs;0;L;;;;;N;;;;;

And in SpecialCasing.txt, which does not have surrogates but does have
a default clause:

    # This file is a supplement to the UnicodeData file.
    # It contains additional information about the casing of Unicode characters.
    # (For compatibility, the UnicodeData.txt file only contains case mappings for
    # characters where they are 1-1, and independent of context and language.
    # For more information, see the discussion of Case Mappings in the Unicode Standard.
    #
    # All code points not listed in this file that do not have a simple case mappings
    # in UnicodeData.txt map to themselves.

And in CaseFolding.txt, which also does not have surrogates but again does 
have a default clause:

    # The data supports both implementations that require simple case foldings
    # (where string lengths don't change), and implementations that allow full case folding
    # (where string lengths may grow). Note that where they can be supported, the
    # full case foldings are superior: for example, they allow "MASSE" and "Ma?e" to match.
    #
    # All code points not listed in this file map to themselves.

Taken all together, it follows that the surrogates have case{map,fold}s
back to themselves, since they have no case{map,fold}s listed.

It's ok to have arbitrary code points in memory, including surrogates and
the 66 noncharacters.  It just isn't legal to have them in a UTF stream
for "open interchange", whatever that means.  

> Does this require us to import more data files from the Unicode
> standard?  By itself that doesn't scare me.

One way or the other, yes, notably the SpecialCasing file for
casemapping and the CaseFolding file for casefolding (which you
should do anyway to fix re.I).  But you can and should process the
new files into some tighter format optimized for your own lookups.

Oddly, Java doesn't provide for String methods that do full casing on
titlecase, even those they do do so on lowercase and uppercase.  On
titlecase they only expose the simple casemaps via the Character class,
which are the ones from UnicodeData.  They recognize that this is flaw, 
but it was too late to fix it for JAva 7.

> Would this also affect .islower() and friends?

Well, it shouldn't, but .islower() and friends are already mistaken.
They seem to be checking for GC=Ll and such, but they need to be
checking the Unicode binary property Lowercase and such.  Watch:

    test 37 for string ?
    wanted <?> to be lowercase of <?> but python disagrees
    wanted <?> to be titlecase of <?> but python disagrees
    wanted <?> to be uppercase of <?> but python disagrees
    test 37 failed 3 subtests

    test 39 for string ?
    wanted <?> to be lowercase of <?> but python disagrees
    wanted <?> to be titlecase of <?> but python disagrees
    wanted <?> to be uppercase of <?> but python disagrees
    test 39 failed 3 subtests

That's because the Roman numerals are GC=Nl but still have
case and change case.  Similarly for the circled letters which
are GC=So but have case and change case.  Plus there's U+0345,
the iota subscript, which is GC=Mn but has case and changes case.

I don't remember whether I've sent in my full test suite or not.  
If I haven't yet, I should attach it to the bug report.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 01:55:59 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 26 Aug 2011 23:55:59 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314402959.4.0.843868673166.issue12736@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Here?s my casing test suite; I thought I sent it in but the mux file here isn?t the full thing.

 It does several things, including letting you run it with regex vs re.  It also checks for the islower, etc functions. It has both simple and full (and turkic) maps and folds in it, but is configured to only check the simple versions for now.  The islower and isupper etc functions seem to be checking the wrong Unicode property.

Yes, it has my quaint Unixisms in it, because it needs to run with UTF-8 output, or you can't read what's going on.

----------
Added file: http://bugs.python.org/file23051/casing-tests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 04:33:56 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 27 Aug 2011 02:33:56 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314412436.38.0.968547268958.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

I wasn't aware this is an auto-generated file. I can add a comment but looking at it, it seems we auto-generate this file just to save a call to _dosmaperr. I would refactor the whole function to call _dosmaperr first then if result is still EINVAL, tweak with custom switch case. The way I see it, this looks like premature optimization since OS error shouldn't be on a hot code path, meaning an application should be able to live with an extra CRT function call on such exceptions. I'm willing to implement this if  there are no objections. Something like:

errno = _dosmaperr(err)
if (EINVAL == errno)
{
    switch (err)
    {
    // Our tweaks
    }
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 05:12:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Aug 2011 03:12:33 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314414753.58.0.189637808515.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My proposal is better than log(N) in 2 respects.

1) There need only be a time penalty when there are non-BMP chars and indexing currently gives the 'wrong' answer and therefore when a time-penalty should be acceptable. Lookup for normal all-BMP strings could remain the same.

2) The penalty is log(K), where K in the number of non-BMP chars. In theory, O(logK) is as 'bad' as O(logN), for any fixed ratio K/N. In practice, the difference should be noticeable when there are just a few (say .01%) extended-range chars.

I am aware that this is an idea for the future, not now.
---

Fixing string iteration on narrow builds to produce code points the same
as with wide builds is easy and costs O(1) per code point (character), which is the same as the current cost. Then

>>> from unicodedata import name
>>> name('\U0001043c')
'DESERET SMALL LETTER DEE'
>>> for c in 'a\U0001043c': name(c)
'LATIN SMALL LETTER A'
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    for c in 'a\U0001043c': name(c)
ValueError: no such name

would work like it does on wide builds instead of failing.

I admit that it would be strange to have default iteration produce different items than default indexing (and indeed, str currently iterates by sequential indexing). But keeping them in sync means that buggy iteration is another cost of O(1) indexing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 27 05:26:21 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 27 Aug 2011 03:26:21 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1314414753.58.0.189637808515.issue12729@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLTw8Ya0hJzfcZLNqJ3p3wGF68k2rPzaR5D_dKae6XEVw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

To me, making (default) iteration deviate from indexing is anathema.

However, there is nothing wrong with providing a library function that
takes a string and returns an iterator that iterates over code points,
joining surrogate pairs as needed. You could even have one that
iterates over characters (I think Tom calls them graphemes), if that
is well-defined and useful.

----------
title: Python lib re cannot handle Unicode properly due to	narrow/wide bug -> Python lib re cannot handle Unicode properly due to narrow/wide bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 27 06:09:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Aug 2011 04:09:03 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314418143.77.0.53884426718.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PEP-393 will take care of iterating by code points.
Where would you have other iterators go? The string module?
Something else I have not thought of? Or something new?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 27 09:00:40 2011
From: report at bugs.python.org (Graeme Cross)
Date: Sat, 27 Aug 2011 07:00:40 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314428440.66.0.767927091206.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

I will check that the patch works with 3.2; if not, I'll redo the patch for 3.2.
I will also incorporate the review changes from Ezio and Eric.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Sat Aug 27 12:45:48 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 27 Aug 2011 10:45:48 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314441948.09.0.584796165232.issue12833@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Reproduced on 3.3 head. Looking at the documentation of the C readline
library, it needs to know the length of the prompt in order to display
properly, so this seems to be an acknowledged limitation of the underlying
library rather than a bug on our side.

Still, this behavior is surprising and undesirable. I would suggest adding
a note to the docs for the readline module, directing users to write:

    input("foo> ")

instead of:

    sys.stdout.write("foo> ")
    input()

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Sat Aug 27 13:03:08 2011
From: report at bugs.python.org (Idan Kamara)
Date: Sat, 27 Aug 2011 11:03:08 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314442988.49.0.984048460309.issue12833@psf.upfronthosting.co.za>


Idan Kamara <idankk86 at gmail.com> added the comment:

You're right, as this little C program verifies:

#include <stdio.h>
#include <stdlib.h>
#include <readline/readline.h>

int main() {
   printf("foo ");
   char* buf = readline("");
   free(buf);

   return 0;
}

Passing ' ' seems to be a suitable workaround for those who can't pass the text directly to raw_input though (such is the case where you have special classes who handle output).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Sat Aug 27 13:11:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 27 Aug 2011 11:11:27 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314443487.67.0.459514995004.issue12802@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Unfortunately, it won't work. _dosmaperr() is not exported by msvcrt.dll, it is only available when you link against the static version of the C runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 13:51:49 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 27 Aug 2011 11:51:49 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <CAP7+vJLTw8Ya0hJzfcZLNqJ3p3wGF68k2rPzaR5D_dKae6XEVw@mail.gmail.com>
Message-ID: <26480.1314445868@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Sat, 27 Aug 2011 03:26:21 -0000: 

> To me, making (default) iteration deviate from indexing is anathema.

So long is there's a way to interate through a string some other way
that by code unit, that's fine.  However, the Java way of 16-bit code
units is so annoying because there often aren't code point APIs, and 
so you get a lot of niggling errors creeping in.  This is part of why
I strongly prefer wide builds, so that code point and code unit are the
same thing again.

> However, there is nothing wrong with providing a library function that
> takes a string and returns an iterator that iterates over code points,
> joining surrogate pairs as needed. You could even have one that
> iterates over characters (I think Tom calls them graphemes), if that
> is well-defined and useful.

"Character" can sometimes be a confusing term when it means something
different to us programmers as it does to users.  Code point to mean the
integer is a lot clearer to us but to no one else.  At work I often just
give in and go along with the crowd and say character for the number that
sits in a char or wchar_t or Character variable, even though of course
that's a code point.  I only rebel when they start calling code units 
characters, which (inexperienced) Java people tend to do, because that
leads to surrogate splitting and related errors.

By grapheme I mean something the user perceives as a single character.  In
full Unicodese, this is an extended grapheme cluster.  These are code point
sequences that start with a grapheme base and have zero or more grapheme
extenders following it.  For our purposes, that's *mostly* like saying you
have a non-Mark followed by any number of Mark code points, the main
excepting being that a CR followed by a LF also counts as a single grapheme
in Unicode.

If you are in an editor and wanted to swap two "characters", the one 
under the user's cursor and the one next to it, you have to deal with
graphemes not individual code points, or else you'd get the wrong answer.
Imagine swapping the last two characters of the first string below,
or the first two characters of second one:

    contr?l?e    contro\x{302}le\x{301}e
    ?l?ve        e\x{301}le\x{300}ve        

While you can sometimes fake a correct answer by considering things
in NFC not NFD, that's doesn't work in the general case, as there
are only a few compatibility glyphs for round-tripping for legacy
encodings (like ISO 8859-1) compared with infinitely many combinations
of combining marks.  Particularly in mathematics and in phonetics, 
you often end up using marks on characters for which no pre-combined
variant glyph exists.  Here's the IPA for a couple of Spanish words
with their tight (phonetic, not phonemic) transcriptions:

        an?cdota    [a??ne?????o?t?a?]
        rinc?n      [r???k??n]

    NFD:
        ane\x{301}cdota    [a\x{320}\x{2C8}ne\x{31E}\x{263}\x{31E}\x{F0}\x{31E}o\x{31E}t\x{32A}a\x{320}]
        rinco\x{301}n      [ri\x{303}\x{14B}\x{2C8}ko\x{31E}\x{303}n]

    NFD:
        an\x{E9}cdota    [a\x{320}\x{2C8}ne\x{31E}\x{263}\x{31E}\x{F0}\x{31E}o\x{31E}t\x{32A}a\x{320}]
        rinc\x{F3}n      [r\x{129}\x{14B}\x{2C8}k\x{F5}\x{31E}n]

So combining marks don't "just go away" in NFC, and you really do have to
deal with them.  Notice that to get the tabs right (your favorite subject :),
you have to deal with print widths, which is another place that you get
into trouble if you only count code points.

BTW, did you know that the stress mark used in the phonetics above
is actually a (modifier) letter in Unicode, not punctuation?

    # uniprops -a 2c8
    U+02C8 ??? \N{MODIFIER LETTER VERTICAL LINE}
        \w \pL \p{L_} \p{Lm}
    All Any Alnum Alpha Alphabetic Assigned InSpacingModifierLetters Case_Ignorable CI Common Zyyy Dia Diacritic L Lm Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Modifier_Letter Print Spacing_Modifier_Letters Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Word
    Age=1.1 Bidi_Class=ON Bidi_Class=Other_Neutral BC=ON Block=Spacing_Modifier_Letters Canonical_Combining_Class=0 Canonical_Combining_Class=Not_Reordered CCC=NR Canonical_Combining_Class=NR Script=Common Decomposition_Type=None DT=None East_Asian_Width=Neutral Grapheme_Cluster_Break=Other GCB=XX Grapheme_Cluster_Break=XX Hangul_Syllable_Type=NA Hangul_Syllable_Type=Not_Applicable HST=NA Joining_Group=No_Joining_Group JG=NoJoiningGroup Joining_Type=Non_Joining JT=U Joining_Type=U Line_Break=BB Line_Break=Break_Before LB=BB Numeric_Type=None NT=None Numeric_Value=NaN NV=NaN Present_In=1.1 IN=1.1 Present_In=2.0 IN=2.0 Present_In=2.1 IN=2.1 Present_In=3.0 IN=3.0 Present_In=3.1 IN=3.1 Present_In=3.2 IN=3.2 Present_In=4.0 IN=4.0 Present_In=4.1 IN=4.1 Present_In=5.0 IN=5.0 Present_In=5.1 IN=5.1 Present_In=5.2 IN=5.2 Present_In=6.0 IN=6.0 SC=Zyyy Script=Zyyy Sentence_Break=LE Sentence_Break=OLetter SB=LE Word_Break=ALetter WB=LE Word_Break=LE _Case_Ignorable _X_Begin

That means those would all be matched by \w+, as unlike \p{alpha},
\p{word} includes not just \pL etc but also all the combining marks.
That's how you want it to work, although I think you have to use
regex not re in Python to get that.

Iterating by grapheme is easy in a regex engine that supports \X.
Instead of using "." to match a code point, you use a \X to match
a grapheme.  So the swapping problem goes away, and many others.
To capture a pair of graphemes for swapping you'd use (\X)(\X), and
to grab the first 6 graphemes without breaking them up you'd use \X{6}.
That means to interate by grpaheme you just split up your string one
\X at a time.

Here's a real-world example:

In the vim editor, when you're editing UTF-8 as I am this mail message,
because it is all about user-perceived characters, they actually use "." to
match an entire grapheme.  This is different form th eayw perl and
everybody else uses "." for a code point, not a grapheme.  If I did s/^.//
or s/.$// in vim, I would need s/^\X// or s/\X$// for in perl.  Similarly,
to swap "characters" with the "xp" command, it will grab the entire \X.
Put some of those phonetic transcriptions above into a vim buffer and play
with them to see what I mean.

Imagine using a format like "%-6.6s" on "contr?l?e": that should produce
"contr?" not "contro".  That's because code points with the property
Bidi_Class=Non_Spacing_Mark (BC=NSM) do not advance the cursor, they just
stack up.

It gets even worse in that some code points advance the cursor by two
not by zero or one.  These include those with the East_Asian_Width
property value Full or Wide.  And they aren't always Asian characters,
either.  For example, these code points all have the EA=W property, so
take up to print columns:

     ?  U+2329 LEFT-POINTING ANGLE BRACKET
     ?  U+232A RIGHT-POINTING ANGLE BRACKET
     ?  U+3003 DITTO MARK
     ?  U+301C WAVE DASH
     ?  U+301D REVERSED DOUBLE PRIME QUOTATION MARK
     ?  U+301E DOUBLE PRIME QUOTATION MARK
     ?  U+301F LOW DOUBLE PRIME QUOTATION MARK

Perl's built-in string indexing, and hence its substrings, is strictly 
by code point and not by grapheme.  This is really frustrating at times,
because something like this screws up:

    printf "%-6.6", "contr?l?e";
    printf "%-6.6", "a??ne?????o?t?a?";

Logically, those should produce "contr?" and "a??ne?????", but of course
when considering only code points, they won't.  Well, not unless the 
1st is in NFC, but there's no hope for the second.

Perl does have a grapheme cluster string class which provides a way 
to figure out the columns and also allows for substring operation by
grapheme. But it is not at all integrated into anything, which makes 
it tedious to use.

    use Unicode::GCString;  # on CPAN only, not yet in core

    my $string   = "a??ne?????o?t?a?";
    my $gcstring = Unicode::GCString->new($string);
    my $colwidth = $gcstring->columns;
    if ($colwidth > 6) {
        print $gcstring->substr(0,6);
    } else {
        print " " x (6 - $colwidth);
        print $gcstring;
    }

Isn't that simply horrible?  You *will* get the right answer that way, but
what a pain!  Really, there needs to be a way for the built-in formatters
to understand graphemes.  But first, I think, you have to have the regex
engine understand them.  Matthew's regex does, because it supports \X.

There's a lot more to dealing with Unicode text than just extending the
character repertoire.  How much should fundamental to the language and how
much should be relegated to modules isn't always clear.  I do know I've had
to rewrite a *lot* of standard Unix tools to deal with Unicode properly.
For the wc(1) rewrite I only needed to consider graphemes with \X and 
Unicode line break sequences with \R, but other tools need better smarts.
For example, just getting the fmt(1) rewrite to wrap lines in paragraphs 
correctly requires understanding not just graphemes but the Unicode 
Linebreak Algorithm, which in turn relies upon understanding the print
widths for grapheme cluster strings and East Asian wide or full characters.

It's something you only want to do once and never think about again. :(

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sat Aug 27 14:01:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 12:01:04 +0000
Subject: [issue12847] crash with negative PUT in pickle
Message-ID: <1314446464.92.0.317073620599.issue12847@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This doesn't happen on 2.x cPickle, where PUT keys are simply treated as strings.

>>> import pickle, pickletools
>>> s = b'Va\np-1\n.'
>>> pickletools.dis(s)
    0: V    UNICODE    'a'
    3: p    PUT        -1
    7: .    STOP
highest protocol among opcodes = 0
>>> pickle.loads(s)   
Erreur de segmentation

----------
messages: 143062
nosy: pitrou
priority: normal
severity: normal
status: open
title: crash with negative PUT in pickle
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12847>
_______________________________________

From report at bugs.python.org  Sat Aug 27 14:05:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 12:05:47 +0000
Subject: [issue12847] crash with negative PUT in pickle
In-Reply-To: <1314446464.92.0.317073620599.issue12847@psf.upfronthosting.co.za>
Message-ID: <1314446747.24.0.0265285645067.issue12847@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Same with LONG_BINPUT on a 32-bit build:

>>> s = b'\x80\x03X\x01\x00\x00\x00ar\xff\xff\xff\xff.'
>>> pickletools.dis(s)
    0: \x80 PROTO      3
    2: X    BINUNICODE 'a'
    8: r    LONG_BINPUT -1
   13: .    STOP
highest protocol among opcodes = 2
>>> pickle.loads(s)
Erreur de segmentation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12847>
_______________________________________

From report at bugs.python.org  Sat Aug 27 14:56:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 12:56:14 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314449774.42.0.10802995495.issue11564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch against 3.2. I can't say it works for sure, but it should be much better. It also adds a couple more tests.
There seems to be a separate issue where pure-Python pickle.py considers 32-bit lengths signed where the C impl considers them unsigned...

----------
Added file: http://bugs.python.org/file23052/pickle64-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Sat Aug 27 14:59:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 12:59:53 +0000
Subject: [issue12848] pickle.py treats 32bit lengths as signed,
	but _pickle.c as unsigned
Message-ID: <1314449993.09.0.0217958770024.issue12848@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In several opcodes (BINBYTES, BINUNICODE... what else?), _pickle.c happily accepts 32-bit lengths of more than 2**31, while pickle.py uses marshal's "i" typecode which means "signed"... and therefore fails reading the data.
Apparently, pickle.py uses marshal for speed reasons, but marshal doesn't support unsigned types.

(seen from http://bugs.python.org/issue11564)

----------
components: Library (Lib)
messages: 143065
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: pickle.py treats 32bit lengths as signed, but _pickle.c as unsigned
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12848>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:00:38 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 27 Aug 2011 14:00:38 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <E1QxJR7-0004JS-92@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b06f011a3529 by Nick Coghlan in branch 'default':
Fix #12835: prevent use of the unencrypted sendmsg/recvmsg APIs on SSL wrapped sockets (Patch by David Watson)
http://hg.python.org/cpython/rev/b06f011a3529

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:02:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Aug 2011 14:02:57 +0000
Subject: [issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to
	send unencrypted data by mistake
In-Reply-To: <1314213094.03.0.301914337294.issue12835@psf.upfronthosting.co.za>
Message-ID: <1314453777.62.0.703485927452.issue12835@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12835>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:17:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 27 Aug 2011 14:17:45 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <E1QxJhf-0005CR-UK@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 7b83d2c1aad9 by Nick Coghlan in branch 'default':
Fix #9923: mailcap now uses the OS path separator for the MAILCAP envvar. Not backported, since it could break cases where people worked around the old POSIX-specific behaviour on non-POSIX platforms.
http://hg.python.org/cpython/rev/7b83d2c1aad9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:27:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 14:27:35 +0000
Subject: [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1314455255.67.0.948973815229.issue12174@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Although the reference docs don't list the numeric values of logging levels, this happened during reorganising of the docs. The table has moved to the HOWTO:

http://docs.python.org/howto/logging.html#logging-levels

That said, I don't understand the need for special logging levels in the multiprocessing package. From the section following the one linked to above:

"Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly *a very bad idea to define custom levels if you are developing a library*. That?s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries."

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12174>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:32:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Aug 2011 14:32:07 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1314455527.48.0.552578211672.issue9923@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As noted in the commit message, I didn't backport this, since it didn't seem worth risking breaking even the unlikely case that someone actually *was* using the MAILCAP environment variable on Windows.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9923>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:38:30 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 27 Aug 2011 14:38:30 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314455910.97.0.893142194281.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Oh, got it. Interesting. Then should I just add a comment somewhere or should we resolve this as Won't Fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:42:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 14:42:28 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314456148.25.0.819664934937.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could add a special case to generrmap.c (but how can I compile and execute this file? it doesn't seem to be part of the project files).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:48:39 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 27 Aug 2011 14:48:39 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314393084.09.0.900456558475.issue12736@psf.upfronthosting.co.za>
Message-ID: <30133.1314456489@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Fri, 26 Aug 2011 21:11:24 -0000: 

> Would this also affect .islower() and friends?

SHORT VERSION:  (7 lines)

    I don't believe so, but the relationship between lower() and islower()
    is not as clear to me as I would have thought, and more importantly,
    the code and the documentation for Python's islower() etc currently seem
    to disagree.  For future releases, I recommend fixing the code, but if
    compatibility is an issue, then perhaps for previous releases still in
    maintenance mode fixing only the documentation would possibly be good
    enough--your call.

=======================================================================

MEDIUM VERSION: (87 lines)

I was initially confused with Python's islower() family because of the way
they are defined to operate on full strings.  They don't check that
everything is lowercase even though they say they do.

 <  http://docs.python.org/py3k/library/stdtypes.html#sequence-types-str-bytes-bytearray-list-tuple-range

    str.lower()

        Return a copy of the string with all the cased characters [4]
        converted to lowercase.

    str.islower()

        Return true if all cased characters [4] in the string are lowercase 
        and there is at least one cased character, false otherwise.

    [4] (1, 2, 3, 4) Cased characters are those with general category
        property being one of ?Lu? (Letter, uppercase), ?Ll? (Letter,
        lowercase), or ?Lt? (Letter, titlecase).

This is strange in several ways.  Of lesser importance is that
strings can be considered lowercase even if they don't match

    ^\p{lowercase}+$

Another is that the result of calling str.lower() may not be .islower().
I'm not sure what these are particularly for, since I myself would just use
a regex to get finer-grained control.  (I suppose that's because re doesn't
give access to the Unicode properties needed that this approach never
gained any traction in the Python community.)

However, the worst of this is that the documentation defines both cased
characters and lowercase characters *differently* from how Unicode does
defines those very same terms.  This was quite confusing.

Unicode distinguishes Cased code points from Cased_*Letter* code points.
Python is using the Cased_Letter property but calling it Cased.  Cased in 
a proper superset of Cased_Letter.  From the DerivedCoreProperties file in
the Unicode Character Database:

    # Derived Property:   Cased (Cased)
    #  As defined by Unicode Standard Definition D120
    #  C has the Lowercase or Uppercase property or has a General_Category value of Titlecase_Letter.

In the same way, the Lowercase and Uppercase properties are not the same as
the Lowercase_*Letter* and Uppercase_*Letter* properties.  Rather, the former
are respectively proper supersets of the latter.  

    # Derived Property: Lowercase
    #  Generated from: Ll + Other_Lowercase

    [...]

    # Derived Property: Uppercase
    #  Generated from: Lu + Other_Uppercase

In all these, you almost always want the superset versions not the
restricted subset versions you are using.  If it were in the regex engine,
the user could select either.

Java used to miss all these, too.  But in 1.7, they updated their character
methods to use the properties that they'd all along said they were using:

  < http://download.oracle.com/javase/7/docs/api/java/lang/Character.html#isLowerCase(char)

    public static boolean isLowerCase(char ch)
    Determines if the specified character is a lowercase character. 

     A character is lowercase if its general category type, provided by
     Character.getType(ch), is LOWERCASE_LETTER, or it has contributory
->   property Other_Lowercase as defined by the Unicode Standard.

    Note: This method cannot handle supplementary characters.  To
          support all Unicode characters, including supplementary
          characters, use the isLowerCase(int) method.

(And yes, that's where Java uses "character" to mean "code unit" 
 not "code point", alas.  No wonder people get confused)

I'm pretty sure that Python needs to either update its documentation to
match its code, update its code to match its documentation, or both.  Java
chose to update the code to match the documentation, and this is the course
I would recommend if at all possible.  If you say you are checking for
cased code points, then you should use the Unicode definition of cased code
points not your own, and if you say you are checking for lowercase code
points, then you should use the Unicode definition not your own.  Both of
these require access to contributory properties from the UCD and not 
just general categories alone.

--tom

=======================================================================

LONG VERSION: (222 lines)

Essential tools I use for inspecting Unicode code points and their 
properties include

    http://training.perl.com/scripts/unichars
    http://training.perl.com/scripts/uniprops
    http://training.perl.com/scripts/uninames

And over the course of the day, these get used a fair bit, too:

    http://training.perl.com/scripts/uniquote
    http://training.perl.com/scripts/ucsort
    http://training.perl.com/scripts/unifmt

Here for example are (some of) the *non*-Letter code point that
are nonetheless considered lowercase or uppercase because
they have the Other_{Lower,Upper}case properties:

    % unichars -gs '\PL' '[\p{upper}\p{lower}]'
     ??  U+00345 GC=Mn SC=Inherited    COMBINING GREEK YPOGEGRAMMENI
     ?  U+02160 GC=Nl SC=Latin        ROMAN NUMERAL ONE
     ?  U+02161 GC=Nl SC=Latin        ROMAN NUMERAL TWO
     ?  U+02162 GC=Nl SC=Latin        ROMAN NUMERAL THREE
     [...]
     ?  U+02170 GC=Nl SC=Latin        SMALL ROMAN NUMERAL ONE
     ?  U+02171 GC=Nl SC=Latin        SMALL ROMAN NUMERAL TWO
     ?  U+02172 GC=Nl SC=Latin        SMALL ROMAN NUMERAL THREE
     [...]
     ?  U+024B6 GC=So SC=Common       CIRCLED LATIN CAPITAL LETTER A
     ?  U+024B7 GC=So SC=Common       CIRCLED LATIN CAPITAL LETTER B
     ?  U+024B8 GC=So SC=Common       CIRCLED LATIN CAPITAL LETTER C
     [...]
     ?  U+024D0 GC=So SC=Common       CIRCLED LATIN SMALL LETTER A
     ?  U+024D1 GC=So SC=Common       CIRCLED LATIN SMALL LETTER B
     ?  U+024D2 GC=So SC=Common       CIRCLED LATIN SMALL LETTER C
     [...]

And here are (some of) the letters that are cased but which are
not Lu, Lt, or Ll (they're all Lm, in fact):

    % unichars -gs '\p{Lm}' '\p{cased}'  | ucsort
     ?  U+1D2D GC=Lm SC=Latin        MODIFIER LETTER CAPITAL AE
     ?  U+1D2C GC=Lm SC=Latin        MODIFIER LETTER CAPITAL A
     ?  U+1D43 GC=Lm SC=Latin        MODIFIER LETTER SMALL A
     ?  U+2090 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER A
     ?  U+1D45 GC=Lm SC=Latin        MODIFIER LETTER SMALL ALPHA
     ?  U+1D2E GC=Lm SC=Latin        MODIFIER LETTER CAPITAL B
     ?  U+1D47 GC=Lm SC=Latin        MODIFIER LETTER SMALL B
     [...]
     ?  U+02B7 GC=Lm SC=Latin        MODIFIER LETTER SMALL W
     ?  U+1D42 GC=Lm SC=Latin        MODIFIER LETTER CAPITAL W
     ?  U+02E3 GC=Lm SC=Latin        MODIFIER LETTER SMALL X
     ?  U+2093 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER X
     ?  U+02B8 GC=Lm SC=Latin        MODIFIER LETTER SMALL Y
     ?  U+1DBB GC=Lm SC=Latin        MODIFIER LETTER SMALL Z
     ?  U+1D5D GC=Lm SC=Greek        MODIFIER LETTER SMALL BETA
     ?  U+1D5E GC=Lm SC=Greek        MODIFIER LETTER SMALL GREEK GAMMA
     ?  U+1D5F GC=Lm SC=Greek        MODIFIER LETTER SMALL DELTA
     ?  U+1DBF GC=Lm SC=Greek        MODIFIER LETTER SMALL THETA
     ?  U+037A GC=Lm SC=Greek        GREEK YPOGEGRAMMENI
     ?  U+1D60 GC=Lm SC=Greek        MODIFIER LETTER SMALL GREEK PHI
     ?  U+1D61 GC=Lm SC=Greek        MODIFIER LETTER SMALL CHI
     ?  U+1D78 GC=Lm SC=Cyrillic     MODIFIER LETTER CYRILLIC EN

Perversely, here are some of the modifier letters which are *not* cased:

    % unichars -gs '\p{Lm}' '\P{CASED}'  | ucsort
     ?  U+2095 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER H
     ?  U+02BB GC=Lm SC=Common       MODIFIER LETTER TURNED COMMA
     ?  U+02BD GC=Lm SC=Common       MODIFIER LETTER REVERSED COMMA
     ?  U+2071 GC=Lm SC=Latin        SUPERSCRIPT LATIN SMALL LETTER I
     ?  U+2096 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER K
     ?  U+2097 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER L
     ?  U+2098 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER M
     ?  U+207F GC=Lm SC=Latin        SUPERSCRIPT LATIN SMALL LETTER N
     ?  U+2099 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER N
     ?  U+209A GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER P
     ?  U+209B GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER S
     ?  U+209C GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER T
     ?  U+02B9 GC=Lm SC=Common       MODIFIER LETTER PRIME
     ?  U+02BA GC=Lm SC=Common       MODIFIER LETTER DOUBLE PRIME
     ?  U+02C6 GC=Lm SC=Common       MODIFIER LETTER CIRCUMFLEX ACCENT
     ?  U+02C7 GC=Lm SC=Common       CARON
     ?  U+02C8 GC=Lm SC=Common       MODIFIER LETTER VERTICAL LINE
     ?  U+02C9 GC=Lm SC=Common       MODIFIER LETTER MACRON
     ?  U+02CA GC=Lm SC=Common       MODIFIER LETTER ACUTE ACCENT
     ?  U+02CB GC=Lm SC=Common       MODIFIER LETTER GRAVE ACCENT
     ?  U+02CC GC=Lm SC=Common       MODIFIER LETTER LOW VERTICAL LINE

(Interesting how the commas sort as breath marks next to H.)

I cannot for the life of me figure out why Unicode deems these lowercase:

     ?  U+1D43 GC=Lm SC=Latin        MODIFIER LETTER SMALL A
     ?  U+2090 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER A
     ?  U+1D45 GC=Lm SC=Latin        MODIFIER LETTER SMALL ALPHA

yet these *not* to be cased:

     ?  U+2071 GC=Lm SC=Latin        SUPERSCRIPT LATIN SMALL LETTER I
     ?  U+2098 GC=Lm SC=Latin        LATIN SUBSCRIPT SMALL LETTER M
     ?  U+207F GC=Lm SC=Latin        SUPERSCRIPT LATIN SMALL LETTER N

All I know is that the tables tell me.

Here's a fair assortment of cased and noncased, case-changing and
non-casing code points.  The variation in binary properties is pretty wide.

    $ uniprops x 00aa 1d4e 2071 2172 df 262 1d401 1d42d 2117 24c5

    U+0078 ?x? \N{LATIN SMALL LETTER X}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic ASCII Assigned Basic_Latin Cased Cased_Letter LC Changes_When_Casemapped CWCM Changes_When_Titlecased CWT Changes_When_Uppercased CWU Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Lowercase_Letter Lower Lowercase PerlWord POSIX_Alnum POSIX_Alpha POSIX_Graph POSIX_Lower POSIX_Print POSIX_Word Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+00AA ??? \N{FEMININE ORDINAL INDICATOR}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic Assigned InLatin1 Cased Cased_Letter LC Changes_When_NFKC_Casefolded CWKCF Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Latin_1 Latin_1_Supplement Lowercase_Letter Lower Lowercase Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+1D4E <?> \N{MODIFIER LETTER SMALL TURNED I}
        \w \pL \p{L_} \p{Lm}
        All Any Alnum Alpha Alphabetic Assigned InPhoneticExtensions Case_Ignorable CI Cased Dia Diacritic L Lm Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Modifier_Letter Lower Lowercase Phonetic_Extensions Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+2071 <?> \N{SUPERSCRIPT LATIN SMALL LETTER I}
        \w \pL \p{L_} \p{Lm}
        All Any Alnum Alpha Alphabetic Assigned InSuperscriptsAndSubscripts Case_Ignorable CI Changes_When_NFKC_Casefolded CWKCF L Lm Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Modifier_Letter Print SD Soft_Dotted Superscripts_And_Subscripts Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Word

    U+2172 <?> \N{SMALL ROMAN NUMERAL THREE}
        \w \pN \p{Nl}
        All Any Alnum Alpha Alphabetic Assigned InNumberForms Cased Changes_When_Casemapped CWCM Changes_When_NFKC_Casefolded CWKCF Changes_When_Titlecased CWT Changes_When_Uppercased CWU Nl N Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Latin Latn Letter_Number Lower Lowercase Number Number_Forms Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+00DF <?> \N{LATIN SMALL LETTER SHARP S}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic Assigned InLatin1 Cased Cased_Letter LC Changes_When_Casefolded CWCF Changes_When_Casemapped CWCM Changes_When_NFKC_Casefolded CWKCF Changes_When_Titlecased CWT Changes_When_Uppercased CWU Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Latin_1 Latin_1_Supplement Lowercase_Letter Lower Lowercase Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+0262 <?> \N{LATIN LETTER SMALL CAPITAL G}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic Assigned InIPA_Extensions Cased Cased_Letter LC Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS IPA_Extensions Letter L_ Latin Latn Lowercase_Letter Lower Lowercase Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+1D401 <?> \N{MATHEMATICAL BOLD CAPITAL B}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
        All Any Alnum Alpha Alphabetic Assigned InMathematicalAlphanumericSymbols Cased Cased_Letter LC Changes_When_NFKC_Casefolded CWKCF Common Zyyy Lu L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Uppercase_Letter Math Mathematical_Alphanumeric_Symbols Print Upper Uppercase Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word

    U+1D42D <?> \N{MATHEMATICAL BOLD SMALL T}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic Assigned InMathematicalAlphanumericSymbols Cased Cased_Letter LC Changes_When_NFKC_Casefolded CWKCF Common Zyyy Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Lowercase_Letter Lower Lowercase Math Mathematical_Alphanumeric_Symbols Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower X_POSIX_Print X_POSIX_Word

    U+2117 ??? \N{SOUND RECORDING COPYRIGHT}
        \pS \p{So}
        All Any Assigned InLetterlikeSymbols Common Zyyy So S Gr_Base Grapheme_Base Graph GrBase Letterlike_Symbols Other_Symbol Print Symbol X_POSIX_Graph X_POSIX_Print

    U+24C5 ??? \N{CIRCLED LATIN CAPITAL LETTER P}
        \w \pS \p{So}
        All Any Alnum Alpha Alphabetic Assigned InEnclosedAlphanumerics Cased Changes_When_Casefolded CWCF Changes_When_Casemapped CWCM Changes_When_Lowercased CWL Changes_When_NFKC_Casefolded CWKCF Common Zyyy Enclosed_Alphanumerics So S Gr_Base Grapheme_Base Graph GrBase Other_Symbol Print Symbol Upper Uppercase Word X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word

Unicode also has a Case_Ignorable (CI) character property, which I haven't 
thought much about but which might be useful.  

    http://www.unicode.org/reports/tr44/#Case_Ignorable

        Characters which are ignored for casing purposes. For more information,
        see D121 in Section 3.13, Default Case Algorithms in [Unicode].

        Generated from: Mn + Me + Cf + Lm + Sk + Word_Break=MidLetter + Word_Break=MidNumLet

I'm not sure if you should think about these when doing your isupper()
test; maybe you should.  That way you wouldn't fail just because you had
a code point that was technically lowercase, like if someone used
"LEONARD M?COY".  That funny ? wouldn't count as a spoiler then, so that
"Leonard M?Coy".upper().isupper() could be true, as the ? wouldn't
change but wouldn't count, either.  I haven't thought about this enough
though.  I'm not used to full string-based isupper() functions, so my
instincts may be wrong here.

The only code point that is both CWCM and also CI is the notorious

     ??  U+00345 GC=Mn SC=Inherited    COMBINING GREEK YPOGEGRAMMENI

Subscripts, superscripts, modifier letters, small capitals, and mathematical
letters *tend* to be cased code points that do not change when casemapped
or casefolded, although there are exceptions.

    % uninames small capital '\b\R\b'
     ?  0280        LATIN LETTER SMALL CAPITAL R
            * voiced uvular trill
            * Germanic, Old Norse
            * uppercase is 01A6
     ?  0281        LATIN LETTER SMALL CAPITAL INVERTED R
            * voiced uvular fricative or approximant
            x (modifier letter small capital inverted r - 02B6)
     ?  02B6        MODIFIER LETTER SMALL CAPITAL INVERTED R
            * preceding four used for r-coloring or r-offglides
            x (latin letter small capital inverted r - 0281)
            # <super> 0281
     ?  1D19        LATIN LETTER SMALL CAPITAL REVERSED R
     ?  1D1A        LATIN LETTER SMALL CAPITAL TURNED R
      ?  1DE2       COMBINING LATIN LETTER SMALL CAPITAL R

   % uniprops 280 1a6
    U+0280 <?> \N{LATIN LETTER SMALL CAPITAL R}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Ll}
        All Any Alnum Alpha Alphabetic Assigned InIPA_Extensions Cased Cased_Letter LC Changes_When_Casemapped CWCM Changes_When_Titlecased CWT Changes_When_Uppercased CWU Ll L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS IPA_Extensions Letter L_ Latin Latn Lowercase_Letter Lower Lowercase Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Lower
           X_POSIX_Print X_POSIX_Word
    U+01A6 <?> \N{LATIN LETTER YR}
        \w \pL \p{LC} \p{L_} \p{L&} \p{Lu}
        All Any Alnum Alpha Alphabetic Assigned InLatinExtendedB Cased Cased_Letter LC Changes_When_Casefolded CWCF Changes_When_Casemapped CWCM Changes_When_Lowercased CWL Changes_When_NFKC_Casefolded CWKCF Lu L Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS Letter L_ Latin Latn Latin_Extended_B Uppercase_Letter Print Upper Uppercase Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha X_POSIX_Graph X_POSIX_Print X_POSIX_Upper X_POSIX_Word

That's right: the uppercase of LATIN LETTER SMALL CAPITAL R is LATIN LETTER
YR, and I don't know why.  No other small capital -- which are all considered
lowercase -- changes when casemapped.  Only this one alone.

Note that things like code points like U+00DF LATIN SMALL LETTER SHARP S
have these binary properties true because the normal/default sense of these
terms in Unicode is the full/string sense not the simple/character sense:

        Changes_When_Casefolded (CWCF) 
        Changes_When_Casemapped (CWCM)
        Changes_When_Titlecased (CWT) 
        Changes_When_Uppercased (CWU)

Those are true because the full uppercase map of "?" is "SS" 
and the full casefold of "?"  is "ss".

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 16:58:59 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 14:58:59 +0000
Subject: [issue10015] Creating a multiprocess.pool.ThreadPool from a child
	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1314457139.06.0.795678306827.issue10015@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
title: Creating a multiproccess.pool.ThreadPool from a child thread blows up. -> Creating a multiprocess.pool.ThreadPool from a child thread blows up.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10015>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:00:39 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 15:00:39 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314457239.18.0.518104634995.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, apparently I can use errmap.mak, except that I get the following error:

Z:\default\PC>nmake errmap.mak

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

        cl  generrmap.c
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

generrmap.c
generrmap.c(1) : fatal error C1034: stdio.h: no include path set
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\
VC\bin\amd64\cl.EXE"' : return code '0x2'
Stop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:02:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 15:02:09 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314457329.33.0.951507822425.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, running vcvarsamd64.bat seems to do the trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:13:03 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 15:13:03 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1314457983.87.0.672335182627.issue8426@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I think it's just a documentation issue. The problem with documenting limits is that they are system-specific and, even if the current limits that Charles-Fran?ois has mentioned are documented, these could become outdated. Perhaps a suggestion could be added to the documentation:

"Avoid sending very large amounts of data via queues, as you could come up against system-dependent limits according to the operating system and whether pipes or sockets are used. You could consider an alternative strategy, such as writing large data blocks to temporary files and sending just the temporary file names via queues, relying on the consumer to delete the temporary files after processing."

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:19:44 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 15:19:44 +0000
Subject: [issue11990] redirected output - stdout writes newline as \n in
	windows
In-Reply-To: <1304458030.29.0.258748957891.issue11990@psf.upfronthosting.co.za>
Message-ID: <1314458384.32.0.970190287931.issue11990@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

So is this now just a documentation issue, about the changed behaviour of pipes in 3.2?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11990>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:24:23 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 15:24:23 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1314458663.63.0.703303583375.issue8296@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Closing, as Andrey Vlasovskikh has agreed that this is a duplicate of #9205.

----------
nosy: +vinay.sajip
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8296>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:27:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 15:27:25 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314458845.84.0.434398751002.issue12802@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch.

----------
Added file: http://bugs.python.org/file23053/winenotdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:30:20 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 27 Aug 2011 15:30:20 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314459020.97.0.82331777357.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Attached updated patch which extends generrmap.c to allow for easy addition of other error mappings.

Also regenerated errmap.h and unittest.

----------
Added file: http://bugs.python.org/file23054/issue12802_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:37:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 15:37:11 +0000
Subject: [issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
In-Reply-To: <1270265835.83.0.251816264221.issue8296@psf.upfronthosting.co.za>
Message-ID: <1314459431.94.0.872943550337.issue8296@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note that #9205 fixed concurrent.futures, but not multiprocessing.Pool which is a different kettle of fish.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8296>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:47:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 27 Aug 2011 15:47:00 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1314457983.87.0.672335182627.issue8426@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1_Ht=+0zZQ_xR=R=u=T7EQf=dsyO_YQ8BwOViMSO3tAQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> "Avoid sending very large amounts of data via queues, as you could come up against system-dependent limits according to the operating system and whether pipes or sockets are used. You could consider an alternative strategy, such as writing large data blocks to temporary files and sending just the temporary file names via queues, relying on the consumer to delete the temporary files after processing."

There's a misunderstanding here: there is absolutely no limit on the
size of objects that can be put through a queue (apart from the host's
memory and the 32-bit limit): the problem is really that you can't
just put an arbitrary buch of data to a queue, and then join it before
making sure other processes will *eventually* pop all the data from
the queue.
I.e., you can't do:

q = Queue()
for i in range(1000000):
    q.put(<big obj>)
q.join()

for i in range(10000000):
    q.get()

That's because join() will wait until the feeder thread has managed to
write all the items to the underlying pipe/Unix socket, and this might
hang if the underlying pipe/socket is full (which will happen after
one has put around 128K without having popped any item).

That's what's explained here:

It's documented in
http://docs.python.org/library/multiprocessing.html#multiprocessing-programming
:
"""
Joining processes that use queues

Bear in mind that a process that has put items in a queue will wait
before terminating until all the buffered items are fed by the
?feeder? thread to the underlying pipe. (The child process can call
the Queue.cancel_join_thread() method of the queue to avoid this
behaviour.)

This means that whenever you use a queue you need to make sure that
all items which have been put on the queue will eventually be removed
before the process is joined. Otherwise you cannot be sure that
processes which have put items on the queue will terminate. Remember
also that non-daemonic processes will be automatically be joined.
"""

If find this wording really clear, but if someone comes up with a
better - i.e. less technical - wording, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Sat Aug 27 17:57:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Aug 2011 15:57:16 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1314460636.09.0.071353291528.issue6560@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Putting this back to open until we decide what to do about the OS X test failures. It sounds like it could really do with some more poking and prodding to figure out whether or not it poses a potential security risk or is just a relatively cosmetic problem with the API, so I'm reluctant to just skip the failing tests at this point.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Sat Aug 27 18:15:33 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 27 Aug 2011 16:15:33 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <30133.1314456489@chthon>
Message-ID: <CAP7+vJLWS7GD0LmggvqX_JOrwQ6iAkXpQunSd18vOh1sMV404g@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Thanks you very much. We should fix the behavior in 3.3 for sure. I'm
thinking that we may be able to backport the behavior fix to 2.7 and
3.2 as well, since it just makes the behavior generally "better" (and
for most folks it won't matter anyway).

I'm not sure where the somewhat odd rules for .islower() come from, I
think in part from the desire to have "".islower() be False but "a
b".islower() to be True. Intuitively, this means that .islower() means
both "there is at least one lower case character" and "there are no
upper case characters", but not "all characters are lowercase". I
forget what we do w.r.t. titlecase, but the intuitive meaning should
not change. Although personally I don't have much of an intuition for
what titlecase means (and why it's important), perhaps because I'm not
familiar with any language where there is a third case for some
letters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 21:17:30 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 27 Aug 2011 19:17:30 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <CAP7+vJLWS7GD0LmggvqX_JOrwQ6iAkXpQunSd18vOh1sMV404g@mail.gmail.com>
Message-ID: <25762.1314471799@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Guido van Rossum <report at bugs.python.org> wrote
   on Sat, 27 Aug 2011 16:15:33 -0000: 

> Although personally I don't have much of an intuition for what
> titlecase means (and why it's important), perhaps because I'm not
> familiar with any language where there is a third case for some
> letters.

Neither am I.  Even in "old-style" English with ae and oe, one wrote
?GYPT and ?SIR all caps but ?gypt and ?sir in titlecase, not *Aegypt or
*Aesir.  Similarly with ?NOLOGY / ?nology / ?nology, never *Oenology.

    (BTW, in French you really shouldn't split up the ? into oe, 
          nor in Old English, Old Norse, or Icelandic the ? in ae;
          although in contemporary English, it's usually ok to do so.)

I believe that almost but not quite all the sticky situations with
Unicode casing involve compatibility characters for clean round-trips
with legacy encodings.  Exceptions include the German sharp s (both of 
them now) and the two Greek lowercase sigmas.  Thank goodness we don't
use the long s in English anymore.  What is it with s's, anyway? :)

Most of the titlecase letters are in Greek, with a few in Armenian.
I know no Armenian (their letters all look the same to me :), and the
folks I talked to about the Greek are skeptical.  The German sharp s is
a red herring, because you can never have it as the first letter
(although it needn't be the last, as in Ru?land).  That's no more
possible than having the old legacy ? ligature appear at the beginning
of an English world.

In any event, there are only 129 total code points that are
"problematic" in terms of their case, where by problematic 
I mean one or more of:

   --- titlecase differs from uppercase
   --- foldcase  differs from lowercase
   --- any of fold/lower/title/uppercase yields more than one code point

Of all these, it's the (now two!) sharp s's and the Turkic i that are the most annoying.
It's really quite a lot of trouble to go through for so few code points of so little
(perceived) use.  But I suppose you never know what new ones they'll uncover, either.
Here are those 129 case-problematicals arranged in UCA order.  Some of these
normilizations forms that decompose into graphemes with four code points (not shown).
There are a few other oddities, like the Kelvin sign and other "singletons", but these
are most of the trouble. They're all in the BMP; I guess we learned our lesson. :)

--tom

  1: U+0345 ??  COMBINING  GREEK YPOGEGRAMMENI
               fc=?  U+3B9 lc=??  U+345 tc=?  U+399 uc=?  U+399 
  2: U+1E9A ?  LATIN SMALL LETTER A WITH RIGHT HALF RING
               fc=a?  U+61.2BE lc=?  U+1E9A tc=A?  U+41.2BE uc=A?  U+41.2BE 
  3: U+01F3 ?  LATIN SMALL LETTER DZ
               fc=?  U+1F3 lc=?  U+1F3 tc=?  U+1F2 uc=?  U+1F1 
  4: U+01F2 ?  LATIN CAPITAL LETTER D WITH SMALL LETTER Z
               fc=?  U+1F3 lc=?  U+1F3 tc=?  U+1F2 uc=?  U+1F1 
  5: U+01F1 ?  LATIN CAPITAL LETTER DZ
               fc=?  U+1F3 lc=?  U+1F3 tc=?  U+1F2 uc=?  U+1F1 
  6: U+01C6 ?  LATIN SMALL LETTER DZ WITH CARON
               fc=?  U+1C6 lc=?  U+1C6 tc=?  U+1C5 uc=?  U+1C4 
  7: U+01C5 ?  LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON
               fc=?  U+1C6 lc=?  U+1C6 tc=?  U+1C5 uc=?  U+1C4 
  8: U+01C4 ?  LATIN CAPITAL LETTER DZ WITH CARON
               fc=?  U+1C6 lc=?  U+1C6 tc=?  U+1C5 uc=?  U+1C4 
  9: U+FB00 ?  LATIN SMALL LIGATURE FF
               fc=ff  U+66.66 lc=?  U+FB00 tc=Ff  U+46.66 uc=FF  U+46.46 
 10: U+FB03 ?  LATIN SMALL LIGATURE FFI
               fc=ffi  U+66.66.69 lc=?  U+FB03 tc=Ffi  U+46.66.69 uc=FFI  U+46.46.49 
 11: U+FB04 ?  LATIN SMALL LIGATURE FFL
               fc=ffl  U+66.66.6C lc=?  U+FB04 tc=Ffl  U+46.66.6C uc=FFL  U+46.46.4C 
 12: U+FB01 ?  LATIN SMALL LIGATURE FI
               fc=fi  U+66.69 lc=?  U+FB01 tc=Fi  U+46.69 uc=FI  U+46.49 
 13: U+FB02 ?  LATIN SMALL LIGATURE FL
               fc=fl  U+66.6C lc=?  U+FB02 tc=Fl  U+46.6C uc=FL  U+46.4C 
 14: U+1E96 ?  LATIN SMALL LETTER H WITH LINE BELOW
               fc=h?  U+68.331 lc=?  U+1E96 tc=H?  U+48.331 uc=H?  U+48.331 
 15: U+0130 ?  LATIN CAPITAL LETTER I WITH DOT ABOVE
               fc=i?  U+69.307 lc=i?  U+69.307 tc=?  U+130 uc=?  U+130 
 16: U+01F0 ?  LATIN SMALL LETTER J WITH CARON
               fc=j?  U+6A.30C lc=?  U+1F0 tc=J?  U+4A.30C uc=J?  U+4A.30C 
 17: U+01C9 ?  LATIN SMALL LETTER LJ
               fc=?  U+1C9 lc=?  U+1C9 tc=?  U+1C8 uc=?  U+1C7 
 18: U+01C8 ?  LATIN CAPITAL LETTER L WITH SMALL LETTER J
               fc=?  U+1C9 lc=?  U+1C9 tc=?  U+1C8 uc=?  U+1C7 
 19: U+01C7 ?  LATIN CAPITAL LETTER LJ
               fc=?  U+1C9 lc=?  U+1C9 tc=?  U+1C8 uc=?  U+1C7 
 20: U+01CC ?  LATIN SMALL LETTER NJ
               fc=?  U+1CC lc=?  U+1CC tc=?  U+1CB uc=?  U+1CA 
 21: U+01CB ?  LATIN CAPITAL LETTER N WITH SMALL LETTER J
               fc=?  U+1CC lc=?  U+1CC tc=?  U+1CB uc=?  U+1CA 
 22: U+01CA ?  LATIN CAPITAL LETTER NJ
               fc=?  U+1CC lc=?  U+1CC tc=?  U+1CB uc=?  U+1CA 
 23: U+017F ?  LATIN SMALL LETTER LONG S
               fc=s  U+73 lc=?  U+17F tc=S  U+53 uc=S  U+53 
 24: U+1E9B ?  LATIN SMALL LETTER LONG S WITH DOT ABOVE
               fc=?  U+1E61 lc=?  U+1E9B tc=?  U+1E60 uc=?  U+1E60 
 25: U+00DF ?  LATIN SMALL LETTER SHARP S
               fc=ss  U+73.73 lc=?  U+DF tc=Ss  U+53.73 uc=SS  U+53.53 
 26: U+1E9E ?  LATIN CAPITAL LETTER SHARP S
               fc=ss  U+73.73 lc=?  U+DF tc=?  U+1E9E uc=?  U+1E9E 
 27: U+FB06 ?  LATIN SMALL LIGATURE ST
               fc=st  U+73.74 lc=?  U+FB06 tc=St  U+53.74 uc=ST  U+53.54 
 28: U+FB05 ?  LATIN SMALL LIGATURE LONG S T
               fc=st  U+73.74 lc=?  U+FB05 tc=St  U+53.74 uc=ST  U+53.54 
 29: U+1E97 ?  LATIN SMALL LETTER T WITH DIAERESIS
               fc=t?  U+74.308 lc=?  U+1E97 tc=T?  U+54.308 uc=T?  U+54.308 
 30: U+1E98 ?  LATIN SMALL LETTER W WITH RING ABOVE
               fc=w?  U+77.30A lc=?  U+1E98 tc=W?  U+57.30A uc=W?  U+57.30A 
 31: U+1E99 ?  LATIN SMALL LETTER Y WITH RING ABOVE
               fc=y?  U+79.30A lc=?  U+1E99 tc=Y?  U+59.30A uc=Y?  U+59.30A 
 32: U+0149 ?  LATIN SMALL LETTER N PRECEDED BY APOSTROPHE
               fc=?n  U+2BC.6E lc=?  U+149 tc=?N  U+2BC.4E uc=?N  U+2BC.4E 
 33: U+1F84 ?  GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F04.3B9 lc=?  U+1F84 tc=?  U+1F8C uc=??  U+1F0C.399 
 34: U+1F8C ?  GREEK CAPITAL LETTER ALPHA WITH PSILI AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F04.3B9 lc=?  U+1F84 tc=?  U+1F8C uc=??  U+1F0C.399 
 35: U+1F82 ?  GREEK SMALL LETTER ALPHA WITH PSILI AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F02.3B9 lc=?  U+1F82 tc=?  U+1F8A uc=??  U+1F0A.399 
 36: U+1F8A ?  GREEK CAPITAL LETTER ALPHA WITH PSILI AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F02.3B9 lc=?  U+1F82 tc=?  U+1F8A uc=??  U+1F0A.399 
 37: U+1F86 ?  GREEK SMALL LETTER ALPHA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F06.3B9 lc=?  U+1F86 tc=?  U+1F8E uc=??  U+1F0E.399 
 38: U+1F8E ?  GREEK CAPITAL LETTER ALPHA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F06.3B9 lc=?  U+1F86 tc=?  U+1F8E uc=??  U+1F0E.399 
 39: U+1F80 ?  GREEK SMALL LETTER ALPHA WITH PSILI AND YPOGEGRAMMENI
               fc=??  U+1F00.3B9 lc=?  U+1F80 tc=?  U+1F88 uc=??  U+1F08.399 
 40: U+1F88 ?  GREEK CAPITAL LETTER ALPHA WITH PSILI AND PROSGEGRAMMENI
               fc=??  U+1F00.3B9 lc=?  U+1F80 tc=?  U+1F88 uc=??  U+1F08.399 
 41: U+1F85 ?  GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F05.3B9 lc=?  U+1F85 tc=?  U+1F8D uc=??  U+1F0D.399 
 42: U+1F8D ?  GREEK CAPITAL LETTER ALPHA WITH DASIA AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F05.3B9 lc=?  U+1F85 tc=?  U+1F8D uc=??  U+1F0D.399 
 43: U+1F83 ?  GREEK SMALL LETTER ALPHA WITH DASIA AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F03.3B9 lc=?  U+1F83 tc=?  U+1F8B uc=??  U+1F0B.399 
 44: U+1F8B ?  GREEK CAPITAL LETTER ALPHA WITH DASIA AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F03.3B9 lc=?  U+1F83 tc=?  U+1F8B uc=??  U+1F0B.399 
 45: U+1F87 ?  GREEK SMALL LETTER ALPHA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F07.3B9 lc=?  U+1F87 tc=?  U+1F8F uc=??  U+1F0F.399 
 46: U+1F8F ?  GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F07.3B9 lc=?  U+1F87 tc=?  U+1F8F uc=??  U+1F0F.399 
 47: U+1F81 ?  GREEK SMALL LETTER ALPHA WITH DASIA AND YPOGEGRAMMENI
               fc=??  U+1F01.3B9 lc=?  U+1F81 tc=?  U+1F89 uc=??  U+1F09.399 
 48: U+1F89 ?  GREEK CAPITAL LETTER ALPHA WITH DASIA AND PROSGEGRAMMENI
               fc=??  U+1F01.3B9 lc=?  U+1F81 tc=?  U+1F89 uc=??  U+1F09.399 
 49: U+1FB4 ?  GREEK SMALL LETTER ALPHA WITH OXIA AND YPOGEGRAMMENI
               fc=??  U+3AC.3B9 lc=?  U+1FB4 tc=??  U+386.345 uc=??  U+386.399 
 50: U+1FB2 ?  GREEK SMALL LETTER ALPHA WITH VARIA AND YPOGEGRAMMENI
               fc=??  U+1F70.3B9 lc=?  U+1FB2 tc=??  U+1FBA.345 uc=??  U+1FBA.399 
 51: U+1FB6 ?  GREEK SMALL LETTER ALPHA WITH PERISPOMENI
               fc=??  U+3B1.342 lc=?  U+1FB6 tc=??  U+391.342 uc=??  U+391.342 
 52: U+1FB7 ?  GREEK SMALL LETTER ALPHA WITH PERISPOMENI AND YPOGEGRAMMENI
               fc=???  U+3B1.342.3B9 lc=?  U+1FB7 tc=???  U+391.342.345 uc=???  U+391.342.399 
 53: U+1FB3 ?  GREEK SMALL LETTER ALPHA WITH YPOGEGRAMMENI
               fc=??  U+3B1.3B9 lc=?  U+1FB3 tc=?  U+1FBC uc=??  U+391.399 
 54: U+1FBC ?  GREEK CAPITAL LETTER ALPHA WITH PROSGEGRAMMENI
               fc=??  U+3B1.3B9 lc=?  U+1FB3 tc=?  U+1FBC uc=??  U+391.399 
 55: U+03D0 ?  GREEK BETA SYMBOL
               fc=?  U+3B2 lc=?  U+3D0 tc=?  U+392 uc=?  U+392 
 56: U+03F5 ?  GREEK LUNATE EPSILON SYMBOL
               fc=?  U+3B5 lc=?  U+3F5 tc=?  U+395 uc=?  U+395 
 57: U+1F94 ?  GREEK SMALL LETTER ETA WITH PSILI AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F24.3B9 lc=?  U+1F94 tc=?  U+1F9C uc=??  U+1F2C.399 
 58: U+1F9C ?  GREEK CAPITAL LETTER ETA WITH PSILI AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F24.3B9 lc=?  U+1F94 tc=?  U+1F9C uc=??  U+1F2C.399 
 59: U+1F92 ?  GREEK SMALL LETTER ETA WITH PSILI AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F22.3B9 lc=?  U+1F92 tc=?  U+1F9A uc=??  U+1F2A.399 
 60: U+1F9A ?  GREEK CAPITAL LETTER ETA WITH PSILI AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F22.3B9 lc=?  U+1F92 tc=?  U+1F9A uc=??  U+1F2A.399 
 61: U+1F96 ?  GREEK SMALL LETTER ETA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F26.3B9 lc=?  U+1F96 tc=?  U+1F9E uc=??  U+1F2E.399 
 62: U+1F9E ?  GREEK CAPITAL LETTER ETA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F26.3B9 lc=?  U+1F96 tc=?  U+1F9E uc=??  U+1F2E.399 
 63: U+1F90 ?  GREEK SMALL LETTER ETA WITH PSILI AND YPOGEGRAMMENI
               fc=??  U+1F20.3B9 lc=?  U+1F90 tc=?  U+1F98 uc=??  U+1F28.399 
 64: U+1F98 ?  GREEK CAPITAL LETTER ETA WITH PSILI AND PROSGEGRAMMENI
               fc=??  U+1F20.3B9 lc=?  U+1F90 tc=?  U+1F98 uc=??  U+1F28.399 
 65: U+1F95 ?  GREEK SMALL LETTER ETA WITH DASIA AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F25.3B9 lc=?  U+1F95 tc=?  U+1F9D uc=??  U+1F2D.399 
 66: U+1F9D ?  GREEK CAPITAL LETTER ETA WITH DASIA AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F25.3B9 lc=?  U+1F95 tc=?  U+1F9D uc=??  U+1F2D.399 
 67: U+1F93 ?  GREEK SMALL LETTER ETA WITH DASIA AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F23.3B9 lc=?  U+1F93 tc=?  U+1F9B uc=??  U+1F2B.399 
 68: U+1F9B ?  GREEK CAPITAL LETTER ETA WITH DASIA AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F23.3B9 lc=?  U+1F93 tc=?  U+1F9B uc=??  U+1F2B.399 
 69: U+1F97 ?  GREEK SMALL LETTER ETA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F27.3B9 lc=?  U+1F97 tc=?  U+1F9F uc=??  U+1F2F.399 
 70: U+1F9F ?  GREEK CAPITAL LETTER ETA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F27.3B9 lc=?  U+1F97 tc=?  U+1F9F uc=??  U+1F2F.399 
 71: U+1F91 ?  GREEK SMALL LETTER ETA WITH DASIA AND YPOGEGRAMMENI
               fc=??  U+1F21.3B9 lc=?  U+1F91 tc=?  U+1F99 uc=??  U+1F29.399 
 72: U+1F99 ?  GREEK CAPITAL LETTER ETA WITH DASIA AND PROSGEGRAMMENI
               fc=??  U+1F21.3B9 lc=?  U+1F91 tc=?  U+1F99 uc=??  U+1F29.399 
 73: U+1FC4 ?  GREEK SMALL LETTER ETA WITH OXIA AND YPOGEGRAMMENI
               fc=??  U+3AE.3B9 lc=?  U+1FC4 tc=??  U+389.345 uc=??  U+389.399 
 74: U+1FC2 ?  GREEK SMALL LETTER ETA WITH VARIA AND YPOGEGRAMMENI
               fc=??  U+1F74.3B9 lc=?  U+1FC2 tc=??  U+1FCA.345 uc=??  U+1FCA.399 
 75: U+1FC6 ?  GREEK SMALL LETTER ETA WITH PERISPOMENI
               fc=??  U+3B7.342 lc=?  U+1FC6 tc=??  U+397.342 uc=??  U+397.342 
 76: U+1FC7 ?  GREEK SMALL LETTER ETA WITH PERISPOMENI AND YPOGEGRAMMENI
               fc=???  U+3B7.342.3B9 lc=?  U+1FC7 tc=???  U+397.342.345 uc=???  U+397.342.399 
 77: U+1FC3 ?  GREEK SMALL LETTER ETA WITH YPOGEGRAMMENI
               fc=??  U+3B7.3B9 lc=?  U+1FC3 tc=?  U+1FCC uc=??  U+397.399 
 78: U+1FCC ?  GREEK CAPITAL LETTER ETA WITH PROSGEGRAMMENI
               fc=??  U+3B7.3B9 lc=?  U+1FC3 tc=?  U+1FCC uc=??  U+397.399 
 79: U+03D1 ?  GREEK THETA SYMBOL
               fc=?  U+3B8 lc=?  U+3D1 tc=?  U+398 uc=?  U+398 
 80: U+1FBE ?  GREEK PROSGEGRAMMENI
               fc=?  U+3B9 lc=?  U+1FBE tc=?  U+399 uc=?  U+399 
 81: U+1FD6 ?  GREEK SMALL LETTER IOTA WITH PERISPOMENI
               fc=??  U+3B9.342 lc=?  U+1FD6 tc=??  U+399.342 uc=??  U+399.342 
 82: U+0390 ?  GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS
               fc=???  U+3B9.308.301 lc=?  U+390 tc=???  U+399.308.301 uc=???  U+399.308.301 
 83: U+1FD3 ?  GREEK SMALL LETTER IOTA WITH DIALYTIKA AND OXIA
               fc=???  U+3B9.308.301 lc=?  U+1FD3 tc=???  U+399.308.301 uc=???  U+399.308.301 
 84: U+1FD2 ?  GREEK SMALL LETTER IOTA WITH DIALYTIKA AND VARIA
               fc=???  U+3B9.308.300 lc=?  U+1FD2 tc=???  U+399.308.300 uc=???  U+399.308.300 
 85: U+1FD7 ?  GREEK SMALL LETTER IOTA WITH DIALYTIKA AND PERISPOMENI
               fc=???  U+3B9.308.342 lc=?  U+1FD7 tc=???  U+399.308.342 uc=???  U+399.308.342 
 86: U+03F0 ?  GREEK KAPPA SYMBOL
               fc=?  U+3BA lc=?  U+3F0 tc=?  U+39A uc=?  U+39A 
 87: U+00B5 ?  MICRO SIGN
               fc=?  U+3BC lc=?  U+B5 tc=?  U+39C uc=?  U+39C 
 88: U+03D6 ?  GREEK PI SYMBOL
               fc=?  U+3C0 lc=?  U+3D6 tc=?  U+3A0 uc=?  U+3A0 
 89: U+03F1 ?  GREEK RHO SYMBOL
               fc=?  U+3C1 lc=?  U+3F1 tc=?  U+3A1 uc=?  U+3A1 
 90: U+1FE4 ?  GREEK SMALL LETTER RHO WITH PSILI
               fc=??  U+3C1.313 lc=?  U+1FE4 tc=??  U+3A1.313 uc=??  U+3A1.313 
 91: U+03C2 ?  GREEK SMALL LETTER FINAL SIGMA
               fc=?  U+3C3 lc=?  U+3C2 tc=?  U+3A3 uc=?  U+3A3 
 92: U+1F50 ?  GREEK SMALL LETTER UPSILON WITH PSILI
               fc=??  U+3C5.313 lc=?  U+1F50 tc=??  U+3A5.313 uc=??  U+3A5.313 
 93: U+1F54 ?  GREEK SMALL LETTER UPSILON WITH PSILI AND OXIA
               fc=???  U+3C5.313.301 lc=?  U+1F54 tc=???  U+3A5.313.301 uc=???  U+3A5.313.301 
 94: U+1F52 ?  GREEK SMALL LETTER UPSILON WITH PSILI AND VARIA
               fc=???  U+3C5.313.300 lc=?  U+1F52 tc=???  U+3A5.313.300 uc=???  U+3A5.313.300 
 95: U+1F56 ?  GREEK SMALL LETTER UPSILON WITH PSILI AND PERISPOMENI
               fc=???  U+3C5.313.342 lc=?  U+1F56 tc=???  U+3A5.313.342 uc=???  U+3A5.313.342 
 96: U+1FE6 ?  GREEK SMALL LETTER UPSILON WITH PERISPOMENI
               fc=??  U+3C5.342 lc=?  U+1FE6 tc=??  U+3A5.342 uc=??  U+3A5.342 
 97: U+03B0 ?  GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS
               fc=???  U+3C5.308.301 lc=?  U+3B0 tc=???  U+3A5.308.301 uc=???  U+3A5.308.301 
 98: U+1FE3 ?  GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND OXIA
               fc=???  U+3C5.308.301 lc=?  U+1FE3 tc=???  U+3A5.308.301 uc=???  U+3A5.308.301 
 99: U+1FE2 ?  GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND VARIA
               fc=???  U+3C5.308.300 lc=?  U+1FE2 tc=???  U+3A5.308.300 uc=???  U+3A5.308.300 
100: U+1FE7 ?  GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND PERISPOMENI
               fc=???  U+3C5.308.342 lc=?  U+1FE7 tc=???  U+3A5.308.342 uc=???  U+3A5.308.342 
101: U+03D5 ?  GREEK PHI SYMBOL
               fc=?  U+3C6 lc=?  U+3D5 tc=?  U+3A6 uc=?  U+3A6 
102: U+1FA4 ?  GREEK SMALL LETTER OMEGA WITH PSILI AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F64.3B9 lc=?  U+1FA4 tc=?  U+1FAC uc=??  U+1F6C.399 
103: U+1FAC ?  GREEK CAPITAL LETTER OMEGA WITH PSILI AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F64.3B9 lc=?  U+1FA4 tc=?  U+1FAC uc=??  U+1F6C.399 
104: U+1FA2 ?  GREEK SMALL LETTER OMEGA WITH PSILI AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F62.3B9 lc=?  U+1FA2 tc=?  U+1FAA uc=??  U+1F6A.399 
105: U+1FAA ?  GREEK CAPITAL LETTER OMEGA WITH PSILI AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F62.3B9 lc=?  U+1FA2 tc=?  U+1FAA uc=??  U+1F6A.399 
106: U+1FA6 ?  GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F66.3B9 lc=?  U+1FA6 tc=?  U+1FAE uc=??  U+1F6E.399 
107: U+1FAE ?  GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F66.3B9 lc=?  U+1FA6 tc=?  U+1FAE uc=??  U+1F6E.399 
108: U+1FA0 ?  GREEK SMALL LETTER OMEGA WITH PSILI AND YPOGEGRAMMENI
               fc=??  U+1F60.3B9 lc=?  U+1FA0 tc=?  U+1FA8 uc=??  U+1F68.399 
109: U+1FA8 ?  GREEK CAPITAL LETTER OMEGA WITH PSILI AND PROSGEGRAMMENI
               fc=??  U+1F60.3B9 lc=?  U+1FA0 tc=?  U+1FA8 uc=??  U+1F68.399 
110: U+1FA5 ?  GREEK SMALL LETTER OMEGA WITH DASIA AND OXIA AND YPOGEGRAMMENI
               fc=??  U+1F65.3B9 lc=?  U+1FA5 tc=?  U+1FAD uc=??  U+1F6D.399 
111: U+1FAD ?  GREEK CAPITAL LETTER OMEGA WITH DASIA AND OXIA AND PROSGEGRAMMENI
               fc=??  U+1F65.3B9 lc=?  U+1FA5 tc=?  U+1FAD uc=??  U+1F6D.399 
112: U+1FA3 ?  GREEK SMALL LETTER OMEGA WITH DASIA AND VARIA AND YPOGEGRAMMENI
               fc=??  U+1F63.3B9 lc=?  U+1FA3 tc=?  U+1FAB uc=??  U+1F6B.399 
113: U+1FAB ?  GREEK CAPITAL LETTER OMEGA WITH DASIA AND VARIA AND PROSGEGRAMMENI
               fc=??  U+1F63.3B9 lc=?  U+1FA3 tc=?  U+1FAB uc=??  U+1F6B.399 
114: U+1FA7 ?  GREEK SMALL LETTER OMEGA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI
               fc=??  U+1F67.3B9 lc=?  U+1FA7 tc=?  U+1FAF uc=??  U+1F6F.399 
115: U+1FAF ?  GREEK CAPITAL LETTER OMEGA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI
               fc=??  U+1F67.3B9 lc=?  U+1FA7 tc=?  U+1FAF uc=??  U+1F6F.399 
116: U+1FA1 ?  GREEK SMALL LETTER OMEGA WITH DASIA AND YPOGEGRAMMENI
               fc=??  U+1F61.3B9 lc=?  U+1FA1 tc=?  U+1FA9 uc=??  U+1F69.399 
117: U+1FA9 ?  GREEK CAPITAL LETTER OMEGA WITH DASIA AND PROSGEGRAMMENI
               fc=??  U+1F61.3B9 lc=?  U+1FA1 tc=?  U+1FA9 uc=??  U+1F69.399 
118: U+1FF4 ?  GREEK SMALL LETTER OMEGA WITH OXIA AND YPOGEGRAMMENI
               fc=??  U+3CE.3B9 lc=?  U+1FF4 tc=??  U+38F.345 uc=??  U+38F.399 
119: U+1FF2 ?  GREEK SMALL LETTER OMEGA WITH VARIA AND YPOGEGRAMMENI
               fc=??  U+1F7C.3B9 lc=?  U+1FF2 tc=??  U+1FFA.345 uc=??  U+1FFA.399 
120: U+1FF6 ?  GREEK SMALL LETTER OMEGA WITH PERISPOMENI
               fc=??  U+3C9.342 lc=?  U+1FF6 tc=??  U+3A9.342 uc=??  U+3A9.342 
121: U+1FF7 ?  GREEK SMALL LETTER OMEGA WITH PERISPOMENI AND YPOGEGRAMMENI
               fc=???  U+3C9.342.3B9 lc=?  U+1FF7 tc=???  U+3A9.342.345 uc=???  U+3A9.342.399 
122: U+1FF3 ?  GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI
               fc=??  U+3C9.3B9 lc=?  U+1FF3 tc=?  U+1FFC uc=??  U+3A9.399 
123: U+1FFC ?  GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI
               fc=??  U+3C9.3B9 lc=?  U+1FF3 tc=?  U+1FFC uc=??  U+3A9.399 
124: U+0587 ?  ARMENIAN SMALL LIGATURE ECH YIWN
               fc=??  U+565.582 lc=?  U+587 tc=??  U+535.582 uc=??  U+535.552 
125: U+FB14 ?  ARMENIAN SMALL LIGATURE MEN ECH
               fc=??  U+574.565 lc=?  U+FB14 tc=??  U+544.565 uc=??  U+544.535 
126: U+FB15 ?  ARMENIAN SMALL LIGATURE MEN INI
               fc=??  U+574.56B lc=?  U+FB15 tc=??  U+544.56B uc=??  U+544.53B 
127: U+FB17 ?  ARMENIAN SMALL LIGATURE MEN XEH
               fc=??  U+574.56D lc=?  U+FB17 tc=??  U+544.56D uc=??  U+544.53D 
128: U+FB13 ?  ARMENIAN SMALL LIGATURE MEN NOW
               fc=??  U+574.576 lc=?  U+FB13 tc=??  U+544.576 uc=??  U+544.546 
129: U+FB16 ?  ARMENIAN SMALL LIGATURE VEW NOW
               fc=??  U+57E.576 lc=?  U+FB16 tc=??  U+54E.576 uc=??  U+54E.546

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 21:29:29 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 27 Aug 2011 19:29:29 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314473369.52.0.906575636063.issue12736@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

There are some oddities in Unicode case-folding.

Under full case-folding, both "\N{LATIN CAPITAL LETTER SHARP S}" and "\N{LATIN SMALL LETTER SHARP S}" fold to "ss", which means that those codepoints match each other.

However, under simple case-folding, they fold to themselves, which means that those codepoints _don't_ match each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 22:04:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 20:04:56 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314475496.58.0.92504976311.issue12736@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Neither am I.  Even in "old-style" English with ae and oe, one wrote
> ?GYPT and ?SIR all caps but ?gypt and ?sir in titlecase, not *Aegypt or
> *Aesir.  Similarly with ?NOLOGY / ?nology / ?nology, never *Oenology.

Trying to disprove you a bit:
http://ecx.images-amazon.com/images/I/51G6CH9XFFL._SL500_AA300_.jpg
http://ecx.images-amazon.com/images/I/51k7TmosPdL._SL500_AA300_.jpg
http://ecx.images-amazon.com/images/I/518UzMeLFCL._SL500_AA300_.jpg

but classical typographies seem to write either the uppercase ? or the lowercase ?.

That said, I wonder why Unicode even includes ligatures like ?. Sounds like mission creep to me (and horrible annoyances for people like us).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sat Aug 27 22:09:19 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Sat, 27 Aug 2011 20:09:19 +0000
Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR,
	not EINVAL
In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za>
Message-ID: <1314475759.72.0.978969959208.issue12802@psf.upfronthosting.co.za>


Vlad Riscutia <riscutiavlad at gmail.com> added the comment:

Ah, I see Antoine already attached a patch. I was 3 minutes late :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12802>
_______________________________________

From report at bugs.python.org  Sat Aug 27 22:23:39 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Aug 2011 20:23:39 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314476619.85.0.242545829832.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python makes it easy to transform a sequence with a generator as long as no look-ahead is needed. utf16.UTF16.__iter__ is a typical example. Whenever a surrogate is found, grab the matching one.

However, grapheme clustering does require look-ahead, which is a bit trickier. Assume s is a sanitized sequence of code points with unicode database entries. Ignoring line endings the following should work (I tested it with a toy definition of mark()):

def graphemes(s):
  sit = iter(s)
  try: graph = [next(sit)]
  except StopIteration: graph = []

  for cp in sit:
    if mark(cp):  
      graph.append(cp)
    else:
      yield combine(graph)
      graph = [cp]

  yield combine(graph)

I tested this with several input with
def mark(cp): return cp == '.'
def combine(l) return ''.join(l)

Python's object orientation makes formatting easy for the user. Assume someone does the hard work of writing (once ;-) a GCString class with a .__format__ method that interprets the format mini-language for graphemes, using a generalized version of your 'simply horrible' code. The might be done by adapting str.__format__ to use the grapheme iterator above. Then users should be able to write

>>> '{:6.6}'.format(GCString("a??ne?????o?t?a?"))
"a??ne?????"
(Note: Thunderbird properly displays characters with the marks beneath even though FireFox does not do so above or in its display of your message.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 28 07:54:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 05:54:36 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314510876.42.0.535641800114.issue12736@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FTR, with the latest Python 3.2/3.3 (narrow) I get:
   Total failures:   58 / 500 ( 12%)
   Total successes: 442 / 500 ( 88%)
and with the latest Python 3.2/3.3 (wide) I get:
   Total failures:   52 / 500 ( 10%)
   Total successes: 448 / 500 ( 90%)

----------
Added file: http://bugs.python.org/file23055/casing-results.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sun Aug 28 08:12:30 2011
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 28 Aug 2011 06:12:30 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1314511950.74.0.642867188675.issue2636@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm not sure if this belongs here, or on the Google code project page, so I'll add it in both places :)

Feature request: please change the NEW flag to something else. In five or six years (give or take), the re module will be long forgotten, compatibility with it will not be needed, so-called "new" features will no longer be new, and the NEW flag will just be silly.

If you care about future compatibility, some sort of version specification would be better, e.g. "VERSION=0" (current re module), "VERSION=1" (this regex module), "VERSION=2" (next generation). You could then default to VERSION=0 for the first few releases, and potentially change to VERSION=1 some time in the future.

Otherwise, I suggest swapping the sense of the flag: instead of "re behaviour unless NEW flag is given", I'd say "re behaviour only if OLD flag is given". (Old semantics will, of course, remain old even when the new semantics are no longer new.)

----------
nosy: +stevenjd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Aug 28 08:26:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 06:26:44 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314512804.63.0.490952078485.issue12731@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Or the re module should be *replaced* by the code from the regex module
> (but renamed to re, and with certain backwards compatibilities
> restored, probably).

This is what I meant.

> But I really hope the re module (really: the _sre extension module)
> can be fixed.

Start fixing these issues from scratch doesn't make much sense IMHO.  We could "extract" the fixes from regex and merge them in re, but then again it's probably easier to just replace the whole module.

> We should also make a habit in our docs of citing specific versions
> of the Unicode standard, and specific TR numbers and versions where 
> they apply.

While this is a good thing it's not always doable.  Usually someone reports a bug related to something specified in some standard and only that part gets fixed.  Sometimes everything else is also updated to follow the whole standard, but often this happens incrementally, so we can't say, e.g., "the re module supports Unicode x.y" unless we go through the whole standard and fix/implements everything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Sun Aug 28 08:37:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 06:37:45 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314513465.34.0.936618459321.issue12731@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> But I really hope the re module (really: the _sre extension module)
> can be fixed.

If you mean on 2.7/3.2, then I guess we could extract the fixes from regex, but we have to see if it's doable and someone will have to do it.

Also consider that the regex module is available for 2.7/3.2, so we could suggest the users to use it if they have problems with the re bugs (even if that means having an additional dependency).

ISTM that current plan is:
  * replace re with regex (and rename it) on 3.3 and fix all these bugs;
  * leave 2.7 and 3.2 with the old re and its bugs;
  * let people use the external regex module on 2.7/3.2 if they need to.

If this is not ok, maybe it should be discussed on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Sun Aug 28 11:30:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Aug 2011 09:30:03 +0000
Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
In-Reply-To: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za>
Message-ID: <E1Qxbgo-0001ZH-D5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ba5000307b5d by Nadeem Vawda in branch '2.7':
Issue #12839: Fix crash in zlib module due to version mismatch.
http://hg.python.org/cpython/rev/ba5000307b5d

New changeset cc9e794bf94f by Nadeem Vawda in branch '3.2':
Issue #12839: Fix crash in zlib module due to version mismatch.
http://hg.python.org/cpython/rev/cc9e794bf94f

New changeset b384231df332 by Nadeem Vawda in branch 'default':
Merge: #12839: Fix crash in zlib module due to version mismatch.
http://hg.python.org/cpython/rev/b384231df332

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12839>
_______________________________________

From report at bugs.python.org  Sun Aug 28 12:36:19 2011
From: report at bugs.python.org (Alexander)
Date: Sun, 28 Aug 2011 10:36:19 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1314527779.81.0.966467078899.issue12759@psf.upfronthosting.co.za>


Alexander <fredeom at mail.ru> added the comment:

I would like to make a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Sun Aug 28 14:59:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Aug 2011 12:59:15 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1314536355.68.0.81168618328.issue12720@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

And here is the next version, taking into account neologix's review.

----------
Added file: http://bugs.python.org/file23056/xattrs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Sun Aug 28 16:21:59 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Aug 2011 14:21:59 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <E1QxgFJ-0003BB-Lt@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ff6adb867f40 by Charles-Fran?ois Natali in branch '2.7':
Issue #12287: Fix a stack corruption in ossaudiodev module when the FD is
http://hg.python.org/cpython/rev/ff6adb867f40

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sun Aug 28 16:32:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Aug 2011 14:32:30 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1314541950.05.0.61820657134.issue12287@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The _socket module doesn't compile anymore on Windows:


Build started: Project: _socket, Configuration: Debug|Win32
Compiling...
socketmodule.c
29>..\Modules\socketmodule.c(1649) : warning C4013: '_PyIsSelectable_fd' undefined; assuming extern returning int
Linking...
   Creating library d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\PCbuild\\_socket_d.lib and object d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\PCbuild\\_socket_d.exp
socketmodule.obj : error LNK2019: unresolved external symbol __PyIsSelectable_fd referenced in function _sock_accept
d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\PCbuild\\_socket_d.pyd : fatal error LNK1120: 1 unresolved externals
Build log was saved at "file://d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\PCbuild\Win32-temp-Debug\_socket\BuildLog.htm"
_socket - 2 error(s), 1 warning(s)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sun Aug 28 17:27:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 15:27:35 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1314541950.05.0.61820657134.issue12287@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM17RRaViYT6qnqJXOFMhxo58T2eMiPcZgvaep7=BdNBgw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> The _socket module doesn't compile anymore on Windows:
>

Fixed (that's why I wanted a Windows expert to have a look at this patch :-).

> You might replace "#if defined(_MSC_VER)" with "#if defined
> (MS_WINDOWS)", but in another commit.

I'd rather not modify code I don't understand. Plus, I have a really
poor Windows karma...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sun Aug 28 17:56:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 15:56:44 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <20110825210917.GA3939@dbwatson.ukfsn.org>
Message-ID: <CAH_1eM14HrGNdySCF58p3A1G=LYLo1Ooi2+Y1B8VUj+=mW49yA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> That has since been changed.  I'm reading from POSIX.1-2008,
> which says:

I see.

> The warning against using values larger than 2**32 - 1 is still
> there, I presume because they would not fit in a 32-bit signed
> int.

I assume you mean 2**31 - 1.

> I take it you mean CMSG_FIRSTHDR here

Indeed.

> IIRC, I saw an implementation in old FreeBSD headers that did not
> check msg_controllen, and hence did not return NULL as RFC 3542
> requires.

Alright, that's all I wanted to know.

> That said, the fact remains that the compiler warning is spurious
> if msg_controllen can be signed on some systems, and I still
> don't think decreasing the robustness of the code (particularly
> against any future modifications to that code) just for the sake
> of silencing a spurious warning is a good thing to do.  People
> can read the comment above the "offending" line and see that the
> compiler has got it wrong.

Well, the compiler does not get it wrong. If socklen_t is defined as
an unsigned int, it has no way of knowing that it might be defined as
signed int on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:06:39 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 28 Aug 2011 16:06:39 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314547599.56.0.923858837599.issue12841@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

The patch is fine. Thank you very much for it, Sebastien. I think we have to go without a unit test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:09:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Aug 2011 16:09:17 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <E1Qxhv4-0002Eq-VF@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 852ca32eb18d by Charles-Fran?ois Natali in branch '3.2':
Issue #12287: Fix a stack corruption in ossaudiodev module when the FD is
http://hg.python.org/cpython/rev/852ca32eb18d

New changeset ad1c09b6a5b9 by Charles-Fran?ois Natali in branch 'default':
Issue #12287: Fix a stack corruption in ossaudiodev module when the FD is
http://hg.python.org/cpython/rev/ad1c09b6a5b9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:22:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 28 Aug 2011 16:22:28 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <E1Qxi7t-0003BO-Ry@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3ed2d087e70d by Charles-Fran?ois Natali in branch 'default':
Issue #12837: POSIX.1-2008 allows socklen_t to be a signed integer: re-enable
http://hg.python.org/cpython/rev/3ed2d087e70d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:27:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 16:27:38 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
	ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1314548858.74.0.74035594154.issue12837@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks for the patch.

For the record, here's Linus Torvalds' opinion on this whole socklen_t confusion:
"""
_Any_ sane library _must_ have "socklen_t" be the same size as int.  Anything else breaks any BSD socket layer stuff.  POSIX initially did make it a size_t, and I (and
       hopefully others, but obviously not too many) complained to them very loudly indeed.  Making it a size_t is completely broken, exactly because size_t very seldom is the
       same  size  as  "int" on 64-bit architectures, for example.  And it has to be the same size as "int" because that's what the BSD socket interface is.  Anyway, the POSIX
       people eventually got a clue, and created "socklen_t".  They shouldn't have touched it in the first place, but once they did they felt it had to have a named  type  for
       some unfathomable reason (probably somebody didn't like losing face over having done the original stupid thing, so they silently just renamed their blunder).
"""

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:32:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 16:32:13 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1314549133.61.0.681778017854.issue8426@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
components: +Documentation -Library (Lib)
nosy: +docs at python
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:34:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Aug 2011 16:34:59 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1314549299.14.0.296390035707.issue12720@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it normal that listxattr() succeeds but getxattr() fails with ENOTSUPP?

>>> os.listxattr("/")
[]
>>> os.getxattr("/", "foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 95] Operation not supported

This is on 2.6.38.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:39:46 2011
From: report at bugs.python.org (Kasun Herath)
Date: Sun, 28 Aug 2011 16:39:46 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1314549586.42.0.313956392178.issue12537@psf.upfronthosting.co.za>


Changes by Kasun Herath <kasunh01 at gmail.com>:


----------
nosy: +kasun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12537>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:40:42 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Aug 2011 16:40:42 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1314549299.14.0.296390035707.issue12720@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o9rzEWScuR_-x592yR_QLehSY93k=_2_L6YwaV_ryCC5w@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/8/28 Antoine Pitrou <report at bugs.python.org>:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Is it normal that listxattr() succeeds but getxattr() fails with ENOTSUPP?
>
>>>> os.listxattr("/")
> []
>>>> os.getxattr("/", "foo")
> Traceback (most recent call last):
> ?File "<stdin>", line 1, in <module>
> OSError: [Errno 95] Operation not supported

The reason you're getting ENOSUP is you have to use the proper prefix.
"user.*" for example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:49:57 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Aug 2011 16:49:57 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1314550197.88.0.463145074813.issue12720@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

After Antoine's review...

----------
Added file: http://bugs.python.org/file23057/xattrs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12720>
_______________________________________

From report at bugs.python.org  Sun Aug 28 18:56:15 2011
From: report at bugs.python.org (terry.h)
Date: Sun, 28 Aug 2011 16:56:15 +0000
Subject: [issue11969] Can't launch multiproccessing.Process on methods
In-Reply-To: <1304256356.26.0.816198245723.issue11969@psf.upfronthosting.co.za>
Message-ID: <1314550575.88.0.531271879281.issue11969@psf.upfronthosting.co.za>


Changes by terry.h <terry.herron at gmail.com>:


----------
nosy: +terry.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11969>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:16:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 17:16:28 +0000
Subject: [issue4028] Problem compiling the multiprocessing module on sunos5
In-Reply-To: <1223039660.71.0.470025758339.issue4028@psf.upfronthosting.co.za>
Message-ID: <1314551788.0.0.285623923389.issue4028@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Hello,

> there's some issues compiling the multiprocessing module on the SunOS
> I have here, where CMSG_LEN, CMSG_ALIGN, CMSG_SPACE and sem_timedwait
> are absent.

CMSG_LEN and friends should be defined by <sys/socket.h> (as required by POSIX). SunOS 5.10 man page lists them:

http://download.oracle.com/docs/cd/E19253-01/816-5173/socket.h-3head/index.html

But not the SunOS 5.9 version:
http://ewp.rpi.edu/hartford/webgen/sysdocs/C/solaris_9/SUNWaman/hman3head/socket.3head.html

> it looks like simply defining the first three macros like this works

It works, but it's probably not a good idea: if the headers don't define CMSG_LEN and friends, then FD passing will probably not work.
It'd be better to not compile multiprocessing_(sendfd|recvfd) if CMSG_LEN is not defined (patch attached).

> sem_timedwait are absent.

Hmmm.
Do you have the compilation's log?
Normally, if sem_timedwait isn't available, HAVE_SEM_TIMEDWAIT shouldn't be defined, and we should fallback to sem_trywait (by the way, calling sem_trywait multiple times until the timeout expires is not the same has calling sem_timedwait: this will fail in case of heavy contention).
So this should build correctly.

And this seems even stranger when I read Sebastian's message:
"""
so I had to commented out HAVE_SEM_TIMEDWAIT from setup.py, see:
             elif platform.startswith('sunos5'):
                  macros = dict(
                      HAVE_SEM_OPEN=1,
                      HAVE_FD_TRANSFER=1
                      )
                      #HAVE_SEM_TIMEDWAIT=0,
                  libraries = ['rt']
"""

Makes sense.
If we define HAVE_SEMTIMEDWAIT=0, then code guarded by
#ifdef HAVE_SEMTIMEDWAIT

will be compiled, and the linker won't be able to resolve sem_timedwait.
The preprocessor just checks that the symbol is defined, not that it has a non-zero value.
To sum up: could someone with a SunOS box test the attached patch, and post the compilation logs if it still fails?

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file23058/multiprocessing_sendfd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4028>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:22:43 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 17:22:43 +0000
Subject: [issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE
In-Reply-To: <1307565435.46.0.191433677292.issue12287@psf.upfronthosting.co.za>
Message-ID: <1314552163.82.0.767004146798.issue12287@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Alright, committed to 2.7, 3.2 an default.
Seems to work on all the buildbots, closing.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12287>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:22:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Aug 2011 17:22:45 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1314512804.63.0.490952078485.issue12731@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJAmoFC8KZEMXHdCFy5oXjVGc_rnzW3+zGFXntjig1VzA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

[me]
>> But I really hope the re module (really: the _sre extension module)
>> can be fixed.

[Ezio]
> Start fixing these issues from scratch doesn't make much sense IMHO. ?We could "extract" the fixes from regex and merge them in re, but then again it's probably easier to just replace the whole module.

I have changed my mind at least half-way. I am open to having regex
(with some changes, details TBD) replace re in 3.3. (I am not yet 100%
convinced, but I'm not rejecting it as strongly as I was when I wrote
that comment in this bug. See the ongoing python-dev discussion on
this topic.)

>> We should also make a habit in our docs of citing specific versions
>> of the Unicode standard, and specific TR numbers and versions where
>> they apply.
>
> While this is a good thing it's not always doable. ?Usually someone reports a bug related to something specified in some standard and only that part gets fixed. ?Sometimes everything else is also updated to follow the whole standard, but often this happens incrementally, so we can't say, e.g., "the re module supports Unicode x.y" unless we go through the whole standard and fix/implements everything.

Hm. I think that for Unicode it may actually be important enough to be
consistent in following the whole standard that we should attempt to
be consistent and not just chase bug reports. Now, we may consciously
decide not to implement a certain recommendation of the standard. E.g.
I'm not going to require that IronPython or Jython have string objects
that support O(1) indexing of code points, even (assuming PEP 393 gets
accepted) CPython will have them. But these decisions should be made
explicitly, and documented clearly.

Ideally, we need a "Unicode czar" -- a core developer whose job it is
to keep track of Python's compliance with various parts and versions
of the Unicode standard and who can nudge other developers towards
fixing bugs or implementing features, or update the documentation in
case things don't get added. (I like Tom's approach to Java 1.7, where
he submitted proposed doc fixes explaining the deviations from the
standard. Perhaps a bit passive-aggressive, but it was effective. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:27:28 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Aug 2011 17:27:28 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314510876.42.0.535641800114.issue12736@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKk=ByDn8uWiU2aUtFZsUcJibaZD41upnn4JL9tfxg2qw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Thanks Tom for such a clear explanation! I hope someone will implement
this. (Matthew, does this affect regex? I am guessing it does, for
case-insensitive matching?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:29:24 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Aug 2011 17:29:24 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1314418143.77.0.53884426718.issue12729@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJWkcJ_4t3=gjnmcGA3Ni4X4UHPYajvHS1C48B8Ta-_tQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> PEP-393 will take care of iterating by code points.

Only for CPython. IronPython/Jython will still need a separate solution.

> Where would you have other iterators go? The string module?
> Something else I have not thought of? Or something new?

Undecided. But I think we may want to create a new module which
provides various APIs specifically for apps that need care when
dealing with Unicode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:49:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 17:49:27 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1314553767.08.0.439760502398.issue12797@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I prefer a new parameter either at the end of the arglist or possibly keyword only. The idea for both variations is to let typical users ignore the option, which would be hard to do if it is part of the prime parameter. The idea for keyword only is that we might want to add other rarely used but useful options. They have no natural order, and having say, 8 positional params is pretty wretched. (I have worked with such APIs.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12797>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:58:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 17:58:12 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314554292.71.0.65648585928.issue12731@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Ideally, we need a "Unicode czar" -- a core developer whose job it is
> to keep track of Python's compliance with various parts and versions
> of the Unicode standard and who can nudge other developers towards
> fixing bugs or implementing features, or update the documentation in
> case things don't get added.

We should first do a full review of the latest Unicode standard and see what's missing.  I think there might be parts of older Unicode versions (even < Unicode 5) that are not yet implemented.  Chapter 3 is a good place where to start, but I'm not sure that's enough -- there are a few TRs that should be considered as well.
If we manage to catch up with Unicode 6, then it shouldn't be too difficult to review the changes that every new version will introduce and open an issue for each (or a single issue if the changes are limited).
FWIW I'm planning to look at the conformance of the UTF codecs and fix them (if necessary) whenever I'll have time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Sun Aug 28 19:58:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 17:58:31 +0000
Subject: [issue12805] Optimizations for bytes.join() et. al
In-Reply-To: <1313973836.25.0.316459845083.issue12805@psf.upfronthosting.co.za>
Message-ID: <1314554311.94.0.962258946645.issue12805@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/issue12805>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:01:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:01:55 +0000
Subject: [issue12815] Coverage of smtpd.py
In-Reply-To: <1314001507.51.0.00455911966964.issue12815@psf.upfronthosting.co.za>
Message-ID: <1314554515.11.0.325771870927.issue12815@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Library (Lib), Tests
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12815>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:04:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:04:28 +0000
Subject: [issue12814] Possible intermittent bug in test_array
In-Reply-To: <1313995958.58.0.615032794438.issue12814@psf.upfronthosting.co.za>
Message-ID: <1314554668.65.0.183514295085.issue12814@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Which Python version? 3.3?

----------
components: +Library (Lib), Tests
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12814>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:06:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:06:32 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1314554792.94.0.677033521966.issue12808@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Library (Lib), Tests
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:08:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:08:47 +0000
Subject: [issue12816] smtpd uses library outside of the standard libraries
In-Reply-To: <1314002733.23.0.776557128792.issue12816@psf.upfronthosting.co.za>
Message-ID: <1314554927.23.0.127722886714.issue12816@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/issue12816>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:27:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:27:14 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314556034.18.0.937498647344.issue12829@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A note for anyone else: David is actually using the xml.parsers.expat module, which uses the now undocumented pyexpat module, whose direct use is deprecated.

David: Have you tested with 3.1 or 3.2? (I am about to try on Windows ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:32:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:32:33 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314556353.21.0.53226385251.issue12829@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Running with IDLE on Windows, I get no crash or uncaught exception but got these printed lines:

An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element
Line number: 1
An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element
Line number: 1
An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element
An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element
Line number: 1
An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element
Line number: 1
An error occurred during XML parsing.  Error ID: 9.  Error message: junk after document element

Is this the correct, expected output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:39:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:39:16 +0000
Subject: [issue12836] ctypes.cast() creates circular reference in original
	object
In-Reply-To: <1314222835.27.0.518600149254.issue12836@psf.upfronthosting.co.za>
Message-ID: <1314556756.0.0.715026954246.issue12836@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What action are you suggesting? Change ctypes code or its doc or something else. If the doc, please suggest a specific change.

Can you test on 3.x?

----------
nosy: +terry.reedy
title: cast() creates circular reference in original object -> ctypes.cast() creates circular reference in original object

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12836>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:48:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 18:48:48 +0000
Subject: [issue12843] file object read* methods in append mode overflows
In-Reply-To: <1314313743.28.0.803214021161.issue12843@psf.upfronthosting.co.za>
Message-ID: <1314557328.58.0.328910781393.issue12843@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> I have confirmed that this only happens in windows.

This would literally mean that you tested on several other systems. Did you actually mean 'I have only confirmed that this happens in Windows.", that you only tested on Windows?

The 2.6 series is in security-fix only mode.

----------
nosy: +terry.reedy
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12843>
_______________________________________

From report at bugs.python.org  Sun Aug 28 20:56:36 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 28 Aug 2011 18:56:36 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314557796.37.0.261083327202.issue12736@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The regex module currently uses simple case-folding, although I'm working towards full case-folding, as listed in http://www.unicode.org/Public/UNIDATA/CaseFolding.txt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sun Aug 28 21:19:28 2011
From: report at bugs.python.org (Shubhojeet Ghosh)
Date: Sun, 28 Aug 2011 19:19:28 +0000
Subject: [issue12849] urllib2 headers issue
Message-ID: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za>


New submission from Shubhojeet Ghosh <shubhojeet.ghosh at yahoo.com>:

There seems to be an issue with urllib2
The headers defined does not match with the physical data packet (from wireshark). Other header parameters such as User Agent, cookie works fine.
Here is an example of a failure:

Python Code:
import urllib2

url = "http://www.python.org"

req = urllib2.Request(url)
req.add_header('Connection',"keep-alive")
u = urllib2.urlopen(req)


Wireshark:
GET / HTTP/1.1

Accept-Encoding: identity

Connection: close

Host: www.python.org

User-Agent: Python-urllib/2.6

----------
components: IO
messages: 143120
nosy: orsenthil, shubhojeet.ghosh
priority: normal
severity: normal
status: open
title: urllib2 headers issue
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12849>
_______________________________________

From report at bugs.python.org  Sun Aug 28 22:00:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 28 Aug 2011 20:00:59 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314561659.32.0.6960965875.issue12841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Should this bug be fixed in 3.3, or 2.7+3.2+3.3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Sun Aug 28 22:37:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 20:37:44 +0000
Subject: [issue12846] unicodedata.normalize turkish letter problem
In-Reply-To: <1314366807.15.0.0695174585608.issue12846@psf.upfronthosting.co.za>
Message-ID: <1314563864.3.0.569661974339.issue12846@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You are doing two different things to the original string: normalizing and encoding to ascii with errors ignored. Each should be tested separately.
On 3.2:
import unicodedata
s1 = "?f?r?k?? a?a? ve ?sl?k?? ?e?me"
s2 =  unicodedata.normalize('NFKD', s1)
print(s2)
print(s2.encode('ascii','ignore'))

#prints
u?fu?ru?kc?u? ag?ac? ve ?sl?kc?? c?es?me
b'ufurukcu agac ve slkc cesme'

The dotless i (==  '\u0131') in s2 does not encode to ascii and is properly dropped when the error is ignored.

I believe you are mistaken to think that unicodedata.normalize *should* turn turkish letter "?" == "\u131" into "i". Unicodedata.decomposition("?") returns an empty string, as it should (see below) because that character has no decomposition normalization in Unicode 6. So I am closing this issue as invalid.

Here is the entry from
http://www.unicode.org/Public/6.0.0/ucd/UnicodeData.txt
0131;LATIN SMALL LETTER DOTLESS I;Ll;0;L;;;;;N;;;0049;;0049
That is explained here
http://www.unicode.org/reports/tr44/tr44-6.html#UnicodeData.txt
The blank after 'L' (bidi class - left to right) is for decomposition type and mapping. There is none, so unicodedata.decomposition is correct. The last three entries are for uppercase, lowercase, and titlecase conversions. Those are different from normalizations.

To reinforce this,
http://www.unicode.org/Public/6.0.0/ucd/NormalizationTest.txt
says explicitly
"@Part1 # Character by character test
# All characters not explicitly occurring in c1 of Part 1 have identical NFC, D, KC, KD forms."
'c1' is column 1, starting from 1.
In this list, 0130 is followed by 0132, omitting 0131, so the line above applies.

After writing this, I discovered that Lib/test/test_normalization.py runs the complete test specified in NormalizationTest.txt for code points that have and do not have normalization forms.

Side note" Python 2.6 is in security-fix-only mode.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12846>
_______________________________________

From report at bugs.python.org  Sun Aug 28 22:55:21 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Aug 2011 20:55:21 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1314564921.99.0.483008835884.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

> But I think we may want to create a new module which
provides various APIs specifically for apps that need care when
dealing with Unicode.

I have started thinking that way too -- perhaps "unitools"?
It could contain the code point iterator for the benefit of other implementations. Actually, since 393 still allows insertion of surrogate values, it might not be completely useless for CPython either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12729>
_______________________________________

From report at bugs.python.org  Sun Aug 28 23:01:50 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 28 Aug 2011 21:01:50 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314475496.58.0.92504976311.issue12736@psf.upfronthosting.co.za>
Message-ID: <7030.1314565285@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote on Sat, 27 Aug 2011 20:04:56 -0000: 

>> Neither am I.  Even in "old-style" English with ae and oe, one wrote
>> ?GYPT and ?SIR all caps but ?gypt and ?sir in titlecase, not *Aegypt or
>> *Aesir.  Similarly with ?NOLOGY / ?nology / ?nology, never *Oenology.

> Trying to disprove you a bit:
> http://ecx.images-amazon.com/images/I/51G6CH9XFFL._SL500_AA300_.jpg
> http://ecx.images-amazon.com/images/I/51k7TmosPdL._SL500_AA300_.jpg
> http://ecx.images-amazon.com/images/I/518UzMeLFCL._SL500_AA300_.jpg

> but classical typographies seem to write either the uppercase ? or the
> lowercase ?.

That's what I meant: one only ever sees ?ufs or ?UFS, never OEUFS.
French doesn't fit into ISO 8859-1.  That's one of the changes to
ISO-8859-15 compared with ISO-8859-1 (and Unicode):

    iso-8859-1   A4  ?  U+00A4  ? ? ?  \N{CURRENCY SIGN}
    iso-8859-15  A4  ?  U+20AC  ? ? ?  \N{EURO SIGN}

    iso-8859-1   A6  ?  U+00A6  ? ? ?  \N{BROKEN BAR}
    iso-8859-15  A6  ?  U+0160  ? ? ?  \N{LATIN CAPITAL LETTER S WITH CARON}

    iso-8859-1   A8  ?  U+00A8  ? ? ?  \N{DIAERESIS}
    iso-8859-15  A8  ?  U+0161  ? ? ?  \N{LATIN SMALL LETTER S WITH CARON}

    iso-8859-1   B4  ?  U+00B4  ? ? ?  \N{ACUTE ACCENT}
    iso-8859-15  B4  ?  U+017D  ? ? ?  \N{LATIN CAPITAL LETTER Z WITH CARON}

    iso-8859-1   B8  ?  U+00B8  ? ? ?  \N{CEDILLA}
    iso-8859-15  B8  ?  U+017E  ? ? ?  \N{LATIN SMALL LETTER Z WITH CARON}

    iso-8859-1   BC  ?  U+00BC  ? ? ?  \N{VULGAR FRACTION ONE QUARTER}
    iso-8859-15  BC  ?  U+0152  ? ? ?  \N{LATIN CAPITAL LIGATURE OE}

    iso-8859-1   BD  ?  U+00BD  ? ? ?  \N{VULGAR FRACTION ONE HALF}
    iso-8859-15  BD  ?  U+0153  ? ? ?  \N{LATIN SMALL LIGATURE OE}

    iso-8859-1   BE  ?  U+00BE  ? ? ?  \N{VULGAR FRACTION THREE QUARTERS}
    iso-8859-15  BE  ?  U+0178  ? ? ?  \N{LATIN CAPITAL LETTER Y WITH DIAERESIS}

> That said, I wonder why Unicode even includes ligatures like ?. Sounds
> like mission creep to me (and horrible annoyances for people like us).

I'm pretty sure that typographic ligatures are there for roundtripping
with legacy encodings.  I believe that ?/? is the only code point
with ligature in its name that you're "supposed" to still use, and
that all others should be figured out by modern fonting software.

--tom

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Sun Aug 28 23:09:56 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 28 Aug 2011 21:09:56 +0000
Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
In-Reply-To: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za>
Message-ID: <1314565796.98.0.689305801049.issue12839@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Done. Once again, thanks for the report and the patch!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12839>
_______________________________________

From report at bugs.python.org  Mon Aug 29 00:02:21 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Aug 2011 22:02:21 +0000
Subject: [issue12843] file object read* methods in append mode overflows
In-Reply-To: <1314313743.28.0.803214021161.issue12843@psf.upfronthosting.co.za>
Message-ID: <1314568941.99.0.720132551991.issue12843@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You should call the .flush() method when switching from writes to reads.

Nothing really overflows, but the fread() function may return uninitialized memory.  In versions 2.x, python uses the fopen, fread and fwrite function (from the C library) and is subject to their limitations.

The exact behaviour is undefined, and it is well possible that it only happens on Windows.  See also the discussion in #7952.

This issue does not exist in versions 3.x, where file functions have been rewritten.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12843>
_______________________________________

From report at bugs.python.org  Mon Aug 29 01:26:13 2011
From: report at bugs.python.org (douglas bagnall)
Date: Sun, 28 Aug 2011 23:26:13 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314573973.14.0.907780455447.issue12754@psf.upfronthosting.co.za>


douglas bagnall <douglas at paradise.net.nz> added the comment:

Earlier this year I wrote Python wrappers for a number of generators:

https://github.com/douglasbagnall/riffle

They are mostly cryptographic stream ciphers from the ESTREAM[1] project, but I was also interested in dSFMT[2], which is a SIMD optimised descendant of MT19937 which runs several times faster and directly produces doubles using cunning bit tricks.

[1]http://www.ecrypt.eu.org/stream/
[2]http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/#dSFMT

Wrapped in Python, the stream ciphers ran about as fast as MT19937 on my laptop, while dSFMT took about two thirds the time to run a "random();random();random();..." test.  For a slightly more realistic test ("sum(random() for x in range(N))"), the performance levelled right off.  As expected.

The stream cipher generators have some good properties.  They generally generate random bytes using something analogous to hash('%s%s' % seed, counter), which means different seeds produce well separated streams, and to skip forward or back in the stream, you just adjust the counter.  This would allow the reinstatement of Random()'s stream-skipping function, which some people (e.g. L'Ecuyer) think is important. (incidentally, the MT people have come up with a jump-ahead algorithm for MT http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/JUMP/index.html).

Of the ciphers I tried, the chacha/salsa family and sosemanuk had the best combination of good testing and portable, reasonably fast, openly licensed C implementations.  HC128 and snow2 also perform well.

The chacha code is shorter than sosemanuk, so I would choose that.  It is used as a primitive in the BLAKE SHA3 candidate, which is a vote of confidence and an attractor of testing for the algorithm.

----------
nosy: +dbagnall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Mon Aug 29 02:03:12 2011
From: report at bugs.python.org (douglas bagnall)
Date: Mon, 29 Aug 2011 00:03:12 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314576192.34.0.549599238846.issue12754@psf.upfronthosting.co.za>


douglas bagnall <douglas at paradise.net.nz> added the comment:

A bit more on the state size and period of the stream ciphers.

Chacha and Salsa use 64 bytes (512 bits) of state (vs ~2.5kB for MT19937).

Its counter is 64 bits, and its seed can be 320 bits (in cipher-speak, the seed is split between a 256 bit key and a 64 bit IV).

Each counter iteration produces 64 random bytes, or 8 doubles, so for any seed, you get a cycle of 2 ** 67, which would last in the order of 100 thousand years on current PCs.

Some of the other ciphers I looked at have smaller seeds and states, and some produce fewer bytes per iteration, but I don't think any of them will result in a cycle of smaller than 2 ** 64.

PS: Regarding the discussion of something like Random.getrandbytes(n): +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Mon Aug 29 02:47:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Aug 2011 00:47:17 +0000
Subject: [issue12846] unicodedata.normalize turkish letter problem
In-Reply-To: <1314366807.15.0.0695174585608.issue12846@psf.upfronthosting.co.za>
Message-ID: <1314578837.03.0.0135041151805.issue12846@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12846>
_______________________________________

From report at bugs.python.org  Mon Aug 29 05:17:23 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Aug 2011 03:17:23 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314587843.64.0.517986370152.issue12754@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks Douglas.   Can you say what the cryptographic guarantees are for Chacha and Salsa (seeing a stream of randoms doesn't allow you to do deduce internal state, previous randoms, or future randoms)?  Is it suitably strong for gaming (dealing poker hands, lottery numbers, etc)?

I'm not sure I follow the notes on state size.  Is it 320 bits + 64 bits or is it 512 bits?  Also, I'm not sure that the smaller state is an advantage that users care about (unless they are pickling many instances of the prngs).

It's okay for jumpahead() to reappear in generators that support it, but   that method can't be a mandatory part of the Random API because it doesn't make sense for many PRNGs where a jumpahead function isn't known.

With respect to the SIMD optimizations and longlong to double operations, I'm curious to take a look at how it was done yet wonder if there is a provable, portable implementation and also wonder if it is worth it (the speed of generating a random() tends to be dwarfed by surrounding code that actually uses the result -- allocating the python object, etc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Mon Aug 29 08:29:18 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 29 Aug 2011 06:29:18 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314599358.83.0.160571656633.issue12754@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Mon Aug 29 09:14:51 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 29 Aug 2011 07:14:51 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314602091.35.0.137892228608.issue12841@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Yes, it should be fixed in all affected branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Mon Aug 29 10:19:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 08:19:29 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314605969.68.0.178361290813.issue12841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The patch looks ok. Can you push it Lars?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Mon Aug 29 11:25:41 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 29 Aug 2011 09:25:41 +0000
Subject: [issue12850] [PATCH] stm.atomic
Message-ID: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Here is (attached) a minimal patch to the core trunk CPython to allow extension modules to take over control of acquiring and releasing the GIL, as proposed here:

http://mail.python.org/pipermail/python-dev/2011-August/113248.html

With this patch, it is possible to write an independent extension module that offers the basic STM "with atomic" blocks:

https://bitbucket.org/arigo/cpython-withatomic/raw/default/stm

As Guido hints in the mail above, more experimentation is needed before we know if the idea can really fly, notably if there are annoying issues with existing locks causing random deadlocks.

----------
components: Interpreter Core
files: stm.diff
keywords: patch
messages: 143132
nosy: arigo
priority: normal
severity: normal
status: open
title: [PATCH] stm.atomic
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23059/stm.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 11:32:19 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 09:32:19 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314610339.42.0.98405056164.issue12850@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 11:41:39 2011
From: report at bugs.python.org (douglas bagnall)
Date: Mon, 29 Aug 2011 09:41:39 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314610899.91.0.754712296355.issue12754@psf.upfronthosting.co.za>


douglas bagnall <douglas at paradise.net.nz> added the comment:

I am no kind of crypto expert, but from what I read, there are no known attacks on chacha8 or salsa20/12 better than brute-forcing the key, and distinguishing the stream from random or deducing state would be considered an attack.  There's a summary of the ESTREAM cipher's security here:

http://cr.yp.to/streamciphers/attacks.html

-- be aware it was written by the chacha/salsa author, so may be biased.

> I'm not sure I follow the notes on state size.  Is it 320 bits + 64 bits or is it 512 bits?

Yeah. The state is contained u32[16], so the 512 is sizeof(that).  320 + 64 is the number of states I can see it getting into from the seeds and cycles.  I imagine the discrepancy is a convenience, just as the mt19937 struct uses a few more than 19937 bits.

> With respect to the SIMD optimizations and longlong to double operations, I'm curious to take a look at how it was done yet wonder if there is a provable, portable implementation and also wonder if it is worth it (the speed of generating a random() tends to be dwarfed by surrounding code that actually uses the result -- allocating the python object, etc).

I agree that it is not worth it.  However the dSFMT generator does seem quite portable and fall back to non-SIMD code (which is allegedly still faster), and its distribution is supposedly a bit better -- though not as good as WELL.

The bit magic is quite simple: if you set the top 12 bits to 0x7ff and randomise the other 52, you get a double in the range [1, 2).  So you subtract 1.  It costs one bit relative to the current method, which is equivalent to 53 bit fixed point.  They explain it reasonably well in these slides:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/dSFMT-slide-e.pdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Mon Aug 29 11:46:41 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 29 Aug 2011 09:46:41 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314611201.27.0.313294014911.issue12850@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

NB. I know that my stmmodule.c contains a gcc-ism: it uses a __thread global variable.  I plan to fix this in future versions :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 11:58:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 29 Aug 2011 09:58:43 +0000
Subject: [issue12851] ctypes: getbuffer() never provides strides
Message-ID: <1314611923.07.0.681765586879.issue12851@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

PyCData_NewGetBuffer() must provide strides information if requested,
e.g. in response to a PyBUF_FULL_RO request.

----------
assignee: skrah
components: Extension Modules
messages: 143135
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes: getbuffer() never provides strides
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12851>
_______________________________________

From report at bugs.python.org  Mon Aug 29 13:43:29 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Aug 2011 11:43:29 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314618209.16.0.460315141118.issue12850@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Rather than exposing the function pointers directly to the linker, I'd be happier with a function based API, with the pointer storage then being made static inside ceval.c.

/* Each function returns the old func, or NULL on failure */
_PyEval_GIL_func _PyEval_replace_take_GIL(_PyEval_GIL_func take_gil); _PyEval_GIL_func _PyEval_replace_drop_GIL(_PyEval_GIL_func drop_gil); 


The redirection code (sans error checking) would then look like:

old_take_gil = _PyEval_replace_take_GIL(stm_take_gil);
old_drop_gil = _PyEval_replace_drop_GIL(stm_drop_gil);

Currently they'd just replace the statics and would never fail, but it provides looser coupling regardless.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 13:49:54 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 29 Aug 2011 11:49:54 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314618594.32.0.967367939363.issue12850@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

I suppose I'm fine either way, but do you have a reason for not exposing the variables to the linker?  Some Windows-ism were such exposed variables are slower to access than static ones, maybe?  The point is that they are kind of "internal use only" anyway, so designing nice APIs around them looks overkill to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 13:50:12 2011
From: report at bugs.python.org (Adal Chiriliuc)
Date: Mon, 29 Aug 2011 11:50:12 +0000
Subject: [issue12742] Add support for CESU-8 encoding
In-Reply-To: <1313157699.02.0.414540020258.issue12742@psf.upfronthosting.co.za>
Message-ID: <1314618612.31.0.507409207002.issue12742@psf.upfronthosting.co.za>


Adal Chiriliuc <adal.chiriliuc at gmail.com> added the comment:

It's an internal web API at the place I work for.

To be able to use it from Python in some form, I did an workaround in which I just stripped everything outside BMP:

# replace characters outside BMP with 'REPLACEMENT CHARACTER' (U+FFFD)
def cesu8_to_utf8(text):
....result = ""
....index = 0
....length = len(text)
....while index < length:
........if text[index] < "\xf0":
............result += text[index]
............index  += 1
........else:
............result += "\xef\xbf\xbd"  # u"\ufffd".encode("utf8")
............index  += 4
....return result

Now that I look at the workaround again, I'm not even sure it's about CESU-8 (it strips Unicode chars encoded to 4 bytes, not 2 pairs of 3 bytes surrogates).

However I can see why there would be little interest in adding this encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12742>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:21:53 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Aug 2011 12:21:53 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1314620513.9.0.291454302914.issue6715@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/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:22:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Aug 2011 12:22:30 +0000
Subject: [issue12742] Add support for CESU-8 encoding
In-Reply-To: <1313157699.02.0.414540020258.issue12742@psf.upfronthosting.co.za>
Message-ID: <1314620550.84.0.958824280227.issue12742@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm going to reject this.  If people need it, they can always implement it using the codecs module.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12742>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:30:08 2011
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 29 Aug 2011 12:30:08 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
Message-ID: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hi,

During the regress tests on OpenBSD, test_posix.test_fdlistdir() segfault.

Details:

$ ./python ./Tools/scripts/run_tests.py test_posix
/home/remi/dev/cpython_test/python -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-network,-urlfetch,-audio,-gui test_posix
Using random seed 7449086
[1/1] test_posix
Fatal Python error: Segmentation fault

Current thread 0x0000000209419000:
  File "/home/remi/dev/cpython_test/Lib/test/test_posix.py", line 456 in test_fdlistdir
  File "/home/remi/dev/cpython_test/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/home/remi/dev/cpython_test/Lib/unittest/case.py", line 441 in run
  File "/home/remi/dev/cpython_test/Lib/unittest/case.py", line 493 in __call__
  File "/home/remi/dev/cpython_test/Lib/unittest/suite.py", line 105 in run
  File "/home/remi/dev/cpython_test/Lib/unittest/suite.py", line 67 in __call__
  File "/home/remi/dev/cpython_test/Lib/unittest/suite.py", line 105 in run
  File "/home/remi/dev/cpython_test/Lib/unittest/suite.py", line 67 in __call__
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1192 in run
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1293 in _run_suite
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1327 in run_unittest
  File "/home/remi/dev/cpython_test/Lib/test/test_posix.py", line 1022 in test_main
  File "/home/remi/dev/cpython_test/Lib/test/regrtest.py", line 1139 in runtest_inner
  File "/home/remi/dev/cpython_test/Lib/test/regrtest.py", line 915 in runtest
  File "/home/remi/dev/cpython_test/Lib/test/regrtest.py", line 439 in main
  File "/home/remi/dev/cpython_test/Lib/test/regrtest.py", line 1717 in <module>
  File "/home/remi/dev/cpython_test/Lib/runpy.py", line 73 in _run_code
  File "/home/remi/dev/cpython_test/Lib/runpy.py", line 160 in _run_module_as_main
Traceback (most recent call last):
  File "/home/remi/dev/cpython_test/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/remi/dev/cpython_test/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/remi/dev/cpython_test/Lib/test/__main__.py", line 13, in <module>
    regrtest.main()
  File "/home/remi/dev/cpython_test/Lib/test/regrtest.py", line 683, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_posix: Exit code -11
[98138 refs]

$ ./python Lib/test/test_posix.py
testNoArgFunctions (__main__.PosixTester) ... ok
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_chflags (__main__.PosixTester) ... ok
test_chown (__main__.PosixTester) ... ok
test_confstr (__main__.PosixTester) ... ok
test_cpu_set_basic (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_cpu_set_bitwise (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_cpu_set_cmp (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_environ (__main__.PosixTester) ... ok
test_faccessat (__main__.PosixTester) ... ok
test_fchmodat (__main__.PosixTester) ... ok
test_fchown (__main__.PosixTester) ... ok
test_fchownat (__main__.PosixTester) ... ok
test_fdlistdir (__main__.PosixTester) ... zsh: segmentation fault (core dumped)  ./python Lib/test/test_posix.py

########
with gdb
########

$ gdb ./python
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd5.0"...
(gdb) run Lib/test/test_posix.py
Starting program: /home/remi/dev/cpython_test/python Lib/test/test_posix.py
testNoArgFunctions (__main__.PosixTester) ... ok
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_chflags (__main__.PosixTester) ... ok
test_chown (__main__.PosixTester) ... ok
test_confstr (__main__.PosixTester) ... ok
test_cpu_set_basic (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_cpu_set_bitwise (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_cpu_set_cmp (__main__.PosixTester) ... skipped "don't have sched affinity support"
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_environ (__main__.PosixTester) ... ok
test_faccessat (__main__.PosixTester) ... ok
test_fchmodat (__main__.PosixTester) ... ok
test_fchown (__main__.PosixTester) ... ok
test_fchownat (__main__.PosixTester) ... ok
test_fdlistdir (__main__.PosixTester) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 21658, thread 0x20a519000]
_readdir_unlocked (dirp=0xafb0e80, result=0x7f7ffffd7ac0, skipdeleted=1)
    at /usr/src/lib/libc/gen/readdir.c:44
44                      if (dirp->dd_loc >= dirp->dd_size)
(gdb) bt
#0  _readdir_unlocked (dirp=0xafb0e80, result=0x7f7ffffd7ac0, skipdeleted=1)
    at /usr/src/lib/libc/gen/readdir.c:44
#1  0x000000020f160f51 in readdir (dirp=0xafb0e80) at /usr/src/lib/libc/gen/readdir.c:80
#2  0x00000000004af33b in posix_fdlistdir (self=Variable "self" is not available.
) at ./Modules/posixmodule.c:2832
#3  0x00000000004694f4 in PyEval_EvalFrameEx (f=0x20973fc30, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4000
#4  0x000000000046a71c in PyEval_EvalFrameEx (f=0x208aa4c30, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4088
#5  0x000000000046b954 in PyEval_EvalCodeEx (_co=0x2052c2640, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#6  0x0000000000467d8b in PyEval_EvalFrameEx (f=0x20e52a830, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4098
#7  0x000000000046b954 in PyEval_EvalCodeEx (_co=0x2052c27c0, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#8  0x000000000051a243 in function_call (func=0x2024054b0, arg=0x20a882600, kw=0x20a8836c8)
    at Objects/funcobject.c:629
#9  0x00000000004ec5bf in PyObject_Call (func=0x2024054b0, arg=0x20a882600, kw=0x20a8836c8)
    at Objects/abstract.c:2149
#10 0x0000000000465936 in PyEval_EvalFrameEx (f=0x20a884660, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4315
#11 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x2052c2ac0, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#12 0x000000000051a243 in function_call (func=0x202405620, arg=0x20a882588, kw=0x0)
    at Objects/funcobject.c:629
#13 0x00000000004ec5bf in PyObject_Call (func=0x202405620, arg=0x20a882588, kw=0x0)
    at Objects/abstract.c:2149
#14 0x0000000000506ed9 in method_call (func=0x202405620, arg=0x20a87f7d0, kw=0x0)
    at Objects/classobject.c:318
#15 0x00000000004ec5bf in PyObject_Call (func=0x20bf0cba0, arg=0x20a87f7d0, kw=0x0)
    at Objects/abstract.c:2149
#16 0x000000000042a7e6 in slot_tp_call (self=Variable "self" is not available.
) at Objects/typeobject.c:5194
#17 0x00000000004ec5bf in PyObject_Call (func=0x20bf25a70, arg=0x20a87f7d0, kw=0x0)
    at Objects/abstract.c:2149
#18 0x00000000004614ef in PyEval_EvalFrameEx (f=0x20e52bc30, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4220
#19 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x20240e1c0, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#20 0x000000000051a243 in function_call (func=0x20240dec0, arg=0x20a882498, kw=0x20a883580)
    at Objects/funcobject.c:629
#21 0x00000000004ec5bf in PyObject_Call (func=0x20240dec0, arg=0x20a882498, kw=0x20a883580)
    at Objects/abstract.c:2149
#22 0x0000000000465936 in PyEval_EvalFrameEx (f=0x20a884260, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4315
#23 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x2023f5f40, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#24 0x000000000051a243 in function_call (func=0x20240dd50, arg=0x20bf0cab0, kw=0x0)
    at Objects/funcobject.c:629
#25 0x00000000004ec5bf in PyObject_Call (func=0x20240dd50, arg=0x20bf0cab0, kw=0x0)
    at Objects/abstract.c:2149
#26 0x0000000000506ed9 in method_call (func=0x20240dd50, arg=0x20bf25290, kw=0x0)
    at Objects/classobject.c:318
#27 0x00000000004ec5bf in PyObject_Call (func=0x20bf0cb28, arg=0x20bf25290, kw=0x0)
    at Objects/abstract.c:2149
#28 0x000000000042a7e6 in slot_tp_call (self=Variable "self" is not available.
) at Objects/typeobject.c:5194
#29 0x00000000004ec5bf in PyObject_Call (func=0x20bf25300, arg=0x20bf25290, kw=0x0)
    at Objects/abstract.c:2149
#30 0x00000000004614ef in PyEval_EvalFrameEx (f=0x20e52c830, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4220
#31 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x20240e1c0, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#32 0x000000000051a243 in function_call (func=0x20240dec0, arg=0x20bf0c9c0, kw=0x20a883438)
    at Objects/funcobject.c:629
#33 0x00000000004ec5bf in PyObject_Call (func=0x20240dec0, arg=0x20bf0c9c0, kw=0x20a883438)
    at Objects/abstract.c:2149
#34 0x0000000000465936 in PyEval_EvalFrameEx (f=0x20a884060, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4315
#35 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x2023f5f40, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#36 0x000000000051a243 in function_call (func=0x20240dd50, arg=0x20bf0c948, kw=0x0)
    at Objects/funcobject.c:629
#37 0x00000000004ec5bf in PyObject_Call (func=0x20240dd50, arg=0x20bf0c948, kw=0x0)
    at Objects/abstract.c:2149
#38 0x0000000000506ed9 in method_call (func=0x20240dd50, arg=0x20bf05fb0, kw=0x0)
---Type <return> to continue, or q <return> to quit---
    at Objects/classobject.c:318
#39 0x00000000004ec5bf in PyObject_Call (func=0x2049d8150, arg=0x20bf05fb0, kw=0x0)
    at Objects/abstract.c:2149
#40 0x000000000042a7e6 in slot_tp_call (self=Variable "self" is not available.
) at Objects/typeobject.c:5194
#41 0x00000000004ec5bf in PyObject_Call (func=0x20bf05df0, arg=0x20bf05fb0, kw=0x0)
    at Objects/abstract.c:2149
#42 0x00000000004614ef in PyEval_EvalFrameEx (f=0x2015e2c30, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4220
#43 0x000000000046a71c in PyEval_EvalFrameEx (f=0x20bea9830, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4088
#44 0x000000000046a71c in PyEval_EvalFrameEx (f=0x20f636030, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4088
#45 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x209f27400, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#46 0x0000000000467d8b in PyEval_EvalFrameEx (f=0x20afb5c30, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4098
#47 0x000000000046a71c in PyEval_EvalFrameEx (f=0x20cde2df0, throwflag=Variable "throwflag" is not available.
) at Python/ceval.c:4088
#48 0x000000000046b954 in PyEval_EvalCodeEx (_co=0x208dc1b80, globals=Variable "globals" is not available.
) at Python/ceval.c:3375
#49 0x000000000046babb in PyEval_EvalCode (co=Variable "co" is not available.
) at Python/ceval.c:770
#50 0x000000000048d3e7 in run_mod (mod=Variable "mod" is not available.
) at Python/pythonrun.c:1793
#51 0x000000000048d4ee in PyRun_FileExFlags (fp=0x20f5dd8e0,
    filename=0x209f123b0 "Lib/test/test_posix.py", start=257, globals=0x2073b0580,
    locals=0x2073b0580, closeit=1, flags=0x7f7ffffdac50) at Python/pythonrun.c:1750
#52 0x00000000004900bf in PyRun_SimpleFileExFlags (fp=0x20f5dd8e0,
    filename=0x209f123b0 "Lib/test/test_posix.py", closeit=1, flags=0x7f7ffffdac50)
    at Python/pythonrun.c:1275
#53 0x00000000004a2990 in Py_Main (argc=Variable "argc" is not available.
) at Modules/main.c:299
#54 0x0000000000415cba in main (argc=2, argv=0x7f7ffffdad18) at ./Modules/python.c:59


Don't hesitate to ask if you need more information.
Thanks a lot for your help.

Cheers,
Remi.

----------
components: Library (Lib)
files: test_fdlistdir_segfault_openbsd
messages: 143140
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_posix.test_fdlistdir() segfault on OpenBSD
versions: Python 3.3
Added file: http://bugs.python.org/file23060/test_fdlistdir_segfault_openbsd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:39:38 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 29 Aug 2011 12:39:38 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314621578.14.0.408744643223.issue12852@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Does it always segfault?

Try:
./python -c 'import os; print(os.fdlistdir(os.open("/tmp", os.O_RDONLY)))'

with various values for /tmp.

>From what I can see, the code for fdlistdir is basically the same as os.listdir().
If possible, try os.listdir() as well.

----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:46:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Aug 2011 12:46:11 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314621971.47.0.557414780772.issue12850@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/issue12850>
_______________________________________

From report at bugs.python.org  Mon Aug 29 14:59:29 2011
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 29 Aug 2011 12:59:29 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314622769.4.0.308294190594.issue12852@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,

thanks for your response.

Yes it always segfault:

$ ./python -c 'import os; print(os.fdlistdir(os.open("/tmp", os.O_RDONLY)))'
zsh: segmentation fault (core dumped)  ./python -c 'import os; print(os.fdlistdir(os.open("/tmp", os.O_RDONLY)))'

$ ./python -c 'import os; print(os.fdlistdir(os.open("/tmp/test_python", os.O_RDONLY)))'
zsh: segmentation fault (core dumped)  ./python -c 

$ ./python -c 'import os; print(os.fdlistdir(os.open("/var/tmp", os.O_RDONLY)))'
zsh: segmentation fault (core dumped)  ./python -c 'import os; print(os.fdlistdir(os.open("/var/tmp", os.O_RDONLY)))

With listdir it correctly works:

$ ./python -c 'import os; print(os.listdir("/tmp"))'                          
['.X11-unix', '.ICE-unix', 'test_python', 'tmpl80ewt', 'tmpled292']
[42658 refs]

$ ./python -c 'import os; print(os.listdir("/tmp/test_python/"))'
['1file', '2file', '3file']
[42658 refs]

$ ./python -c 'import os; print(os.listdir("/var/tmp/"))'        
['vi.recover', 'kdecache-remi']
[42658 refs]

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 15:10:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 13:10:22 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314623422.08.0.292929054948.issue12852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like a kernel bug !? Are you able to write a C script reproducing the problem? If not, I can try to write it.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 15:13:36 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 29 Aug 2011 13:13:36 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314623616.3.0.425846172378.issue12852@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> It looks like a kernel bug !?

That's what I thought given that it appears to be working on all the other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 15:13:57 2011
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Mon, 29 Aug 2011 13:13:57 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1313098784.96.0.996919907442.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314623637.88.0.494858727365.issue12736@psf.upfronthosting.co.za>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

?, ? or even & are historically ligatures or "ligatured forms".
In the French typography, they are "single plain letters" and
they belong the group of the 42 letters used in the French
typography.
Typographically speaking, using "oe" instead of "?" is considered
as a mistake, while not using the ligatured forms for the groups
of letters like ff, ffi, ffl, fj, et, st is acceptable.

Microsoft with cp1252, Apple with mac-roman, Adobe and all
foundries and now "Unicode" are working correctly.

It should be noted, when "TeX" moved from the ascii to iso-8859-1
(more precisely "CorkEncoding") as default encoding, "they" saw
the problem and introduced the \oe or \OE commands.

>From my understanding and my point of view on the subject, ISO has
somehow recognized his mistake by introducing iso-8859-15.
Infortunatelly, it was too late.

To the subject: ?dipe: correct, Oedipe, OEdipe: incorrect.

Without beeing an expert on that field, all the informations
one can find on Wikipedia (French) regarding questions about
typography are generally correct.

----------
nosy: +Jean-Michel.Fauth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Mon Aug 29 15:21:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 13:21:06 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314623637.88.0.494858727365.issue12736@psf.upfronthosting.co.za>
Message-ID: <1314623915.3551.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> ?, ? or even & are historically ligatures or "ligatured forms".
> In the French typography, they are "single plain letters" and
> they belong the group of the 42 letters used in the French
> typography.
> Typographically speaking, using "oe" instead of "?" is considered
> as a mistake,

It's not only "typographically speaking", it's really a spelling error,
even in hand-written text :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Mon Aug 29 15:29:35 2011
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 29 Aug 2011 13:29:35 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314624575.77.0.987432354255.issue12852@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,

I tested with this program in C:

#include <stdio.h>
#include <dirent.h>
#include <fcntl.h>
#include <stdlib.h>

int
main(void)
{
    DIR *d;
    struct dirent *dp;
    int dfd;

    if ((d = fdopendir((dfd = open("/tmp", O_RDONLY)))) == NULL) {
        fprintf(stderr, "Cannot open /tmp directory\n");
        exit(1);
    }
    while ((dp = readdir(d)) != NULL) {
        if (dp->d_name[0] == '.')
            continue;
            printf("%s, \n", dp->d_name);
    }
    closedir(d);
    return 0;
}


and it seems to correctly works.

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 16:16:04 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 29 Aug 2011 14:16:04 +0000
Subject: [issue12736] Request for python casemapping functions to use full not
	simple casemaps per Unicode's recommendation
In-Reply-To: <1314623915.3551.1.camel@localhost.localdomain>
Message-ID: <15828.1314627355@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote
   on Mon, 29 Aug 2011 13:21:06 -0000: 

> It's not only "typographically speaking", it's really a spelling error,
> even in hand-written text :-)

Sure, and so too is omitting an accent mark or diaeresis.  But?alas!?you?ll
never convince most monoglot anglophones of that, the ones who keep wanting to
strip them from r?sum?, fa?ade, ch?teaux, cr?me br?l?e, f?te, t?te-?-t?te, 
? la fran?aise, or na?vet?, not to mention Jos?, jalape?o, the erstwhile
American Secretary of State Federico Pe?a, or nearby Ca?on City, Colorado, 
where I have family.  I think ?nonlogy has survived solely on its rarity, 
and the Encyclop?dia Britannica is that way because the ligat(ur)ed letter
is in their actual trademark.

Cell phone users sending text messages have long suffered the grievous
injuries to their language(s) that naked ASCII imparts, but this is
nothing like the crossdressing nightmare called Greeklish, also variously
known as Grenglish, Latinoellinika/??????????????, or ASCII Greek.

    http://en.wikipedia.org/wiki/Greeklish

    [...] The reason for this is the fact that text written in Greeklish
    is considerably less aesthetically pleasing, and also much harder to
    read, compared to text written in the Greek alphabet. A non-Greek
    speaker/reader can guess this by this example: "??? ?? ????? ???
    ????" would be the way to write "this is hard to read" in English
    but utilizing the Greek alphabet.

I especially enjoy  George Baloglou?s "Byzantine" Grenglish, wherein:

    ????????    => Oducceus    instead of Odysseus
    ????????    => Axilleus    instead of Achilleus
    ???????     => Sicuphos    instead of Sisyphus
    ????????    => 5epiklhs    instead of Pericles
    ??????      => X8onos      instead of Chthonos
 ?? ????????    => Oi Atpeides instead of the Atre?des

Terrible though the depredations upon the French language that may
have been committed by ASCII, surely these go even further. :)

--tom

        ? ??????                                        H Iliada

????? ?????, ???, ????????? ???????           Mhnin aeide, 8ea, 5hlhiadeo Axilhos
?????????, ? ????? ??????? ????? ?????,       oulomenhn, 'h mupi? Axaiois alge? e8hke,
?????? ?? ???????? ????? ???? ????????        nollas d? iph8imous yuxas Aidi npoiayen
?????, ?????? ?? ?????? ????? ????????        'hpoon, autous de elopia teuxe kuneccin
???????? ?? ????? ???? ?? ????????? ??????    oionoici te naci? Dios d? eteleieto boulh?
?? ?? ?? ?? ????? ????????? ????????          eks o'u dh ta npota diacththn epicante
???????? ?? ???? ?????? ??? ???? ????????.    Atpeidhs te anaks andpon kai dios Axilleus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12736>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:26:22 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 15:26:22 +0000
Subject: [issue8323] buffer objects are picklable but result is not unpicklable
In-Reply-To: <1270507518.5.0.340159262485.issue8323@psf.upfronthosting.co.za>
Message-ID: <1314631582.84.0.741019623515.issue8323@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Buffer objects *are* picklable with protocol 2 (but not with earlier protocols).  Unfortunately, the result is not unpicklable.  

This is not a problem with multiprocessing.  (buffer seems to inherit __reduce__ and __reduce_ex__ from object.)

Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cPickle
>>> cPickle.dumps(buffer("hello"), cPickle.HIGHEST_PROTOCOL)
'\x80\x02c__builtin__\nbuffer\nq\x01)\x81q\x02.'
>>> cPickle.loads(_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: buffer() takes at least 1 argument (0 given)

----------
nosy: +sbt
title: multiprocessing.Queue ignores pickle restrictions in .put() -> buffer objects are picklable but result is not unpicklable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8323>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:29:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 15:29:24 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1314631764.22.0.543364538379.issue9253@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: test needed -> needs patch
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:33:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 15:33:57 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1314632037.93.0.672938808796.issue3871@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> if you recall there was some discussion that it was acceptable to use
> distutils but *only* for python 2.N
There was discussion, yes, but it was not decided to change our decision on the freeze: msg121097

> just as an aside: have all python 3.N packaging scripts, for all
> python-dev scripts *and* all 3rd party packages world-wide, been using
> distutils2 by default instead of distutils?
We are well aware that it is going to take years for the Python world to switch to the new standard, that?s why
1) projects can have a distutils-compatible setup.py and a distutils2-compatible setup.Cfg
2) pysetup can install distutils-based projects
3) I?m working on documentation to help people use distutils2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:41:40 2011
From: report at bugs.python.org (jan matejek)
Date: Mon, 29 Aug 2011 15:41:40 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314632500.16.0.307029386411.issue12801@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:44:26 2011
From: report at bugs.python.org (Zooko O'Whielacronx)
Date: Mon, 29 Aug 2011 15:44:26 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	packaging
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1314632666.42.0.757471669968.issue3871@psf.upfronthosting.co.za>


Changes by Zooko O'Whielacronx <zooko at zooko.com>:


----------
nosy:  -zooko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:46:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 15:46:32 +0000
Subject: [issue11913] sdist refuses README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1314632792.09.0.627378505638.issue11913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distribute is not a project of python-dev, please use their bug tracker.

For distutils, I explained why we can?t change it and proposed a doc change; nobody commented on that.

For distutils2, I?m waiting for a reply from Tarek to this question: why don?t we include README by default anymore?

----------
components: +Distutils2
nosy: +alexis
title: sdist should allow for README.rst -> sdist refuses README.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11913>
_______________________________________

From report at bugs.python.org  Mon Aug 29 17:56:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 15:56:48 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1314633408.38.0.417309415308.issue2636@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib)
title: Regexp 2.7 (modifications to current re 2.2.2) -> Adding a new regex module (compatible with re)
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:07:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 16:07:13 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314634033.05.0.557141382786.issue12801@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, if we use two different paths based on the libc version, it might not be a good idea, since behaviour can be different in some cases.
It would be nice to know if some modern platforms have a non-compliant realpath().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:08:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 16:08:15 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1314634095.47.0.42813070142.issue10946@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The fix was actually very simple.  I have committed it to my 3.2 repo and will push later.

----------
stage: test needed -> commit review
Added file: http://bugs.python.org/file23061/fix-bdist-skip-build.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:10:55 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 16:10:55 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1314634255.58.0.381345153558.issue10886@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

mp_queue_pickle_in_main_thread.patch (against the default branch) fixes the problem by doing the pickling in Queue.put().  It is version of a patch for Issue 8037 (although I believe the behaviour complained about in Issue 8037 is not an actual bug).

The patch also has the advantage of ensuring that weakref callbacks and 
__del__ methods for objects put in the queue will not be run in the 
background thread.  (Bytes objects have trivial destructors.)  This 
potentially prevents inconsistent state caused by forking a process 
while the background thread is running -- see Issue 6721.

----------
keywords: +patch
nosy: +sbt
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23062/mp_queue_pickle_in_main_thread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:15:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 29 Aug 2011 16:15:10 +0000
Subject: [issue12836] ctypes.cast() creates circular reference in original
	object
In-Reply-To: <1314222835.27.0.518600149254.issue12836@psf.upfronthosting.co.za>
Message-ID: <1314634510.72.0.783215324591.issue12836@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can confirm that the same behaviour occur in Python 3.3, and this appears to be by design. There's a specific line in the cast() function in in Modules/_ctypes.c:

rc = PyDict_SetItem(result->b_objects, index, src);

This adds the source object to the _objects of the cast object being returned. However, earlier in the function, the code

CDataObject *obj = (CDataObject *)src;

...

result->b_objects = obj->b_objects;

ensures that result and src are using a single dictionary. Possibly, the result's b_objects needs to be a copy of the src's b_objects; but I don't know enough about ctypes internals to say whether the present code is intentional, or whether an attempt to minimise resource usage (by not copying the dictionary) has led to unwanted consequences.

----------
nosy: +vinay.sajip
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12836>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:17:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 16:17:17 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314634637.05.0.422945481787.issue12785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The tests using build_ext now pass \o/  I would love for someone with Windows and a 3.3 clone to test this patch (and if it does not fix, try with the two lines mentioned in msg142773 removed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:18:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 16:18:28 +0000
Subject: [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314634708.88.0.891941886022.issue12833@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Still, this behavior is surprising and undesirable. I would suggest
> adding a note to the docs for the readline module
+1.

----------
assignee:  -> docs at python
components: +Documentation -IO, Interpreter Core
nosy: +docs at python
stage: test needed -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12833>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:36:41 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 16:36:41 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1314635801.15.0.00705068228588.issue8037@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

Modifying an object which is already on a traditional queue can also change what is received by the other thread (depending on timing).  So Queue.Queue's put() is not "atomic" either.  Therefore I do not believe this behaviour is a bug. 

However the solution proposed is a good one since it fixes Issue 10886.  In addition it prevents arbitrary code being run in the background thread by weakref callbacks or __del__ methods.  Such arbitrary code may cause inconsistent state in a forked process if the fork happens while the queue's thread is running -- see issue 6271.

I have submitted a patch for Issue 10886.  It is basically the same as 
patch_27maint.diff, but it is against the default mercurial branch.  (Also, it is a bit simpler because does it does not unnecessarily modify Queue.get().)

I would suggest closing this issue and letting Issue 10886 take it's place.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:38:01 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 29 Aug 2011 16:38:01 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314635881.39.0.910034825541.issue12852@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

I'm not sure what the status of Python and OpenBSD support is but I just tried the latest stable version of OpenBSD (4.9) in VirtualBox and it won't compile fully. It segfaults while trying to run setup.py (I think).

I see you're running OpenBSD 5.0. Does it compile easily on that without having to jump through hoops?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:39:18 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 16:39:18 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1314635958.22.0.061206391693.issue8037@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

I meant Issue 6721 (Locks in python standard library should be sanitized on fork) not 6271.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Mon Aug 29 18:45:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 16:45:17 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1314636317.05.0.597898907914.issue10886@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This shouldn't be a problem in Python 3.3, where the Connection classes are reimplemented in pure Python.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:08:20 2011
From: report at bugs.python.org (Russell Owen)
Date: Mon, 29 Aug 2011 17:08:20 +0000
Subject: [issue12853] global name 'r' is not defined in upload.py
Message-ID: <1314637700.16.0.440169429003.issue12853@psf.upfronthosting.co.za>


New submission from Russell Owen <reowen at users.sourceforge.net>:

When using distutils to upload code to PyPI I get the following message (but the upload is successful):
{{{
Traceback (most recent call last):
  File "setup.py", line 60, in <module>
    zip_safe = False, # icons (e.g. as used by RO.Wdg.GrayImageDispWdg) are not retrieved in a zip-safe way
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/distutils/command/upload.py", line 180, in upload_file
    msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
NameError: global name 'r' is not defined
}}}
A look at the current source code shows that there is indeed no variable "r". I'm not sure what was intended but it seems likely that it would be possible to replace r.read() by reason, status, or a combination of the two.

----------
messages: 143162
nosy: reowen
priority: normal
severity: normal
status: open
title: global name 'r' is not defined in upload.py
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12853>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:22:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 29 Aug 2011 17:22:19 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1314634033.05.0.557141382786.issue12801@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Okeq30F_5YYviCRaxuu1aW1KS8CYkMJv6vYG=JY-W9Q@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Well, if we use two different paths based on the libc version, it might not be a good idea, since behaviour can be different in some cases.

Indeed.

> It would be nice to know if some modern platforms have a non-compliant realpath().

Alas, it doesn't seem to hold for OpenBSD:
http://old.nabble.com/Make-realpath(3)-conform-to-SUSv4-td32031895.html

A patch supporting NULL was committed two months ago, which means we
probably can't push this forward.

I've been quite disappointed by POSIX lately...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:24:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 17:24:02 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <CAH_1eM0Okeq30F_5YYviCRaxuu1aW1KS8CYkMJv6vYG=JY-W9Q@mail.gmail.com>
Message-ID: <1314638486.3551.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Alas, it doesn't seem to hold for OpenBSD:
> http://old.nabble.com/Make-realpath(3)-conform-to-SUSv4-td32031895.html
> 
> A patch supporting NULL was committed two months ago, which means we
> probably can't push this forward.
> 
> I've been quite disappointed by POSIX lately...

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:25:22 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 29 Aug 2011 17:25:22 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1313884051.29.0.336736419117.issue12801@psf.upfronthosting.co.za>
Message-ID: <1314638722.57.0.162686353215.issue12801@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> I've been quite disappointed by POSIX lately...

POSIX the standard, or the implementers??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:29:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 17:29:27 +0000
Subject: [issue12853] global name 'r' is not defined in upload.py
In-Reply-To: <1314637700.16.0.440169429003.issue12853@psf.upfronthosting.co.za>
Message-ID: <1314638967.24.0.392509223891.issue12853@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils
nosy: +eric.araujo, tarek
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12853>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:45:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 17:45:14 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314639914.08.0.300666872815.issue11564@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Tested the latest patch with -M11G. All tests pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Mon Aug 29 19:55:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 29 Aug 2011 17:55:45 +0000
Subject: [issue12801] C realpath not used by os.path.realpath
In-Reply-To: <1314638722.57.0.162686353215.issue12801@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1G8voscKqbJRXpB1zFfk0DucMALu9KvfnYECcoFe8NAw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> POSIX the standard, or the implementers??
>

Both :-)

For those wondering why we can't use PATH_MAX (ignoring the buffer
overallocation), here's why:

https://www.securecoding.cert.org/confluence/display/cplusplus/FIO02-CPP.+Canonicalize+path+names+originating+from+untrusted+sources
"""
Avoid using this function. It is broken by design since (unless using
the non-standard resolved_path == NULL feature) it is impossible to
determine a suitable size for the output buffer, resolved_path.
According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX
need not be a defined constant, and may have to be obtained using
pathconf(3). And asking pathconf(3) does not really help, since on the
one hand POSIX warns that the result of pathconf(3) may be huge and
unsuitable for mallocing memory. And on the other hand pathconf(3) may
return -1 to signify that PATH_MAX is not bounded.
The libc4 and libc5 implementation contains a buffer overflow (fixed
in libc-5.4.13). As a result, set-user-ID programs like mount(8) need
a private version."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12801>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:02:45 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 29 Aug 2011 18:02:45 +0000
Subject: [issue12854] PyOS_Readline usage in tokenizer ignores
	sys.stdin/sys.stdout
Message-ID: <1314640965.12.0.413941920183.issue12854@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

In Parser/tokenizer.c, there is `PyOS_Readline(stdin, stdout, tok->prompt)`. This ignores any `sys.stdin` / `sys.stdout` overwrites.

The usage should be like in Python/bltinmodule.c in builtin_raw_input.

----------
messages: 143168
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: PyOS_Readline usage in tokenizer ignores sys.stdin/sys.stdout
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12854>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:05:12 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 29 Aug 2011 18:05:12 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1314641112.18.0.728476024012.issue12769@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This behaviour also occurs in 3.3, where this does appear to be a bug. In Modules/_ctypes/cfield.c, the setting code does a strlen(), which is in fact questioned in a comment. In function s_set():

size = strlen(data); /* XXX Why not Py_SIZE(value)? */

Why not, indeed? value is the bytes object passed in, and using Py_SIZE does indeed copy all the bytes. However, it's operating in string rather than buffer mode: for example, it adds a byte for a terminating NUL, so if the 5-byte value b'x\x00y\x00z' were passed, 6 bytes are actually copied. This doesn't seem right.

Even after changing s_set to use Py_SIZE, you can't see the copied bytes when you access the attribute, since the code in s_get() skips out at the first NUL byte and then constructs using PyBytes_FromStringAndSize and the truncated size. One can see the convenience of avoiding the display of lots of NUL chars, but it doesn't seem correct to do this.

On 2.x it's a bit muddier, as arrays of c_char could be using ASCII strings, where a NUL terminator might be appropriate to consider.

----------
nosy: +vinay.sajip
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:17:33 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 29 Aug 2011 18:17:33 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
	assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1314641853.16.0.0305092172331.issue12769@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Seems related: #8161

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12769>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:27:00 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 29 Aug 2011 18:27:00 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1314642420.79.0.884565067798.issue9041@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

While the patch might improve over the current situation, doesn't it potentially mask other errors which might be raised by PyFloat_AsDouble()?
Why not just

x = PyFloat_AsDouble(value);
if (PyErr_Occurred())
    return NULL;

which would not mask any exception?

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:35:28 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 29 Aug 2011 18:35:28 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314642928.69.0.908125621546.issue12841@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Yes, I can do that as soon as I've managed to wrap my head around using Mercurial and the new way of developing Python. I have been away from Python programming for quite some time and haven't adapted my workflow yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:48:05 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 18:48:05 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1314643685.74.0.483364594941.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
hgrepos: +64

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:49:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 18:49:14 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1314643754.18.0.0724979650547.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


Added file: http://bugs.python.org/file23063/f3cf187208ea.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 29 20:53:08 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 18:53:08 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1314643988.69.0.301465535881.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Attached is a patch (f3cf187208ea.diff) containing my work so far on
reimplementing the lzma module. So far I've just done the LZMACompressor
and LZMADecompressor classes, but I'm hoping to implement LZMAFile this
weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Mon Aug 29 21:04:01 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 19:04:01 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1314644641.94.0.400299242844.issue6721@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

multiprocessing.util already has register_after_fork() which it uses for cleaning up certain things when a new process (launched by multiprocessing) is starting.  This is very similar to the proposed atfork mechanism.

Multiprocessing assumes that it is always safe to delete lock objects.  If reinit_locks.diff is committed then I guess this won't be a problem.

I will try to go through multiprocessing's use of threads: 

Queue
-----

Queue's have a feeder thread which pushes objects in to the underlying pipe as soon as possible.  The state which can be modified by this thread is a threading.Condition object and a collections.deque buffer.  Both of these are replaced by fresh copies by the after-fork mechanism.

However, because objects in the buffer may have __del__ methods or weakref callbacks associated, arbitrary code may be run by the background thread if the reference count falls to zero.

Simply pickling the argument of put() before adding it to the buffer fixes that problem -- see the patch for Issue 10886.  With this patch I think Queue's use of threads is fork-safe.

Pool
----

If a fork occurs while a pool is running then a forked process will get a copy of the pool object in an inconsistent state -- but that does not matter since trying to use a pool from a forked process will *never* work.

Also, some of a pool's methods support callbacks which can execute arbitrary code in a background thread.  This can create inconsistent state in a forked process

As with Queue.put, pool methods should pickle immediately for similar reasons.

I would suggest documenting clearly that a pool should only ever be used or deleted by the process which created it.  We can use register_after_fork to make all of a pool's methods raise an error after a fork.  

We should also document that callbacks should only be used if no more processes will be forked.

allow_connection_pickling
-------------------------

Currently multiprocessing.allow_connection_pickling() does not work because types are registered with ForkingPickler instead of copyreg -- see Issue 4892.  However, the code in multiprocessing.reduction uses a background thread to support the transfer of sockets/connections between processes.

If this code is ever resurrected I think the use of register_after_fork makes this safe.

Managers
--------

A manager uses a threaded server process.  This is not a problem unless you create a user defined manager which forks new processes.   The documentation should just say Don't Do That.


I think multiprocessing's threading issues are all fixable.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Mon Aug 29 21:37:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 19:37:11 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1314646631.76.0.384648009644.issue12841@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can get a lot of information on this guide:
http://docs.python.org/devguide/setup.html#getting-set-up

You can also ask on IRC (#python-dev on Freenode), or by email on the python-dev mailing list.

It was really hard for me to switch from Subversion to Mercurial. Not because of the merge and the push things, but because of the 4 different Python branches! So don't hesitate to ask me questions about how I use Mercurial ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12841>
_______________________________________

From report at bugs.python.org  Mon Aug 29 21:40:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 19:40:50 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314646850.24.0.268988342616.issue12852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It looks like a kernel bug !?

And you know what? fdopendir() function has been introducted in OpenBSD 5.0!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 22:10:04 2011
From: report at bugs.python.org (sbt)
Date: Mon, 29 Aug 2011 20:10:04 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1314648604.96.0.0241524947026.issue10886@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

> This shouldn't be a problem in Python 3.3, where the Connection classes
> are reimplemented in pure Python.

What should not be a problem?

Changes to the implementation of Connection won't affect whether Queue.put() raises an error immediately if it gets an unpicklable argument.  

Nor will they affect whether weakref callbacks or __del__ methods run in a background thread, causing fork-safety issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Mon Aug 29 22:24:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Aug 2011 20:24:11 +0000
Subject: [issue12762] EnvironmentError_str contributes to unportable code
In-Reply-To: <1313514546.35.0.211291095895.issue12762@psf.upfronthosting.co.za>
Message-ID: <1314649451.98.0.678855394064.issue12762@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I tend to agree that the errno is much less useful than the symbolic name.  The former is useful and will be available as an attribute, but the latter should be used in the str.  The change will probably break scads of doctests, but is probably worth it. :)

BTW, this came up in the PEP 3151 discussions, but I agree it's orthogonal to that PEP.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12762>
_______________________________________

From report at bugs.python.org  Mon Aug 29 22:52:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 20:52:24 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1314651144.44.0.294015893533.issue10886@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Changes to the implementation of Connection won't affect whether
> Queue.put() raises an error immediately if it gets an unpicklable
> argument.

Ah, right. Then indeed it won't make a difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:24:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 29 Aug 2011 21:24:39 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <E1Qy9Jt-0005RP-Jb@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset babc90f3cbf4 by Antoine Pitrou in branch '3.2':
Issue #11564: Avoid crashes when trying to pickle huge objects or containers
http://hg.python.org/cpython/rev/babc90f3cbf4

New changeset 56242682a931 by Antoine Pitrou in branch 'default':
Issue #11564: Avoid crashes when trying to pickle huge objects or containers
http://hg.python.org/cpython/rev/56242682a931

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:31:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 29 Aug 2011 21:31:12 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314653472.91.0.659740731072.issue12852@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

[Switching to process 21658, thread 0x20a519000]
_readdir_unlocked (dirp=0xafb0e80, result=0x7f7ffffd7ac0, skipdeleted=1)
    at /usr/src/lib/libc/gen/readdir.c:44
44                      if (dirp->dd_loc >= dirp->dd_size)


Looks like dirp points to an invali location in memory.
Could you try display it ("p *dirp")?

But this definitely looks like a kernel/libc bug...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:42:30 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 21:42:30 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
Message-ID: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>


New submission from Matthew Boehm <boehm.matthew at gmail.com>:

A file opened with codecs.open() splits on a form feed character (\x0c) while a file opened with open() does not.

>>> with open("formfeed.txt", "w") as f:
...   f.write("line \fone\nline two\n")
...
>>> with open("formfeed.txt", "r") as f:
...   s = f.read()
...
>>> s
'line \x0cone\nline two\n'
>>> print s
line
    one
line two

>>> import codecs
>>> with open("formfeed.txt", "rb") as f:
...   lines = f.readlines()
...
>>> lines
['line \x0cone\n', 'line two\n']
>>> with codecs.open("formfeed.txt", "r", encoding="ascii") as f:
...   lines2 = f.readlines()
...
>>> lines2
[u'line \x0c', u'one\n', u'line two\n']
>>>

Note that lines contains two items while lines2 has 3.

Issue 7643 has a good discussion on newlines in python, but I did not see this discrepancy mentioned.

----------
components: Interpreter Core
messages: 143182
nosy: Matthew.Boehm
priority: normal
severity: normal
status: open
title: open() and codecs.open() treat form-feed differently
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:43:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 21:43:23 +0000
Subject: [issue11564] pickle not 64-bit ready
In-Reply-To: <1300229909.71.0.853987934234.issue11564@psf.upfronthosting.co.za>
Message-ID: <1314654203.24.0.738285398808.issue11564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed as far as possible (OverflowErrors will be raised instead of crashing).
Making people actually 64-bit compliant is part of PEP 3154 (http://www.python.org/dev/peps/pep-3154/).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11564>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:45:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 21:45:08 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314654308.8.0.353970953192.issue12852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that the problem is that fdopendir() is not defined. If a function is not defined, C uses int as the result type. An int is not enough to store a 64-bit pointer. See in gdb output: dirp is 0x0afb0e80 whereas other pointers look like 0x20973fc30. You missed the highest hexa digit (0x2).

fdopendir() requires IEEE 1003.1-2008 and so "#define _POSIX_C_SOURCE 200809L", whereas pyconfig.h defines _POSIX_C_SOURCE to 200112L (POSIX 2001).

Something should be done in configure.in, near:
-----------------------------------------
case $ac_sys_system/$ac_sys_release in
  # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined,
  # even though select is a POSIX function. Reported by J. Ribbens.
  # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish.
  # In addition, Stefan Krah confirms that issue #1244610 exists through
  # OpenBSD 4.6, but is fixed in 4.7.
  OpenBSD/2.* | OpenBSD/3.* | OpenBSD/4.@<:@0123456@:>@) 
    define_xopen_source=no
    # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
    # also defined. This can be overridden by defining _BSD_SOURCE
    # As this has a different meaning on Linux, only define it on OpenBSD
    AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features])
    ;;
  OpenBSD/*)
    # OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is
    # also defined. This can be overridden by defining _BSD_SOURCE
    # As this has a different meaning on Linux, only define it on OpenBSD
    AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features])
    ;;
-----------------------------------------

or maybe in

-----------------------------------------
if test $define_xopen_source = yes
then
  AC_DEFINE(_XOPEN_SOURCE, 600, 
            Define to the level of X/Open that your system supports)

  # On Tru64 Unix 4.0F, defining _XOPEN_SOURCE also requires
  # definition of _XOPEN_SOURCE_EXTENDED and _POSIX_C_SOURCE, or else
  # several APIs are not declared. Since this is also needed in some
  # cases for HP-UX, we define it globally.
  AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1,
   	    Define to activate Unix95-and-earlier features)

  AC_DEFINE(_POSIX_C_SOURCE, 200112L, Define to activate features from IEEE Stds 1003.1-2001)  
fi
-----------------------------------------

I tried "AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from IEEE Stds 1003.1-2008)" but it doesn't work.

Add "#define _POSIX_C_SOURCE 200809L" at the beginning of Modules/posixmodule.c does works around this issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file23064/posix_2008.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Mon Aug 29 23:55:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 21:55:57 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314654957.28.0.590281526603.issue12855@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

U+000C (Form feed) is considered as a line boundary in Unicode (unicode type), but no for a byte string (str type).

Example:

>>> u'line \x0cone\nline two\n'.splitlines(True)
[u'line \x0c', u'one\n', u'line two\n']
>>> 'line \x0cone\nline two\n'.splitlines(True)
['line \x0cone\n', 'line two\n']

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:03:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 22:03:14 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1314655394.7.0.0984131393942.issue12589@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> what information do you need to advance on this bug?

It would be easier to debug if I had access to OpenBSD on a PowerPC host.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:07:58 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 22:07:58 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314655678.23.0.714789491026.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

Thanks for explaining the reasoning.

Perhaps I should add this to the python wiki (http://wiki.python.org/moin/Unicode) ?

It would be nice if it fit in the docs somewhere, but I'm not sure where.

I'm curious how (or if) 2to3 would handle this as well, but I'm closing this issue as it's now clear to me why these two are expected to act differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:08:33 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 22:08:33 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314655713.3.0.222332712566.issue12855@psf.upfronthosting.co.za>


Changes by Matthew Boehm <boehm.matthew at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:11:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Aug 2011 22:11:59 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314655919.28.0.910600672895.issue12855@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It would be nice if it fit in the docs somewhere,
> but I'm not sure where.

See:
http://docs.python.org/library/codecs.html#codecs.StreamReader.readline

Can you suggest a patch for the documentation? Source code of this document:
http://hg.python.org/cpython/file/bb7b14dd5ded/Doc/library/codecs.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:24:37 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 22:24:37 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314656677.79.0.459016621394.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I'll suggest a patch for the documentation when I get to my home computer in an hour or two.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:31:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 29 Aug 2011 22:31:14 +0000
Subject: [issue12847] crash with negative PUT in pickle
In-Reply-To: <1314446464.92.0.317073620599.issue12847@psf.upfronthosting.co.za>
Message-ID: <E1QyAML-0002BN-4O@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0d9e4ce1c010 by Antoine Pitrou in branch '3.2':
Issue #12847: Fix a crash with negative PUT and LONG_BINPUT arguments in
http://hg.python.org/cpython/rev/0d9e4ce1c010

New changeset fb8d7a666bed by Antoine Pitrou in branch 'default':
Issue #12847: Fix a crash with negative PUT and LONG_BINPUT arguments in
http://hg.python.org/cpython/rev/fb8d7a666bed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12847>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:31:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Aug 2011 22:31:35 +0000
Subject: [issue12847] crash with negative PUT in pickle
In-Reply-To: <1314446464.92.0.317073620599.issue12847@psf.upfronthosting.co.za>
Message-ID: <1314657095.82.0.189486611443.issue12847@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/issue12847>
_______________________________________

From report at bugs.python.org  Tue Aug 30 00:54:35 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Aug 2011 22:54:35 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314658475.32.0.34462219762.issue12785@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I've tested the attached patch against 3.3 on Windows XP, and it seems to
fix the test_database failures. There were some merge conflicts when I
applied the patch (because some of the docstring and comment changes had
already been committed in fixes from the other issue), so I've uploaded
the exact diff of what I tested with.

I tested both with and without the change you suggested in msg142773 -
the tests pass in both cases.

----------
Added file: http://bugs.python.org/file23065/fix-list_distinfo_files-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Tue Aug 30 02:31:53 2011
From: report at bugs.python.org (Ferringb)
Date: Tue, 30 Aug 2011 00:31:53 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
Message-ID: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>


New submission from Ferringb <ferringb at gmail.com>:

Roughly; tempfile's uniqueness is derived from a global random instance; while there are protections for thread access, a forked child process /will/ inherit that PRNG source, resulting in children/parent trying the same set of names.

Mostly it's proving annoying in some code I have to deal in, although it wouldn't surprise me if someone watching a known temp location could use the predictability in some fashion.

As for affect, all versions of python have this; attached patch is cut against trunk.

----------
files: unique-seed-per-process-tempfile.patch
keywords: patch
messages: 143192
nosy: ferringb
priority: normal
severity: normal
status: open
title: tempfile PRNG reuse between parent and child process
type: behavior
Added file: http://bugs.python.org/file23066/unique-seed-per-process-tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Tue Aug 30 02:33:37 2011
From: report at bugs.python.org (Ferringb)
Date: Tue, 30 Aug 2011 00:33:37 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1314664417.59.0.753584641823.issue12856@psf.upfronthosting.co.za>


Ferringb <ferringb at gmail.com> added the comment:

Bleh; pardon, reuploading the patch.  hg export aparently appends to the output file rather than overwriting it (last patch had duplicated content in it).

----------
Added file: http://bugs.python.org/file23067/unique-seed-per-process-tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Tue Aug 30 02:34:52 2011
From: report at bugs.python.org (Ferringb)
Date: Tue, 30 Aug 2011 00:34:52 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1314664492.41.0.679317946909.issue12856@psf.upfronthosting.co.za>


Changes by Ferringb <ferringb at gmail.com>:


Removed file: http://bugs.python.org/file23066/unique-seed-per-process-tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Tue Aug 30 02:57:55 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 00:57:55 +0000
Subject: [issue12855] open() and codecs.open() treat form-feed differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314665875.6.0.724419473697.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I'm taking a look at the docs now.

I'm considering adding a table/list of characters python treats as newlines, but it seems like this might fit better as a note in http://docs.python.org/library/stdtypes.html#str.splitlines or somewhere else in stdtypes. I'll start working on it now, but please let me know what you think about this.

This is my first attempt at a patch, so I greatly appreciate your help so far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 03:11:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Aug 2011 01:11:32 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1314666692.34.0.65040664489.issue12856@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Interesting, thank you.
Two nits:
- the test must be skipped where os.fork() isn't available (namely, under Windows)
- I would do os.read(fd, 100) (or some other large value) rather than os.read(fd, 6), so that the test doesn't depend on the exact length of the random sequences produced

----------
components: +Library (Lib)
nosy: +ncoghlan, pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Tue Aug 30 04:07:48 2011
From: report at bugs.python.org (Ferringb)
Date: Tue, 30 Aug 2011 02:07:48 +0000
Subject: [issue12856] tempfile PRNG reuse between parent and child process
In-Reply-To: <1314664313.38.0.204964767206.issue12856@psf.upfronthosting.co.za>
Message-ID: <1314670068.06.0.54106902457.issue12856@psf.upfronthosting.co.za>


Ferringb <ferringb at gmail.com> added the comment:

> the test must be skipped where os.fork() isn't available (namely, under Windows)

Done, although I still humbly suggest telling windows to bugger off ;)

> I would do os.read(fd, 100) (or some other large value) rather than os.read(fd, 6), so that the test doesn't depend on the exact length of the random sequences produced

100 is no different than 6 (same potential exists); better to just use the length from the parent side access to the PRNG.  That leaves open the unlikely scenario of child returning 7 chars, parent 6, and child/parent agreeing on the first 6... which would very likely be a bug anyways.

----------
Added file: http://bugs.python.org/file23068/unique-seed-per-process-tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12856>
_______________________________________

From report at bugs.python.org  Tue Aug 30 06:22:39 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 30 Aug 2011 04:22:39 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314678159.45.0.104937363165.issue12829@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

Terry: I wasn't aware xml.parsers.expat is deprecated, though it clearly says so in the documentation, I now see...  (I'd been using it because it features prominently in various examples in Python books, and it's lightweight.)  I haven't tested with the 3.x series, because I rely on the 2.6 branch as a dependency for a variety of software on NetBSD, but having said that, I can test it on Mac OS X.  Your test output is the correct, expected results, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Tue Aug 30 06:37:30 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 30 Aug 2011 04:37:30 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314679050.56.0.328753602599.issue12829@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

Confirming that Python 3.2.1 crashes the same way on Mac OS X 10.6.8:

Process:         Python [9594]
Path:            /Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  bash [9570]

Date/Time:       2011-08-30 00:35:53.863 -0400
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          292720 sec
Crashes Since Last Report:           2
Per-App Crashes Since Last Report:   2
Anonymous UUID:                      5504B203-8C24-427A-B74C-EDBD3EF8DB51

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000001006fb000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   pyexpat.so                    	0x00000001006a03e9 normal_updatePosition + 57
1   pyexpat.so                    	0x000000010068b2c4 PyExpat_XML_GetCurrentLineNumber + 84
2   pyexpat.so                    	0x000000010068673e set_error + 62
3   pyexpat.so                    	0x00000001006874e8 xmlparse_Parse + 200
4   org.python.python             	0x00000001000b39b2 PyEval_EvalFrameEx + 30530
5   org.python.python             	0x00000001000b2a4d PyEval_EvalFrameEx + 26589
6   org.python.python             	0x00000001000b431a PyEval_EvalCodeEx + 1770
7   org.python.python             	0x00000001000b462f PyEval_EvalCode + 63
8   org.python.python             	0x00000001000db82b PyRun_FileExFlags + 187
9   org.python.python             	0x00000001000dbaf9 PyRun_SimpleFileExFlags + 521
10  org.python.python             	0x00000001000f0a03 Py_Main + 3059
11  org.python.python             	0x0000000100000e5f 0x100000000 + 3679
12  org.python.python             	0x0000000100000d04 0x100000000 + 3332

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00000000fffffffb  rbx: 0x00000001003a9b40  rcx: 0x00000001003a9e48  rdx: 0x000000010093b59f
  rdi: 0x00000001006b76e0  rsi: 0x00000001006fb000  rbp: 0x00007fff5fbfed60  rsp: 0x00007fff5fbfed60
   r8: 0x00000001006a0408   r9: 0x00000001008cb400  r10: 0x0000000000000800  r11: 0x00000001006d4dda
  r12: 0x0000000000000000  r13: 0x00000001005aa5f0  r14: 0x0000000000000009  r15: 0x00000001002b6810
  rip: 0x00000001006a03e9  rfl: 0x0000000000010293  cr2: 0x00000001006fb000

Binary Images:
       0x100000000 -        0x100000ff7 +org.python.python 3.2.1 (3.2.1) <B2AFB510-C20A-61C8-C375-448C252C66A8> /Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100182ff7 +org.python.python 3.2.1, (c) 2004-2011 Python Software Foundation. (3.2.1) <9A9D8FC9-0EA2-8B57-D918-373F60ECF77A> /Library/Frameworks/Python.framework/Versions/3.2/Python
       0x1002fc000 -        0x1002fcfff +_bisect.so ??? (???) <25A7A434-1970-9B41-5BFD-31B6F7AD6ECF> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_bisect.so
       0x1005b0000 -        0x1005b1ff7 +_heapq.so ??? (???) <3E54D664-5279-8504-CA26-E23A15CF152D> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_heapq.so
       0x100682000 -        0x1006b6fef +pyexpat.so ??? (???) <F5A9710C-3B05-3BA8-66E1-5D34290441CA> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/pyexpat.so
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <B536F2F1-9DF1-3B6C-1C2C-9075EA219A06> /usr/lib/dyld
    0x7fff8005d000 -     0x7fff801d4fe7  com.apple.CoreFoundation 6.6.5 (550.43) <31A1C118-AD96-0A11-8BDF-BD55B9940EDC> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff822f0000 -     0x7fff824b1fef  libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
    0x7fff82781000 -     0x7fff82792ff7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <FB5EE53A-0534-0FFA-B2ED-486609433717> /usr/lib/libz.1.dylib
    0x7fff8376d000 -     0x7fff837eafef  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
    0x7fff85577000 -     0x7fff8557bff7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff86259000 -     0x7fff86417fff  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <4274FC73-A257-3A56-4293-5968F3428854> /usr/lib/libicucore.A.dylib
    0x7fff86526000 -     0x7fff865dcff7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib
    0x7fff8739a000 -     0x7fff873e6fff  libauto.dylib ??? (???) <F7221B46-DC4F-3153-CE61-7F52C8C293CF> /usr/lib/libauto.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Tue Aug 30 06:45:19 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 04:45:19 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314679519.7.0.470795314113.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I've attached a patch for python2.7 that adds a small not to library/stdtypes.html#str.splitlines explaining which sequences are treated as line breaks:

"""
Note: Python recognizes "\r", "\n", and "\r\n" as line boundaries for strings.

In addition to these, Unicode strings can have line boundaries of u"\x0b", u"\x0c", u"\x85", u"\u2028", and u"\u2029"
"""

Additional thoughts:

* Would it be better to put this note in a different place?

* It looks like \x0b and \x0c (vertical tab and form feed) were first considered line breaks in Python 2.7, probably related to this note from "What's New in 2.7": "The Unicode database provided by the unicodedata module is now used internally to determine which characters are numeric, whitespace, or represent line breaks." It might be worth putting a "changed in 2.7" note somewhere in the docs.

Please let me know of any thoughts you have and I'll be glad to make any desired changes and submit a new patch.

----------
keywords: +patch
title: open() and codecs.open() treat form-feed differently -> linebreak sequences should be better documented
Added file: http://bugs.python.org/file23069/linebreakdoc.py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 06:58:46 2011
From: report at bugs.python.org (David H. Gutteridge)
Date: Tue, 30 Aug 2011 04:58:46 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314680326.4.0.230369890371.issue12829@psf.upfronthosting.co.za>


David H. Gutteridge <dhgutteridge at sympatico.ca> added the comment:

Further details:

- The original test case I'd submitted crashed on the development branch of NetBSD as well as Mac OS X Snow Leopard, but not the most recent stable branch of NetBSD.  I've found a separate test case that crashes on both branches of NetBSD, but not OS X...  This is quite possibly a separate bug, but the means of triggering it is directly related, so I'm including it here.

- I also built Python 2.7.2 under Solaris to see if either test case resulted in a crash there, and they do not, so it seems this is BSDish somehow (or else, the Mac OS X and NetBSD crashes are two separate bugs).

- With NetBSD, I also created tests in C that use the Expat library directly, submitting the very same test data, and they do not crash, they return the expected results, so it appears there's definitely something happening in Python somewhere that's causing this.

This is the (non-debug) crash trace from the separate NetBSD test.  (I will look at building a debug version of Python when I get a chance...)  I'm running Python 2.6.7 on the NetBSD machines.

#0  0xbb93ff64 in XML_ParserCreate () from /usr/X11R7/lib/libexpat.so.1
#1  0xbb9348a3 in XML_GetCurrentLineNumber () from /usr/X11R7/lib/libexpat.so.1
#2  0xbb956743 in set_error () from /usr/pkg/lib/python2.6/site-packages/pyexpat.so
#3  0xbb956d21 in xmlparse_Parse () from /usr/pkg/lib/python2.6/site-packages/pyexpat.so
#4  0xbbb048b0 in PyCFunction_Call () from /usr/pkg/lib/libpython2.6.so.1.0
#5  0xbbb5a3d7 in PyEval_EvalFrameEx () from /usr/pkg/lib/libpython2.6.so.1.0
#6  0xbbb5add8 in PyEval_EvalCodeEx () from /usr/pkg/lib/libpython2.6.so.1.0
#7  0xbbb5914e in PyEval_EvalFrameEx () from /usr/pkg/lib/libpython2.6.so.1.0
#8  0xbbb5add8 in PyEval_EvalCodeEx () from /usr/pkg/lib/libpython2.6.so.1.0
#9  0xbbb5ae22 in PyEval_EvalCode () from /usr/pkg/lib/libpython2.6.so.1.0
#10 0xbbb72f12 in run_mod () from /usr/pkg/lib/libpython2.6.so.1.0
#11 0xbbb72fb5 in PyRun_FileExFlags () from /usr/pkg/lib/libpython2.6.so.1.0
#12 0xbbb745e4 in PyRun_SimpleFileExFlags () from /usr/pkg/lib/libpython2.6.so.1.0
#13 0xbbb74ce5 in PyRun_AnyFileExFlags () from /usr/pkg/lib/libpython2.6.so.1.0
#14 0xbbb80322 in Py_Main () from /usr/pkg/lib/libpython2.6.so.1.0
#15 0x080487e9 in main ()

----------
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23070/pyexpat_crash_isolation_nb.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Tue Aug 30 07:29:52 2011
From: report at bugs.python.org (Anthony Kong)
Date: Tue, 30 Aug 2011 05:29:52 +0000
Subject: [issue12853] global name 'r' is not defined in upload.py
In-Reply-To: <1314637700.16.0.440169429003.issue12853@psf.upfronthosting.co.za>
Message-ID: <1314682192.79.0.62305014312.issue12853@psf.upfronthosting.co.za>


Changes by Anthony Kong <anthony.hw.kong at gmail.com>:


----------
nosy: +Anthony.Kong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12853>
_______________________________________

From report at bugs.python.org  Tue Aug 30 07:54:28 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Aug 2011 05:54:28 +0000
Subject: [issue12857] Expose called function on frame object
Message-ID: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

This patch adds f_func to PyFrameObject and sets it for functions that get called (in PyFrame_New).  For classes and modules it is set to None.  The difference in performance was not noticable, as far as I could tell.  However, I am willing to do more than just time 'make test' a few times if there is any concern.

A couple weeks ago a thread on python-ideas centered on the subject matter of PEP 3130[1].  The discussion started with, and mainly involved, the idea of adding __function__ to the frame locals during execution of the function.  __function__ would point to the function that was called, which had resulted in the frame.

I spent quite a bit of time getting this to work using a closure, but the result was overkill.  It also made it too easy to use __function__ for recursion, which Guido did not like (and I agree).

At this point it dawned on me that it would be much simpler to just add the called function to the frame object.  This patch is the result.  In the end it is much more efficient than the locals approach I had been taking.

[1] http://mail.python.org/pipermail/python-ideas/2011-August/011062.html

----------
components: Interpreter Core
files: called_function.diff
keywords: patch
messages: 143201
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Expose called function on frame object
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23071/called_function.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Tue Aug 30 09:05:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 30 Aug 2011 07:05:25 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314654308.8.0.353970953192.issue12852@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2285JQNWgSkfQicwJ8yq_hNpABb1HCCBU1NsAV1p4hkw@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> I think that the problem is that fdopendir() is not defined. If a function is not defined, C uses int as the result type. An int is not enough to store a 64-bit pointer. See in gdb output: dirp is 0x0afb0e80 whereas other pointers look like 0x20973fc30. You missed the highest hexa digit (0x2).

Yeah, I noticed that. I didn't make the connection with the
possibility of missing prototype though. Nice catch.

> I tried "AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from IEEE Stds 1003.1-2008)" but it doesn't work.
>

You mean that the patch you attached doesn't work, correct?
I know it's a stupid question, but you're sure you didn't forget to
run autoconf/autoheader?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Tue Aug 30 10:08:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 08:08:24 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <CAH_1eM2285JQNWgSkfQicwJ8yq_hNpABb1HCCBU1NsAV1p4hkw@mail.gmail.com>
Message-ID: <4E5C9A6D.2080409@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> I tried "AC_DEFINE(_POSIX_C_SOURCE, 200809L, Define to activate features from IEEE Stds 1003.1-2008)" but it doesn't work.
>
> You mean that the patch you attached doesn't work, correct?

I ran autoconf, re-ran configure and it doesn't work. You can test 
without touching configure.in: edit pyconfig.h directly.

On Linux, all "features" flags are defined/undefined in 
/usr/include/features.h. Depending on _POSIX_C_SOURCE, _XOPEN_SOURCE, 
_BSD_SOURCE, ..., you get a different POSIX level.

For example:

/* If _GNU_SOURCE was defined by the user, turn on all the other 
features.  */
#ifdef _GNU_SOURCE
# undef  _ISOC99_SOURCE
# define _ISOC99_SOURCE	1
# undef  _POSIX_SOURCE
# define _POSIX_SOURCE	1
# undef  _POSIX_C_SOURCE
# define _POSIX_C_SOURCE	200809L
# undef  _XOPEN_SOURCE
# define _XOPEN_SOURCE	700
# ...
#endif

I suppose that there is a conflict between Python's _POSIX_C_SOURCE and 
other defines related to the POSIX level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Tue Aug 30 10:22:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 08:22:54 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314692574.67.0.567076643261.issue12855@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Would it be better to put this note in a different place?

You may just say that StreamReader.readline() uses unicode.splitlines(), and so point to unicode.splitlines() doc (use :meth:`unicode.splitlines` syntax). unicode.splitlines() is now well documented: line boundaries are not listed, even in Python 3 documentation.

Unicode line boundaries used by Python 2.7 and 3.3:

U+000A: Line feed
U+000B: Line tabulation
U+000C: Form feed
U+000D: Carriage return
U+001C: File separator
U+001D: Group separator
U+001E: Record separator
U+0085: "control"
U+2028: Line separator
U+2029: Paragraph separator

> It looks like \x0b and \x0c (vertical tab and form feed) were first
> considered line breaks in Python 2.7

Correct: U+000B and U+000C were added to Python 2.7 and 3.2.

> It might be worth putting a "changed in 2.7" note somewhere in the docs

We add the following syntax exactly for this:

   .. versionchanged:: 2.6
      Also unset environment variables when calling :meth:`os.environ.clear`
      and :meth:`os.environ.pop`.

If you downloaded Python source code, go into Doc/ directory and run "make html" to compile the doc to HTML.

http://docs.python.org/devguide/setup.html
http://docs.python.org/devguide/docquality.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 10:23:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 08:23:07 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314692587.07.0.960873462658.issue12855@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 10:46:48 2011
From: report at bugs.python.org (honglei jiang)
Date: Tue, 30 Aug 2011 08:46:48 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1314694008.51.0.111154429098.issue7171@psf.upfronthosting.co.za>


Changes by honglei jiang <jhonglei at gmail.com>:


----------
nosy: +honglei.jiang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Tue Aug 30 11:11:37 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 09:11:37 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1314695497.71.0.402844870684.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that we should process in two steps:

* Expose low level C functions
* Write a high level reusing the best low level function depending on the OS

Low level functions:

* Expose clock_gettime() into the time module, with CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW constants, if available. The wrapper should be thin, so the result would be a tuple (sec, nsec) (to avoid issues with floating point numbers)
* Windows: GetTickCount, GetTickCount64 and QueryPerformaceCounter are monotonic. GetTickCount wraps after 50 days, so GetTickCount64 should be preferred. GetTickCount(64) returns a number of milliseconds. It looks like QueryPerformaceCounter has a better resolution than GetTickCount(64). I don't know when QueryPerformaceCounter does wrap? QueryPerformaceCounter is already exposed as time.clock().


High level:
* Use clock_gettime(CLOCK_MONOTONIC_RAW) on Linux>=2.6.28
* Use clock_gettime(CLOCK_MONOTONIC) on UNIX
* Use time.clock() (QueryPerformaceCounter) on Windows?
* If none of these functions is available, don't define the function

I propose time.monotonic() because I saw this name in different projects.

Pseudo-code for the time module:

monotonic = None
if hasattr(time, 'clock_gettime'):
  if hasattr(time, 'CLOCK_MONOTONIC_RAW'):
    def monotonic(): return time.clock_gettime(CLOCK_MONOTONIC_RAW)
  else:
    # i don't think that we should expose clock_gettime
    # if CLOCK_MONOTONIC is not available (or the function is useless)
    def monotonic(): return time.clock_gettime(CLOCK_MONOTONIC)
elif os.name == 'nt':
    def monotonic(): return time.clock()
if monotonic is not None:
   monotonic.__doc__ = 'monotonic time'
else:
   del monotonic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Aug 30 11:17:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 09:17:48 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1314695868.88.0.804574197258.issue10278@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Note: it would be very pratical if time.monotonic() has always the same unit on all platforms. clock_gettime() uses seconds (and nanoseconds), time.clock() uses also seconds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Aug 30 11:49:03 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 30 Aug 2011 09:49:03 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1314697743.72.0.350422384397.issue12857@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Tue Aug 30 11:55:37 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 30 Aug 2011 09:55:37 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314698137.39.0.409704309333.issue12850@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Tue Aug 30 12:27:41 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 30 Aug 2011 10:27:41 +0000
Subject: [issue12852] test_posix.test_fdlistdir() segfault on OpenBSD
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1314700061.53.0.178022439824.issue12852@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,

this is the result of gcc -E on Modules/posixmodule.o, asked by haypo.

Thanks for your help,

Cheers,
Remi.

----------
Added file: http://bugs.python.org/file23072/gcc-E-Modules_posixmodule_output

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12852>
_______________________________________

From report at bugs.python.org  Tue Aug 30 13:11:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Aug 2011 11:11:05 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314702665.94.0.995798340304.issue12850@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nothing specific, just a reflexive C++ induced dislike for linker-accessible globals in general.

However, while I slightly prefer the function driven API, I wouldn't actively oppose direct linker access if someone else wanted to check it in :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Tue Aug 30 13:49:04 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 30 Aug 2011 11:49:04 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1314704944.44.0.617943265663.issue10278@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The problem with QueryPerformanceCounter is that it drifts.  It has high resolution, but can drift far out of sync with GetTickCount64.
The best solutions on windows combine the two, but that's tricky to impolement.

QPC will wrap, but only after a long time.  its 64 bits, and with a frequency of 1GHz, that takes some 600 years.
Of course, with 10GHz we're down to 60 years, but by that time, we will have python 2.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10278>
_______________________________________

From report at bugs.python.org  Tue Aug 30 14:26:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Aug 2011 12:26:18 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1314707178.33.0.945438600759.issue11682@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The pep380 branch in my bitbucket repo has been updated with the refactored tests that Ryan Kelly put together at the PyconAU sprints (as well as being brought up to speed with 3.x tip).

The update depends on the new dis.get_opinfo() API added by issue #11816 (which is currently with Raymond for review).

The AST validator still needs to be updated to take into account the new syntax and the patch attribution needs to be updated to account for Ryan's contribution, but this is getting fairly close to being ready.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11682>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:03:35 2011
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 30 Aug 2011 14:03:35 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314713015.89.0.959269258486.issue12850@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Ok, I followed Nick's suggestion, and I finally found out how to write the code in order to avoid all (or most?) deadlocks without any change in the rest of CPython.  It requires a way to be sure that some callback function is invoked _at the next cross-bytecode point_, and not (or not much) later, which I also include here.  Here is the updated patch.

----------
Added file: http://bugs.python.org/file23073/stm2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:22:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Aug 2011 14:22:12 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <E1QyPCc-0003jQ-Sq@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 326a7e44bb66 by ?ric Araujo in branch '3.2':
Make bdist_* commands respect --skip-build passed to bdist (#10946)
http://hg.python.org/cpython/rev/326a7e44bb66

New changeset 2f69b4f3df2e by ?ric Araujo in branch 'default':
Merge fix for #10946 from 3.2
http://hg.python.org/cpython/rev/2f69b4f3df2e

New changeset afb12c6b79ba by ?ric Araujo in branch 'default':
Make bdist_* commands respect --skip-build passed to bdist (#10946).
http://hg.python.org/cpython/rev/afb12c6b79ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:26:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Aug 2011 14:26:28 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <E1QyPGl-0004A6-76@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4ff92eb1a915 by ?ric Araujo in branch '2.7':
Make bdist_* commands respect --skip-build passed to bdist (#10946)
http://hg.python.org/cpython/rev/4ff92eb1a915

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:28:00 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 30 Aug 2011 14:28:00 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1314714480.92.0.730814291982.issue9041@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

That is a good question.  While it is true that errors other than 'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is a bad thing.  Any errors that come out of 'PyFloat_AsDouble' should be handled on a case-by-case basis and not blindly passed back out the call chain.  Otherwise, we may end up passing back errors (which are who knows what) that make sense for a caller of 'PyFloat_AsDouble', but not for callers of 'g_set'.

Also, the interface would become variable, meaning that whenever 'PyFloat_AsDouble' introduces new exceptions, then this code would too, which would lead to a somewhat unpredictable interface for callers of 'g_set'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9041>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:41:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 14:41:18 +0000
Subject: [issue12858] crypt.mksalt: use ssl.RAND_pseudo_bytes() if available
Message-ID: <1314715278.55.0.540710035592.issue12858@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

A salt doesn't need to be strong random bits, but I'm not sure that Mersenne Twister is a best candidate to generate salt. It would be nice to use ssl.RAND_pseudo_bytes() if available.

Problem: implement random.choice() from a generator generating bytes => see issue #12754.

----------
components: Extension Modules
messages: 143215
nosy: haypo
priority: normal
severity: normal
status: open
title: crypt.mksalt: use ssl.RAND_pseudo_bytes() if available
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12858>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:42:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 14:42:44 +0000
Subject: [issue12858] crypt.mksalt: use ssl.RAND_pseudo_bytes() if available
In-Reply-To: <1314715278.55.0.540710035592.issue12858@psf.upfronthosting.co.za>
Message-ID: <1314715364.31.0.789975714401.issue12858@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +jafo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12858>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:42:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 14:42:48 +0000
Subject: [issue12754] Add alternative random number generators
In-Reply-To: <1313449307.14.0.643454119212.issue12754@psf.upfronthosting.co.za>
Message-ID: <1314715368.58.0.486595675611.issue12754@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Before trying to find the best (CS)PRNG, can't we start with ssl.RAND_bytes() and ssl.RAND_pseudo_bytes()? I would be nice to use ssl.RAND_pseudo_bytes() to generate crypt.mksalt(): see issue #12858

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:46:46 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 14:46:46 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314715606.44.0.47182649975.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I can fix the patch to list all the unicode line boundaries. The three places I've considered putting it are:

1. On the howto/unicode.html

2. Somewhere in the stdtypes.html#typesseq description (maybe with other notes at the bottom)

3. As a note to the stdtypes.html#str.splitlines method description (where it is in the previous patch.)

I can move it to any of these places if you think it's a better fit. I'll fix the list so that it's complete, add a note about \x0b and \x0c being added in 2.7/3.2, and possibly reference it from StreamReader.readline.

After confirming that my documentation matches the style guide, I'll make the docs, test the output, and upload a patch. I can do this for 2.7, 3.2 and 3.3 separately.

Let me know if that sounds good and if you have any further thoughts. I should be able to upload new patches in 10 hours (after work today).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:51:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 14:51:27 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1314715887.28.0.126670153345.issue10946@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I simplified my patch and pushed it.  I had to discover again that I needed to inject customized command objects into dist.command_obj, like you found out a few months ago when we had a private email discussion :)

> Using set_undefined_options in install_* is definitely not safe,
> because it fails if parent [command] has not set skip_build.
We can be sure (by looking at the code) that bdist always sets skip_build to something (False by default), so it?s not unsafe.

> Also skip_build has to be set to None in install_* (set_... needs
> that to work) which obviously breaks it.
Yes, skip_build on the subcommands needed to change from None to False, but I don?t see how it is a breakage; it?s just an harmless change needed for this bug fix, so I did it. :)

Thanks to everyone involved in this bug.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10946>
_______________________________________

From report at bugs.python.org  Tue Aug 30 16:55:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 14:55:43 +0000
Subject: [issue12759] "(?P=)" input for Tools/scripts/redemo.py raises
	unnhandled exception
In-Reply-To: <1313495654.73.0.277709437369.issue12759@psf.upfronthosting.co.za>
Message-ID: <1314716143.87.0.396881687954.issue12759@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great!  Feel free to ask any questions here or through the core-mentorship mailing list.  Remember to read the devguide and work from a Mercurial clone of Python 3.2.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12759>
_______________________________________

From report at bugs.python.org  Tue Aug 30 17:02:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 15:02:52 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314716572.46.0.0239774835546.issue12855@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 1. On the howto/unicode.html
> 2. Somewhere in the stdtypes.html#typesseq description (maybe with other notes at the bottom)
> 3. As a note to the stdtypes.html#str.splitlines method description (where it is in the previous patch.)

(3) is the best place. For Python 2, you should add a new unicode.splitlines entry, whereas the str.splitlines should be updated in Python 3.

> I can do this for 2.7, 3.2 and 3.3 separately.

You don't have to do it for 3.3: 2.7 and 3.2 are enough (I will do the change in 3.3 using Mercurial).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Aug 30 17:24:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 15:24:21 +0000
Subject: [issue2945] bdist_rpm does not list dist files (should effect upload)
In-Reply-To: <1211466871.95.0.658180804984.issue2945@psf.upfronthosting.co.za>
Message-ID: <1314717861.9.0.785013102992.issue2945@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Even thought bdist_rpm is gone from distutils2, this is a bug that can be fixed in distutils.  Adding the easy keyword to let potential contributors find this bug; hint: look at how bdist_dumb registers distributions with dist.dist_files.

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2945>
_______________________________________

From report at bugs.python.org  Tue Aug 30 17:43:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 15:43:23 +0000
Subject: [issue12853] global name 'r' is not defined in upload.py
In-Reply-To: <1314637700.16.0.440169429003.issue12853@psf.upfronthosting.co.za>
Message-ID: <1314719003.88.0.450012186658.issue12853@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does it work if you replace r with result?

----------
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12853>
_______________________________________

From report at bugs.python.org  Tue Aug 30 17:44:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 15:44:11 +0000
Subject: [issue9041] raised exception is misleading
In-Reply-To: <1277123013.52.0.887079191328.issue9041@psf.upfronthosting.co.za>
Message-ID: <1314719051.51.0.706831755006.issue9041@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/issue9041>
_______________________________________

From report at bugs.python.org  Tue Aug 30 18:05:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 16:05:28 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1314720328.69.0.362806925878.issue1215@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo
versions: +Python 3.3 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Tue Aug 30 18:35:16 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Aug 2011 16:35:16 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314722116.33.0.861998460269.issue12829@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My understanding is that what you did:
import xml.parsers.expat
is now the proper way to use expat. After some searching, it seems the sentence about direct use of pyexpat being deprecated refers to
http://sourceforge.net/tracker/?func=detail&aid=2745230&group_id=26590&atid=387667
"The location and name of the PyExpat module have moved in Python v2.6.1 from  xml.dom.ext.reader.PyExpat to xml.parsers.expat"
This is puzzling becasue xmo.parsers.expat dates back to 2.0 while I see no doc for xml.dom.ext... .

The deprecation notice should be deleted from the 3.x docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Tue Aug 30 18:39:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Aug 2011 16:39:52 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314722392.76.0.383695851335.issue12829@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This seems to be a Mac-only issue.

Barry, does this seem to be a security issue to you, or should we delete 2.6 from the versions?

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +barry, ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Tue Aug 30 18:57:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Aug 2011 16:57:51 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1314723471.98.0.891139258144.issue12555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file23074/8a0e40f4f004.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:00:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Aug 2011 17:00:14 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1314723614.83.0.451315291975.issue12555@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch implementing the latest PEP changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12555>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:04:40 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:04:40 +0000
Subject: [issue12859] readline implementation doesn't release the GIL
Message-ID: <1314723880.29.0.384914760858.issue12859@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

Modules/readline.c 's `call_readline` doesn't release the GIL while reading.

----------
messages: 143226
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: readline implementation doesn't release the GIL
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12859>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:05:30 2011
From: report at bugs.python.org (Lang Martin)
Date: Tue, 30 Aug 2011 17:05:30 +0000
Subject: [issue12860] http client attempts to send a readable object twice
Message-ID: <1314723930.88.0.607695250414.issue12860@psf.upfronthosting.co.za>


New submission from Lang Martin <lang.martin at gmail.com>:

on line 765 of client/http.py, the client loops over the read method, sending it's content to the web server. It appears as though the send method should return at this point; instead it falls through and attempts to send the data object through first self.sock.sendall, falling back to the iterable interface.

The result is that a readable data object must support a null __iter__ method, or if it supports both a working read and __iter__, the data will be sent to the server twice.

Change the break on line 768 to a return, and the expected behavior happens.

----------
messages: 143227
nosy: langmartin
priority: normal
severity: normal
status: open
title: http client attempts to send a readable object twice
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12860>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:10:42 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:10:42 +0000
Subject: [issue12859] readline implementation doesn't release the GIL
In-Reply-To: <1314723880.29.0.384914760858.issue12859@psf.upfronthosting.co.za>
Message-ID: <1314724242.24.0.516981791976.issue12859@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Whoops, sorry, invalid. It doesn't need to. It is handled in PyOS_Readline.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12859>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:15:55 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:15:55 +0000
Subject: [issue12861] PyOS_Readline uses single lock
Message-ID: <1314724555.55.0.18633205677.issue12861@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

In Parser/myreadline.c PyOS_Readline uses a single lock (`_PyOS_ReadlineLock`). I guess it is so that we don't have messed up stdin reads. Or are there other technical reasons?

However, it should work to call this function from multiple threads with different/independent `sys_stdin` / `sys_stdout`.

----------
messages: 143229
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: PyOS_Readline uses single lock
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12861>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:30:54 2011
From: report at bugs.python.org (Daniel Fortunov)
Date: Tue, 30 Aug 2011 17:30:54 +0000
Subject: [issue12862] ConfigParser does not implement "comments need to be
	preceded by a whitespace character" correctly
Message-ID: <1314725453.99.0.502494798896.issue12862@psf.upfronthosting.co.za>


New submission from Daniel Fortunov <pythonbugtracker at danielfortunov.com>:

ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly and in most cases will treat a value beginning with a comment character as a comment, even though it is not preceded by a whitespace character.

The ConfigParser documentation states:
"""
Comments may appear on their own in an otherwise empty line, or may be entered in lines holding values or section names. In the latter case, they need to be preceded by a whitespace character to be recognized as a comment.
"""

This suggests that in the following configuration file, the value of 'password' would be read as ';23bUx1'.

[test_config]
password=;23bUx1
username=bar

In fact, there appears to be a bug in the following code within RawConfigParser._read():

    if vi in ('=', ':') and ';' in optval:
        # ';' is a comment delimiter only if it follows
        # a spacing character
        pos = optval.find(';')
        if pos != -1 and optval[pos-1].isspace():
            optval = optval[:pos]
    optval = optval.strip()

For the example file above, vi==';' and optval==';23bUx1\r'. pos therefore takes the value 0, and the second part of the compound if statement which checks if the preceding character is a space ends up looking at optval[-1] -- the last character in optval -- which is \r, since it has not yet been stripped.

I think this can be resolved by changing the line:
    if pos != -1 and optval[pos-1].isspace():
to:
    if pos > 0 and optval[pos-1].isspace():

Thus, the "if preceded by a space" case is only considered if the comment character appears *after* the first character in the value. (And if it appears as the very *first* character, then by definition it cannot be preceded by a space!)

A rather fragile workaround (which works only if there is only one single value affected by this bug) would be to ensure that the affected value is defined on the last line of your config file, the file does not end with a carriage return. In this case, the optval[-1] would return a non-whitespace character and prevent the value being considered a comment.

The above analysis pertains to Python 2.7.2, and I see that the implementation has been re-written in python 3 so this bug doesn't seem to exist there.

----------
components: Library (Lib)
messages: 143230
nosy: DanielFortunov
priority: normal
severity: normal
status: open
title: ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12862>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:34:32 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Aug 2011 17:34:32 +0000
Subject: [issue12844] Support more than 255 arguments
In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>
Message-ID: <1314725672.95.0.758105464016.issue12844@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12844>
_______________________________________

From report at bugs.python.org  Tue Aug 30 19:49:39 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:49:39 +0000
Subject: [issue12861] PyOS_Readline uses single lock
In-Reply-To: <1314724555.55.0.18633205677.issue12861@psf.upfronthosting.co.za>
Message-ID: <1314726579.32.0.911486896125.issue12861@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Ok, it seems that the Modules/readline.c implementation is also not really threadsafe... (Whereby, I think it should be.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12861>
_______________________________________

From report at bugs.python.org  Tue Aug 30 20:34:35 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 30 Aug 2011 18:34:35 +0000
Subject: [issue1462440] socket and threading: udp multicast setsockopt fails
Message-ID: <1314729275.31.0.0513862762134.issue1462440@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1462440>
_______________________________________

From report at bugs.python.org  Tue Aug 30 20:50:58 2011
From: report at bugs.python.org (GPU Group)
Date: Tue, 30 Aug 2011 18:50:58 +0000
Subject: [issue12863] py32 > Lib > xml.minidom > usage feedback > overrides
Message-ID: <1314730258.77.0.934592208452.issue12863@psf.upfronthosting.co.za>


New submission from GPU Group <gpugroup at gmail.com>:

Py32 > Lib > xml.dom.minidom  > usage feedback > overrides
I like the minidom. I use it -and over-ride the Element.writexml() and _write_data() methods for a few of my Blender.org B259 personal export scripts to formats:

.x3d - a www.web3d.org public format, an xml-like version of vitual reality .vrml, except it wants single quotes with double quotes inside:
'"EXAMINE" "ANY"'. It's an attribute heavy format.

.kml - an earth.google.com format, element heavy. By default minidom puts extra lines backslash n so the following comes out on 3 lines:
		<description>
			1909 era from 1891 to 1930
		</description>
and I want something more compact on one line:
<description>1909 era from 1891 to 1930</description>

In both cases I over-ride the minidom:
save_original_writexml = xml.dom.minidom.Element.writexml 
xml.dom.minidom.Element.writexml = writexml_pluto
... do my exporting ...
# other registered scripts share the minidom, so restore it
xml.dom.minidom.Element.writexml = save_original_writexml

I'm happy with this, as long as I remember to update my minidom overrides with new py versions. I mention it in case I'm using it wrong or in case you like what I'm doing and want to adopt or spread the word.

more...
kml over-ride for compact element-heaviness:
    def _write_data_orig(writer, data):
        "Writes datachars to writer."
        if data:
            data = data.replace("&", "&amp;").replace("<", "&lt;"). \
                        replace("\"", "&quot;").replace(">", "&gt;")
            writer.write(data)
          
            
    def writexml_plutokml(self, writer, indent="", addindent="", newl=""):
        # indent = current indentation
        # addindent = indentation to add to higher levels
        # newl = newline string
        writer.write(indent+"<" + self.tagName)

        attrs = self._get_attributes()
        a_names = sorted(attrs.keys())

        for a_name in a_names:
            writer.write(" %s=\"" % a_name)
            _write_data_orig(writer, attrs[a_name].value)
            writer.write("\"")
        if self.childNodes:
            #pluto- writer.write(">%s"%(newl))
            writer.write(">")  # pluto+
            tx = False  # pluto+
            k=0  # pluto+
            for node in self.childNodes:
              k=k+1  # p+
              if node.nodeType == Node.TEXT_NODE:  # p+
                node.writexml(writer,"","","")      # p+
                tx = True           # p+
              else:    # p+
                if k == 1: writer.write(newl) # p+
                node.writexml(writer, indent + addindent, addindent, newl)
            if tx:  # p+
                writer.write("%s</%s>%s" % ("",self.tagName,newl))  # p+
            else:  # p+
                writer.write("%s</%s>%s" % (indent, self.tagName, newl))
        else:
            writer.write("/>%s"%(newl))

x3d over-ride for apos (versus quote) attribute delimeters:
    def _write_data_pluto(writer, data):
        "Writes datachars to writer."
        if data:
            data = data.replace("&", "&amp;").replace("<", "&lt;"). \
                        replace("'", "&apos;").replace(">", "&gt;")   # pluto: apos instead of quot
            writer.write(data)

    def writexml_pluto(self, writer, indent="", addindent="", newl=""):
        # indent = current indentation
        # addindent = indentation to add to higher levels
        # newl = newline string
        writer.write(indent+"<" + self.tagName)

        attrs = self._get_attributes()
        a_names = sorted(attrs.keys())

        for a_name in a_names:
            writer.write(" %s='" % a_name)  # pluto, orig: writer.write(" %s=\"" % a_name)
            _write_data_pluto(writer, attrs[a_name].value)
            writer.write("'")  # pluto, orig: writer.write("\"")
        if self.childNodes:
            writer.write(">%s" % (newl))
            for node in self.childNodes:
                node.writexml(writer, indent+addindent, addindent, newl)
            writer.write("%s</%s>%s" % (indent, self.tagName, newl))
        else:
            writer.write("/>%s"%(newl))

----------
components: XML
messages: 143232
nosy: GPU.Group
priority: normal
severity: normal
status: open
title: py32 > Lib > xml.minidom > usage feedback > overrides
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12863>
_______________________________________

From report at bugs.python.org  Tue Aug 30 22:07:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Aug 2011 20:07:26 +0000
Subject: [issue9651] ctypes crash when writing zerolength string buffer to file
In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za>
Message-ID: <E1QyUai-0003G2-GA@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5df1609fbd8f by Amaury Forgeot d'Arc in branch '3.2':
Issue #9651: Fix a crash when ctypes.create_string_buffer(0) was passed to
http://hg.python.org/cpython/rev/5df1609fbd8f

New changeset d8c73a7d65f8 by Amaury Forgeot d'Arc in branch 'default':
Merge from 3.2:
http://hg.python.org/cpython/rev/d8c73a7d65f8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9651>
_______________________________________

From report at bugs.python.org  Tue Aug 30 22:07:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Aug 2011 20:07:26 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <E1QyUai-0003G2-GX@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 5e23532f694d by Amaury Forgeot d'Arc in branch '3.2':
Issue #11241: subclasses of ctypes.Array can now be subclassed.
http://hg.python.org/cpython/rev/5e23532f694d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Tue Aug 30 22:07:48 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Aug 2011 20:07:48 +0000
Subject: [issue9651] ctypes crash when writing zerolength string buffer to file
In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za>
Message-ID: <E1QyUb4-0003HU-TW@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4aa00f465b4f by Amaury Forgeot d'Arc in branch '2.7':
Issue #9651: Fix a crash when ctypes.create_string_buffer(0) was passed to
http://hg.python.org/cpython/rev/4aa00f465b4f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9651>
_______________________________________

From report at bugs.python.org  Tue Aug 30 22:10:40 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Aug 2011 20:10:40 +0000
Subject: [issue9651] ctypes crash when writing zerolength string buffer to file
In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za>
Message-ID: <1314735040.68.0.818863013964.issue9651@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9651>
_______________________________________

From report at bugs.python.org  Tue Aug 30 23:56:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 21:56:03 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1314741363.51.0.771027280396.issue1215@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> def handler(signal, stackframe):
>     print "OUCH"
>     stdout.flush()
>     _exit(1)

What do you want to do on a SIGSEGV? On a real fault, you cannot rely on  Python internal state, you cannot use any Python object. To handle a real SIGSEGV fault, you have to implement a signal handler using only *signal safe* functions.... in C.

See faulthandler_fatal_error() function:
https://github.com/haypo/faulthandler/blob/master/faulthandler.c#L257

> The documentation for this can now point to the faulthandler module
> (in Python 3).

For your information, faulthandler is available for Python older than 3.3 as a third party module:
http://pypi.python.org/pypi/faulthandler

> segfault is the following C module:

For tests, you can use ctypes.string_at(0) to read a word from NULL.

--

faulthandler installs a signal handler for SIGSEGV, SIGFPE, SIGABRT, SIGBUS and SIGILL signals:
http://docs.python.org/dev/library/faulthandler.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Tue Aug 30 23:59:21 2011
From: report at bugs.python.org (simohe)
Date: Tue, 30 Aug 2011 21:59:21 +0000
Subject: [issue12864] 2to3 creates illegal code on import a.b inside a package
Message-ID: <1314741561.82.0.752843827348.issue12864@psf.upfronthosting.co.za>


New submission from simohe <simohe at besonet.ch>:

When the current module is in a package and imports submodules, the following lines are converted to illegal code.

-import sub.subsub
+from . import sub.subsub

-import sub, sub.subsub, sub2
+from . import sub, sub.subsub, sub2

A valid alternative:

-import sub.subsub
+from .sub import subsub as _dummy

-import sub, sub.subsub, sub2
+from . import sub, sub2\nfrom .sub import subsub as _dummy

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 143237
nosy: simohe
priority: normal
severity: normal
status: open
title: 2to3 creates illegal code on import a.b inside a package
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12864>
_______________________________________

From report at bugs.python.org  Wed Aug 31 00:09:04 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Aug 2011 22:09:04 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1314742144.01.0.854541950147.issue11241@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Wed Aug 31 00:35:13 2011
From: report at bugs.python.org (Andrey Men)
Date: Tue, 30 Aug 2011 22:35:13 +0000
Subject: [issue12865] import SimpleHTTPServer
Message-ID: <1314743713.19.0.860549510488.issue12865@psf.upfronthosting.co.za>


New submission from Andrey Men <menangen at gmail.com>:

In russian windows seven SP1, x32, installed from 2.7.1/2.7.2 MSI installer:

>>> import SimpleHTTPServer

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    import SimpleHTTPServer
  File "C:\Python\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "C:\Python\lib\SimpleHTTPServer.py", line 204, in SimpleHTTPRequestHandler
    mimetypes.init() # try to read system mime.types
  File "C:\Python\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "C:\Python\lib\mimetypes.py", line 259, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "C:\Python\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)

----------
messages: 143238
nosy: Andrey.Men
priority: normal
severity: normal
status: open
title: import SimpleHTTPServer
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12865>
_______________________________________

From report at bugs.python.org  Wed Aug 31 00:51:55 2011
From: report at bugs.python.org (=?utf-8?q?Peder_J=C3=B8rgensen?=)
Date: Tue, 30 Aug 2011 22:51:55 +0000
Subject: [issue12866] Want to submit our Audioop.c patch for 24bit audio
Message-ID: <1314744712.67.0.770855933698.issue12866@psf.upfronthosting.co.za>


New submission from Peder J?rgensen <peder.jorgensen at gmail.com>:

Hi,
I'm working with audio in python 2.7 and I needed Audioop to work with
24bit files, it currently only supports 8 16 and 32 bit sound files.
(24bit files are very common in the audio world)
My brother knows c quite well, so he managed to patch it up to support 24bit files for me, he's a bit too shy to try and get it into the standard python package him self, so I thought i'd give it a go for him :) 

I think the updated audioop.c would be a great add-on to python, it's 100% backwards compatible, and should work fine with python 3.
I searched for hours and hours to see if someone had fixed it before, but found nothing.
Not sure if this is the right place for this kind of thing, but was the best place I could find on python.org

Also!
The file i uploaded is not ready for release, my brother will probably want to go over it a few times and do more testing.

----------
files: audioop24.c
messages: 143239
nosy: Peder.J?rgensen
priority: normal
severity: normal
status: open
title: Want to submit our Audioop.c patch for 24bit audio
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23075/audioop24.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12866>
_______________________________________

From report at bugs.python.org  Wed Aug 31 00:53:16 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Aug 2011 22:53:16 +0000
Subject: [issue12865] import SimpleHTTPServer
In-Reply-To: <1314743713.19.0.860549510488.issue12865@psf.upfronthosting.co.za>
Message-ID: <1314744796.81.0.1612625483.issue12865@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is a duplicate of issue9291.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> mimetypes initialization fails on Windows because of non-Latin characters in registry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12865>
_______________________________________

From report at bugs.python.org  Wed Aug 31 01:20:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Aug 2011 23:20:26 +0000
Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to
	Parse()
In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za>
Message-ID: <1314746426.61.0.713800634762.issue12829@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This is the same issue as highlighted by Issue6676.  The root cause is attempting to reuse a parser instance and that is known to not work with the version of expat included with Python.  Whether the test program crashes with a memory access violation or just uses uninitialized memory depends on the version of malloc in use and what protections the linker and os use.  Even on Mac OS X, the test program does not segfault on earlier versions of OS X (like 10.5).  And on 10.6 and 10.7 if you build python with pymalloc it usually does not segfault.  But that doesn't mean it is working properly.  At a minimum, the single use restriction should be documented; if anyone is interested, they could look into adding any more recent fixes to expat and plugging remaining reuse holes.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> expat parser throws Memory Error when parsing multiple files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12829>
_______________________________________

From report at bugs.python.org  Wed Aug 31 01:25:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Aug 2011 23:25:51 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1314746751.0.0.345992489812.issue6676@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I agree that, at a minimum, the documentation should be updated to include a warning about not reusing a parser instance.  Whether it's worth trying to plug all the holes in the expat library is another issue (see, for instance, issue12829).  David, would you be willing to propose a wording for a documentation change?

----------
nosy: +ned.deily
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Wed Aug 31 01:34:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Aug 2011 23:34:09 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1314747249.85.0.687945374992.issue6676@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also, note issue1208730 proposes a feature to expose a binding for XML_ParserReset and has the start of a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6676>
_______________________________________

From report at bugs.python.org  Wed Aug 31 02:52:01 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 31 Aug 2011 00:52:01 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <CAA9uavBKHBZQRYb_oQU-Jpr--BNC34gRbKVdnrOERJ5wx-HLAg@mail.gmail.com>
Message-ID: <CAA9uavBU5TCMFuzwsgLrfHSNjpGu92DENOgfhsR-nujgVV9wfA@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 31 August 2011 07:56, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> def handler(signal, stackframe):
>> ? ? print "OUCH"
>> ? ? stdout.flush()
>> ? ? _exit(1)
>
> What do you want to do on a SIGSEGV? On a real fault, you cannot rely on ?Python internal state, you cannot use any Python object. To handle a real SIGSEGV fault, you have to implement a signal handler using only *signal safe* functions.... in C.

Well, strictly speaking, it is very hard or impossible to write C code
that's guaranteed to be safe after an unexpected segv too; who knows
what might have caused it. ?The odds are probably better that it will work in
in C than in Python. ?At any rate I think it's agreed that the
original code is not supported and it's just the docs that need to
change.

So what do you think of
<http://bugs.python.org/file22989/20110822-1525-signal-doc.diff> ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Wed Aug 31 04:35:38 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Wed, 31 Aug 2011 02:35:38 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314758138.69.0.705205578449.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I've attached a patch for 2.7 and will attach one for 3.2 in a minute.

I built the docs for both 2.7 and 3.2 and verified that there were no warnings and that the resulting web pages looked okay.

Things to consider:

* Placement of unicode.splitlines() method: I placed it next to str.splitlines. I didn't want to place it with the unicode methods further down because docs say "The following methods are present only on unicode objects"

* The docs for codecs.readlines() already mentions "Line-endings are implemented using the codec?s decoder method and are included in the list entries if keepends is true." 

* Feel free to make any wording/style suggestions.

----------
Added file: http://bugs.python.org/file23076/linebreakdoc.v2.py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Wed Aug 31 04:35:54 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Wed, 31 Aug 2011 02:35:54 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314758154.5.0.89132337788.issue12855@psf.upfronthosting.co.za>


Changes by Matthew Boehm <boehm.matthew at gmail.com>:


Added file: http://bugs.python.org/file23077/linebreakdoc.v2.py32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Wed Aug 31 04:41:52 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Wed, 31 Aug 2011 02:41:52 +0000
Subject: [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314758512.68.0.304754210843.issue12409@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________

From report at bugs.python.org  Wed Aug 31 05:03:58 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Wed, 31 Aug 2011 03:03:58 +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: <1314759838.27.0.250266610877.issue11176@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Wed Aug 31 05:43:03 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 31 Aug 2011 03:43:03 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1314762183.14.0.0116018745232.issue11241@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Thanks a lot for committing this for me Amaury.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Wed Aug 31 06:29:23 2011
From: report at bugs.python.org (Jordan Meyer)
Date: Wed, 31 Aug 2011 04:29:23 +0000
Subject: [issue12867] linecache.getline() Returning Error
Message-ID: <1314764963.3.0.192985058794.issue12867@psf.upfronthosting.co.za>


New submission from Jordan Meyer <jordanmeyer1991 at gmail.com>:

In trying to use the linecache.getline() function to extra data from a plain-text database format that I'm building. Every time I make a call to it (even from the interpreter directly) I get an error like the one below. I believe the problem lies in the linecache module itself.

Traceback (most recent call last):
  File "/Users/jordanmeyer/Documents/Python/eFlashcard/alpha/0.1a2/eFlashcard_0.1a2.py", line 59, in <module>
    eFlashcard_main()
  File "/Users/jordanmeyer/Documents/Python/eFlashcard/alpha/0.1a2/eFlashcard_0.1a2.py", line 17, in eFlashcard_main
    eFlashcard_build()
  File "/Users/jordanmeyer/Documents/Python/eFlashcard/alpha/0.1a2/eFlashcard_0.1a2.py", line 31, in eFlashcard_build
    while str(linecache.getline(lib_file, lib_index, module_globals=None)) != '':
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/linecache.py", line 15, in getline
    lines = getlines(filename, module_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/linecache.py", line 41, in getlines
    return updatecache(filename, module_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/linecache.py", line 76, in updatecache
    if not filename or (filename.startswith('<') and filename.endswith('>')):
AttributeError: '_io.TextIOWrapper' object has no attribute 'startswith'

----------
components: Library (Lib)
messages: 143247
nosy: Jordan.Meyer
priority: normal
severity: normal
status: open
title: linecache.getline() Returning Error
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12867>
_______________________________________

From report at bugs.python.org  Wed Aug 31 06:43:51 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 31 Aug 2011 04:43:51 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1314765831.62.0.550647624779.issue12857@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for the review, Nick.  I'll be uploading a new patch in a couple hours with your recommended fixes.

Regarding the comments on python-ideas, would it be better to use a weakref proxy around the function, to help with the reference cycles?  That's what I was doing with my closure-based solution.  I didn't do it here just to see what would happen and I didn't see any problems in my very limited testing (basically just 'make test').  I don't mind using weakrefs and, if it matters, I could pre-allocate the weakref proxy in PyFunction_New to save a little overhead at each call. 

For the moment I left in the code to limit f_func to only functions.  I'll respond to that on python-ideas.

Finally, how does this patch relate to the ABI?  I'm not too familiar with it (read through PEP 384) and want to make sure I'm okay here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Wed Aug 31 07:47:14 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 31 Aug 2011 05:47:14 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1314769634.75.0.81421110361.issue12857@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On second thought, I probably won't be able to get an updated patch tonight.  I need to mull over the PyEval_EvalFunction implementation and the interaction with fast_function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12857>
_______________________________________

From report at bugs.python.org  Wed Aug 31 09:21:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 31 Aug 2011 07:21:30 +0000
Subject: [issue12867] linecache.getline() Returning Error
In-Reply-To: <1314764963.3.0.192985058794.issue12867@psf.upfronthosting.co.za>
Message-ID: <1314775290.24.0.839457745014.issue12867@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The linecache module functions take a filename string as an argument, not a file object.  Try:

   linecache.getlines("/path/to/filename", lineno)

http://docs.python.org/py3k/library/linecache.html

----------
nosy: +ned.deily
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12867>
_______________________________________

From report at bugs.python.org  Wed Aug 31 09:55:33 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 31 Aug 2011 07:55:33 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
Message-ID: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>


New submission from Remi Pointel <python at xiri.fr>:

Hello,

the test_stack_overflow failed on OpenBSD.

Don't hesitate if you need more information.

Details:
$ ./python Lib/test/test_faulthandler.py 
test_disable (__main__.FaultHandlerTests) ... ok
test_dump_traceback (__main__.FaultHandlerTests) ... ok
test_dump_traceback_file (__main__.FaultHandlerTests) ... ok
test_dump_traceback_threads (__main__.FaultHandlerTests) ... ok
test_dump_traceback_threads_file (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_cancel (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_file (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_repeat (__main__.FaultHandlerTests) ... ok
test_dump_tracebacks_later_twice (__main__.FaultHandlerTests) ... ok
test_enable_file (__main__.FaultHandlerTests) ... ok
test_enable_single_thread (__main__.FaultHandlerTests) ... ok
test_fatal_error (__main__.FaultHandlerTests) ... ok
test_gil_released (__main__.FaultHandlerTests) ... ok
test_is_enabled (__main__.FaultHandlerTests) ... ok
test_read_null (__main__.FaultHandlerTests) ... ok
test_register (__main__.FaultHandlerTests) ... ok
test_register_chain (__main__.FaultHandlerTests) ... ok
test_register_file (__main__.FaultHandlerTests) ... ok
test_register_threads (__main__.FaultHandlerTests) ... ok
test_sigabrt (__main__.FaultHandlerTests) ... ok
test_sigbus (__main__.FaultHandlerTests) ... ok
test_sigfpe (__main__.FaultHandlerTests) ... ok
test_sigill (__main__.FaultHandlerTests) ... ok
test_sigsegv (__main__.FaultHandlerTests) ... ok
test_stack_overflow (__main__.FaultHandlerTests) ... FAIL
test_unregister (__main__.FaultHandlerTests) ... ok

======================================================================
FAIL: test_stack_overflow (__main__.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 187, in test_stack_overflow
    other_regex='unable to raise a stack overflow')
  File "Lib/test/test_faulthandler.py", line 105, in check_fatal_error
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$|unable to raise a stack overflow' not found in ''

----------------------------------------------------------------------
Ran 27 tests in 16.938s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 551, in <module>
    test_main()
  File "Lib/test/test_faulthandler.py", line 548, in test_main
    support.run_unittest(FaultHandlerTests)
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1328, in run_unittest
    _run_suite(suite)
  File "/home/remi/dev/cpython_test/Lib/test/support.py", line 1303, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_faulthandler.py", line 187, in test_stack_overflow
    other_regex='unable to raise a stack overflow')
  File "Lib/test/test_faulthandler.py", line 105, in check_fatal_error
    self.assertRegex(output, regex)
AssertionError: Regex didn't match: '^Fatal Python error: (?:Segmentation fault|Bus error)\n\nCurrent\\ thread\\ XXX:\n  File "<string>", line 3 in <module>$|unable to raise a stack overflow' not found in ''


Thanks a lot,

Remi.

----------
messages: 143251
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_faulthandler.test_stack_overflow() failed on OpenBSD
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 09:56:11 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 31 Aug 2011 07:56:11 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314777371.86.0.317631378578.issue12868@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Info: I read issue 12469 but I prefered to create new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 12:18:09 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 31 Aug 2011 10:18:09 +0000
Subject: [issue12850] [PATCH] stm.atomic
In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za>
Message-ID: <1314785889.8.0.844250548988.issue12850@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12850>
_______________________________________

From report at bugs.python.org  Wed Aug 31 14:02:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Aug 2011 12:02:31 +0000
Subject: [issue1215] documentation doesn't say that you can't handle C
	segfaults from python
In-Reply-To: <CAA9uavBU5TCMFuzwsgLrfHSNjpGu92DENOgfhsR-nujgVV9wfA@mail.gmail.com>
Message-ID: <201108311402.11025.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le mercredi 31 ao?t 2011 02:52:01, vous avez ?crit :
> > What do you want to do on a SIGSEGV? On a real fault, you cannot rely on
> >  Python internal state, you cannot use any Python object. To handle a
> > real SIGSEGV fault, you have to implement a signal handler using only
> > *signal safe* functions.... in C.
> 
> Well, strictly speaking, it is very hard or impossible to write C code
> that's guaranteed to be safe after an unexpected segv too

It is possible if you only use signal safe functions. I think that no Python 
function is signal safe :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1215>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:33:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 14:33:08 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1314801188.66.0.821296712531.issue12765@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Still failing.

----------
resolution: fixed -> 
stage: commit review -> needs patch
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:38:25 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 31 Aug 2011 14:38:25 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1314801505.8.0.150928643615.issue9998@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There is a problem in this area of the code, not especially with the patch but with how gcc works (or doesn't). To illustrate:

-----------------------
Version info
-----------------------
vinay at eta-hardy:/tmp$ uname -a
Linux eta-hardy 2.6.24-29-generic #1 SMP Wed Aug 10 16:34:32 UTC 2011 i686 GNU/Linux
vinay at eta-hardy:/tmp$ gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-----------------------
Create an empty file:
-----------------------
vinay at eta-hardy:/tmp$ touch dummy.c
-----------------------
Compile a shared library from it:
-----------------------
vinay at eta-hardy:/tmp$ gcc -shared -o libdummy.so dummy.c
-----------------------
Invoke gcc with patched command line:
-----------------------
vinay at eta-hardy:/tmp$ gcc -L /tmp -Wl,t -o /dev/null -ldummy
/usr/bin/ld: t: No such file: No such file or directory
collect2: ld returned 1 exit status
-----------------------
It's not patch related, here's what happens with the unpatched line
-----------------------
vinay at eta-hardy:/tmp$ gcc -Wl,t -o /dev/null -ldummy
/usr/bin/ld: t: No such file: No such file or directory
collect2: ld returned 1 exit status
-----------------------
Calling ld directly works as expected. With no search path:
-----------------------
vinay at eta-hardy:/tmp$ ld -t -o /dev/null -ldummy
ld: mode elf_i386
ld: cannot find -ldummy
-----------------------
With the search path supplied:
-----------------------
vinay at eta-hardy:/tmp$ ld -t -L /tmp -o /dev/null -ldummy
ld: mode elf_i386
-ldummy (/tmp/libdummy.so)
ld: warning: cannot find entry symbol _start; not setting start address
vinay at eta-hardy:/tmp$ 

So, ISTM that the find_library code needs changing to use ld, else it will not work on all platforms.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:38:38 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 31 Aug 2011 14:38:38 +0000
Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr
Message-ID: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

PyOS_StdioReadline from Parser/myreadline.c is printing the prompt on stderr.

I think it should print it on the given parameter sys_stdout. Other readline implementations (like from the readline module) also behave this way.

Even if it really is supposed to write on stderr, it should use the `sys.stderr` and not the system stderr.

----------
messages: 143256
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: PyOS_StdioReadline is printing the prompt on stderr
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12869>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:40:21 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 31 Aug 2011 14:40:21 +0000
Subject: [issue12861] PyOS_Readline uses single lock
In-Reply-To: <1314724555.55.0.18633205677.issue12861@psf.upfronthosting.co.za>
Message-ID: <1314801621.21.0.536710883435.issue12861@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Even more problematic: The readline lib itself is absolutely not designed in a way to be used from multi threads at once.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12861>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:42:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 14:42:11 +0000
Subject: [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1314801731.26.0.249512778345.issue11435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

After getting Georg?s greenlight on python-dev, I have adapted the source reST role for 2.7 and updated all links.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11435>
_______________________________________

From report at bugs.python.org  Wed Aug 31 16:52:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 31 Aug 2011 14:52:36 +0000
Subject: [issue10086] test_sysconfig failure when prefix matches /site
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <E1Qym9b-0000oC-Al@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1e01543c3d0a by ?ric Araujo in branch '3.2':
Fix test_sysconfig when run from a Python installed under /site (#10086).
http://hg.python.org/cpython/rev/1e01543c3d0a

New changeset 0968acf0e6db by ?ric Araujo in branch 'default':
Merge fix for #10086 from 3.2
http://hg.python.org/cpython/rev/0968acf0e6db

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Aug 31 17:16:47 2011
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 31 Aug 2011 15:16:47 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313688161.11.0.633868309496.issue12765@psf.upfronthosting.co.za>
Message-ID: <CAHkzgdhNQQDDNm1ac7fn2tSuB2eRJCAFqYEVXrMQkvJuQ_E+MQ@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

I'm on vacation right now and can't get to it...

Bill

On Thu, Aug 18, 2011 at 12:22 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Bill is the owner of that buildbot.
>
> ----------
> nosy: +janssen
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12765>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12765>
_______________________________________

From report at bugs.python.org  Wed Aug 31 17:21:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 15:21:28 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1314804088.98.0.469179187506.issue12785@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've tested the attached patch against 3.3 on Windows XP, and it
> seems to fix the test_database failures.
Thanks.

> I've uploaded the exact diff of what I tested with.
Your diff matches the one I get after updating my clone, we?re good.

> I tested both with and without the change you suggested in msg142773 -
> the tests pass in both cases.
I have to have another look at the code to make sure this makes sense and take the right approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12785>
_______________________________________

From report at bugs.python.org  Wed Aug 31 17:35:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 31 Aug 2011 15:35:19 +0000
Subject: [issue10086] test_sysconfig failure when prefix matches /site
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <E1Qymow-0005Iw-GS@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4dcbae65df3f by ?ric Araujo in branch '2.7':
Fix test_sysconfig when run from a Python installed under /site (#10086).
http://hg.python.org/cpython/rev/4dcbae65df3f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Aug 31 17:37:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 15:37:08 +0000
Subject: [issue10086] test_sysconfig failure when prefix matches /site
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1314805028.6.0.197611504455.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I think I can commit this fix for a minor issue in a test without
> worrying about regressions.  I manually tested and it?s fixed.

Done!  Thanks again.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Aug 31 17:52:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 15:52:42 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314805962.42.0.125362083441.issue12386@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I only meant that when writing data resources, one might reasonably
> use 'wb', but when writing scripts, which are text, 'w' is more
> appropriate.

I don?t see why.  All text is bytes, so we can do all I/O in bytes when writing resources and avoid special-casing.

> BTW, IIRC I have fixed it in the pythonv branch.
> https://bitbucket.org/vinay.sajip/pythonv

A link to a specific changeset or file would be great.

[trevor]
> i see the same behavior - the error occurs leaving an empty RESOURCES file

Do you see that when running a test, a command or some other code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Wed Aug 31 18:00:11 2011
From: report at bugs.python.org (trevor)
Date: Wed, 31 Aug 2011 16:00:11 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314806411.27.0.121100644491.issue12386@psf.upfronthosting.co.za>


trevor <trevor at well.com> added the comment:

[eric.araujo]
> Do you see that when running a test, a command or some other code?

when attempting to install a self-created package.

tools from 3.3a ~72060:1696e2789d91

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Wed Aug 31 19:29:34 2011
From: report at bugs.python.org (Matt Chaput)
Date: Wed, 31 Aug 2011 17:29:34 +0000
Subject: [issue12870] Regex object should have introspection methods
Message-ID: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>


New submission from Matt Chaput <matt at whoosh.ca>:

Several times in the recent past I've wished for the following methods on the regular expression object. These would allow me to speed up search and parsing code, by limiting the number of regex matches I need to try.

literal_prefix(): Returns any literal string at the start of the pattern (before any "special" parts). E.g., for the pattern "ab(c|d)ef" the method would return "ab". For the pattern "abc|def" the method would return "". When matching a regex against keys in a btree, this would let me limit the search to just the range of keys with the prefix.

first_chars(): Returns a string/list/set/whatever of the possible first characters that could appear at the start of a matching string. E.g. for the pattern "ab(c|d)ef" the method would return "a". For the pattern "[a-d]ef" the method would return "abcd". When parsing a string with regexes, this would let me only have to test the regexes that could match at the current character.

As long as you're making a new regex package, I thought I'd put in a request for these :)

----------
components: Regular Expressions
messages: 143266
nosy: mattchaput
priority: normal
severity: normal
status: open
title: Regex object should have introspection methods
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12870>
_______________________________________

From report at bugs.python.org  Wed Aug 31 19:30:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 17:30:10 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314811810.44.0.480222297433.issue12868@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

OpenBSD's threads are userland threads, and sigaltstack() doesn't work when the program is built with -pthread:
http://marc.info/?l=openbsd-bugs&m=114323355014696&w=2

Note that POSIX warns about this:
http://www.opengroup.org/onlinepubs/000095399/functions/sigaltstack.html
""""
Use of this function by library threads that are not bound to
kernel-scheduled entities results in undefined behavior.
"""

I think we should skip this test on OpenBSD when Python is compiled with threads support.
Out of curiosity, could you try this:
$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?

And if you're motivated, you could try it again after having built python with './configure --without-threads'.

----------
components: +Tests
nosy: +haypo, neologix
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 19:54:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 31 Aug 2011 17:54:32 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1314813272.4.0.377831978088.issue12870@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

These additions sounds more useful as an external tool than regex functions/methods.  There are already a few tools able to "explain" what a regex matches.
The use cases you proposed are too specific to deserve new methods, and using them programmatically sounds like premature optimization IMHO.

----------
nosy: +ezio.melotti, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12870>
_______________________________________

From report at bugs.python.org  Wed Aug 31 19:59:36 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 31 Aug 2011 17:59:36 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314813576.33.0.456780707255.issue12868@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

Hi,

results:
>Out of curiosity, could you try this:
>$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?

$ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $?
zsh: illegal hardware instruction (core dumped)  ./python -c 
132

>And if you're motivated, you could try it again after having built python with './configure --without-threads'.

It does not build completely, I have a problem if I add --without-threads:
$ make
[...]
./Modules/posixmodule.c:4582: undefined reference to `sched_get_priority_min'
libpython3.3m.a(posixmodule.o)(.text+0x430b): In function `posix_sched_get_priority_max':
./Modules/posixmodule.c:4565: undefined reference to `sched_get_priority_max'
collect2: ld returned 1 exit status
*** Error code 1

It seems that it needs -pthread even if I precise --without-threads. Must I open a new ticket for this problem?

Thanks for your help,

Remi.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:03:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Aug 2011 18:03:42 +0000
Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled
	without threads
Message-ID: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If Pyton is configured without thread support (--without-threads), the compilation fails on OpenBSD :

$ make
[...]
./Modules/posixmodule.c:4582: undefined reference to `sched_get_priority_min'
libpython3.3m.a(posixmodule.o)(.text+0x430b): In function `posix_sched_get_priority_max':
./Modules/posixmodule.c:4565: undefined reference to `sched_get_priority_max'
collect2: ld returned 1 exit status
*** Error code 1

I didn't try on Linux, but I suppose that the issue is not specific to OpenBSD.

----------
components: Extension Modules
messages: 143270
nosy: haypo, rpointel
priority: normal
severity: normal
status: open
title: Disable sched_get_priority_min/max if Python is compiled without threads
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12871>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:04:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Aug 2011 18:04:20 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314813860.03.0.777329988849.issue12868@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I have a problem if I add --without-threads

Yeah, it's a recent regression: I opened the issue #12871. I don't think that it's specific to OpenBSD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:16:30 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 31 Aug 2011 18:16:30 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314814590.46.0.13187720175.issue12868@psf.upfronthosting.co.za>


Remi Pointel <python at xiri.fr> added the comment:

> Yeah, it's a recent regression: I opened the issue #12871. I don't think that it's specific to OpenBSD.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:20:46 2011
From: report at bugs.python.org (ledave123)
Date: Wed, 31 Aug 2011 18:20:46 +0000
Subject: [issue12636] IDLE ignores -*- coding -*- with -r option
In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za>
Message-ID: <1314814846.73.0.220167179469.issue12636@psf.upfronthosting.co.za>


ledave123 <ledave123 at yahoo.fr> added the comment:

Here is the patch:

diff -r e8da570d29a8 Lib/idlelib/PyShell.py
--- a/Lib/idlelib/PyShell.py    Wed Jul 27 21:28:23 2011 +0200
+++ b/Lib/idlelib/PyShell.py    Wed Aug 31 20:16:38 2011 +0200
@@ -582,7 +582,9 @@
     def execfile(self, filename, source=None):
         "Execute an existing file"
         if source is None:
-            source = open(filename, "r").read()
+            import tokenize
+            with tokenize.open(filename) as filein:
+                source = filein.read()
         try:
             code = compile(source, filename, "exec")
         except (OverflowError, SyntaxError):

Sorry for taking such a long time, I was on holidays.

----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12636>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:25:43 2011
From: report at bugs.python.org (Nir Aides)
Date: Wed, 31 Aug 2011 18:25:43 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1314815143.08.0.52611461825.issue6721@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

For the record, turns out there was a bit of misunderstanding. 

I used the term deprecate above to mean "warn users (through documentation) that they should not use (a feature)" and not in its Python-dev sense of "remove (a feature) after a period of warning".

I do not think the possibility to mix threading and multiprocessing together should be somehow forcibly disabled. 

Anyway, since my view does not seem to resonate with core developers I I'll give it a rest for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:34:32 2011
From: report at bugs.python.org (Jacek Pliszka)
Date: Wed, 31 Aug 2011 18:34:32 +0000
Subject: [issue12793] allow filters in os.walk
In-Reply-To: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>
Message-ID: <1314815672.68.0.903645604351.issue12793@psf.upfronthosting.co.za>


Jacek Pliszka <jacek.pliszka at gmail.com> added the comment:

Looks like the proper way to do it is described in the manual:
http://docs.python.org/dev/library/os.html#os.walk

for root, dirs, files in os.walk('python/Lib/email'):
    if 'CVS' in dirs:
        dirs.remove('CVS')  # don't visit CVS directories
    .....

I checked that it is covered by unit tests in /test_os.py so it is safe to use and bug can blo closed as invalid.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12793>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:37:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 18:37:50 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314815870.45.0.765955220578.issue12868@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23078/openbsd_sigaltstack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:45:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 31 Aug 2011 18:45:14 +0000
Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled
	without threads
In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za>
Message-ID: <1314816314.4.0.999716630218.issue12871@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

I haven't been able to reproduce this on Linux (2.6.38; Ubuntu 11.04).
Some searching around seems to suggest that OpenBSD doesn't provide
those functions (or didn't until recently). Modules/posixmodule.c and
configure.in seem to assume that these functions are available if
sched.h exists. Adding an explicit check for them should solve the
problem.

----------
nosy: +nadeem.vawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12871>
_______________________________________

From report at bugs.python.org  Wed Aug 31 20:48:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 18:48:50 +0000
Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled
	without threads
In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za>
Message-ID: <1314816530.45.0.895163027519.issue12871@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

There's no reason to disable sched_get_priority_(min|max) when Python is built without threads: those libraries control the scheduling policy, and should be available even without pthread.
However, it's really likely that pthread has its own implementation (especially since OpenBSD's threads are implemented in user-space), and it seems that OpenBSD sched_get_priority() is only defined for threads:
http://www.openbsd.org/cgi-bin/man.cgi?query=sched_get_priority_max&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
"""
This implementation does not support process scheduling.
"""

For example, the following snippet builds correctly on Linux:

"""
#include <sched.h>


int main(int argc, char *argv[])
{
    int (*fp)(int) = sched_get_priority_max;

    return 0;
}
"""

So this should be skipped only on OpenBSD, or we should add some checks to the configure script.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12871>
_______________________________________

From report at bugs.python.org  Wed Aug 31 21:50:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 31 Aug 2011 19:50:56 +0000
Subject: [issue12793] allow filters in os.walk
In-Reply-To: <1313841174.16.0.821458772727.issue12793@psf.upfronthosting.co.za>
Message-ID: <1314820256.14.0.815949998088.issue12793@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/issue12793>
_______________________________________

From report at bugs.python.org  Wed Aug 31 22:51:00 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 20:51:00 +0000
Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD
In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za>
Message-ID: <1314823860.91.0.723056181529.issue12868@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> It does not build completely, I have a problem if I add
> --without-threads:

Until this gets fixed, if you want to do a quick test, you could just remove the calls to sched_get_priority_(min|max):

"""
diff -r 0968acf0e6db Modules/posixmodule.c
--- a/Modules/posixmodule.c     Wed Aug 31 16:52:12 2011 +0200
+++ b/Modules/posixmodule.c     Wed Aug 31 22:51:13 2011 +0200
@@ -4562,7 +4562,6 @@
 
     if (!PyArg_ParseTuple(args, "i:sched_get_priority_max", &policy))
         return NULL;
-    max = sched_get_priority_max(policy);
     if (max < 0)
         return posix_error();
     return PyLong_FromLong(max);
@@ -4579,7 +4578,6 @@
 
     if (!PyArg_ParseTuple(args, "i:sched_get_priority_min", &policy))
         return NULL;
-    min = sched_get_priority_min(policy);
     if (min < 0)
         return posix_error();
     return PyLong_FromLong(min);
"""

That should allow you to rebuild with 'without-threads'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12868>
_______________________________________

From report at bugs.python.org  Wed Aug 31 23:02:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 21:02:05 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1314815143.08.0.52611461825.issue6721@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2-UXj3ks783PY5SnupDMy5cF_PRnxZzwpffNRQ6WBasQ@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> Anyway, since my view does not seem to resonate with core developers I I'll
> give it a rest for now.

Well, the problem is that many views have been expressed in this
thread, which doesn't help getting a clear picture of what's needed to
make progress on this issue.
AFAIC, I think the following seems reasonable:
1) add an atfork module which provides a generic and
pthread_atfork-like mechanism to setup handlers that must be called
after fork (right now several modules use their own ad-hoc mechanism)
2) for multiprocessing, call exec() after fork() (issue #8713)
3) for buffered file objects locks, use the approach similar to the
patch I posted (reinit locks in the child process right after fork())

Does that sound reasonable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Wed Aug 31 23:11:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 31 Aug 2011 21:11:16 +0000
Subject: [issue12472] Build failure on IRIX
In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za>
Message-ID: <1314825076.44.0.771280880463.issue12472@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

I'm closing, since IRIX header files seem terminally broken, and we can't do much about it.
Furthermore, I'm 99% sure IRIX isn't officially supported anymore.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12472>
_______________________________________

From report at bugs.python.org  Wed Aug 31 23:51:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 31 Aug 2011 21:51:24 +0000
Subject: [issue12872] --with-tsc crashes on ppc64
Message-ID: <1314827484.72.0.601008700485.issue12872@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

On 64-bit PPC builds configured --with-tsc, Python segfaults within the first function call in the bytecode interpreter.

Upon investigation this is due to this code in Python/ceval.c:
    32  typedef unsigned long long uint64;
    33  
    34  /* PowerPC support.
    35     "__ppc__" appears to be the preprocessor definition to detect on OS
X, whereas
    36     "__powerpc__" appears to be the correct one for Linux with GCC
    37  */
    38  #if defined(__ppc__) || defined (__powerpc__)
    39  
    40  #define READ_TIMESTAMP(var) ppc_getcounter(&var)
    41  
    42  static void
    43  ppc_getcounter(uint64 *v)
    44  {
    45      register unsigned long tbu, tb, tbu2;
    46  
    47    loop:
    48      asm volatile ("mftbu %0" : "=r" (tbu) );
    49      asm volatile ("mftb  %0" : "=r" (tb)  );
    50      asm volatile ("mftbu %0" : "=r" (tbu2));
    51      if (__builtin_expect(tbu != tbu2, 0)) goto loop;
    52  
    53      /* The slightly peculiar way of writing the next lines is
    54         compiled better by GCC than any other way I tried. */
    55      ((long*)(v))[0] = tbu;
    56      /*((long*)(v))[1] = tb; */ /* <==== this is the bug */
    57  }
    58  
    59  #elif defined(__i386__)

(gdb) p sizeof(long)
$44 = 8
(gdb) p sizeof(uint64)
$45 = 8

Looks like lines 55 and 56 are erroneously assuming that a long is 4 bytes on
this arch: line 56 above is trashing the next value beyond the timer value, which is on the machine's stack, corrupting local variables within PyEval_EvalFrameEx.

The code has been this way since ppc_getcounter was added, in:
  http://hg.python.org/cpython/rev/f455bbe7ea7e

I may have broken this in:
  http://hg.python.org/cpython/rev/419ca089d365/
which was for:
  http://bugs.python.org/issue10655
by (perhaps) generalizing support from ppc to (ppc and ppc64) (not sure about
this).

I'm attaching a patch which splits the ppc tsc support into 32-bit and 64-bit parts, and which also removes an aliasing violation on 32-bit ppc.

(I'm tracking this downstream in Fedora's bug tracker as https://bugzilla.redhat.com/show_bug.cgi?id=698726 )

----------
components: Interpreter Core
files: python-2.7.2-tsc-on-ppc.patch
keywords: patch
messages: 143281
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: --with-tsc crashes on ppc64
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23079/python-2.7.2-tsc-on-ppc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12872>
_______________________________________

From report at bugs.python.org  Wed Aug 31 23:53:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 31 Aug 2011 21:53:13 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1314827593.0.0.41695196017.issue12386@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I don?t see why.  All text is bytes, so we can do all I/O in bytes
> when writing resources and avoid special-casing.

I was only commenting on how the bug might have come about.

> A link to a specific changeset or file would be great.

https://bitbucket.org/vinay.sajip/pythonv/changeset/3e3a07a94f69#chg-Lib/packaging/command/install_distinfo.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12386>
_______________________________________

From report at bugs.python.org  Wed Aug 31 23:57:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 31 Aug 2011 21:57:21 +0000
Subject: [issue12873] 2to3 incorrectly handles multi-line imports from
	__future__
Message-ID: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ cat test1.py
from __future__ import (absolute_import, division,
    print_function, unicode_literals)

print(1, 2)
$ cat test2.py
from __future__ import (absolute_import, division, print_function, unicode_literals)

print(1, 2)
$ python2.7 -c 'import test1'
1 2
$ python2.7 -c 'import test2'
1 2
$ 2to3 test1.py test2.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 test1.py
--- test1.py    (original)
+++ test1.py    (refactored)
@@ -1,4 +1,4 @@
 from __future__ import (absolute_import, division,
     print_function, unicode_literals)
 
-print(1, 2)
+print((1, 2))
RefactoringTool: Files that need to be modified:
RefactoringTool: test1.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 143283
nosy: Arfrever, benjamin.peterson
priority: normal
severity: normal
status: open
title: 2to3 incorrectly handles multi-line imports from __future__
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12873>
_______________________________________