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: [New-bugs-announce] [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: [New-bugs-announce] [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 05:54:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 01 Aug 2011 03:54:54 +0000
Subject: [New-bugs-announce] [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 08:00:10 2011
From: report at bugs.python.org (rpointel)
Date: Mon, 01 Aug 2011 06:00:10 +0000
Subject: [New-bugs-announce] [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 14:22:36 2011
From: report at bugs.python.org (thp)
Date: Mon, 01 Aug 2011 12:22:36 +0000
Subject: [New-bugs-announce] [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:58:39 2011
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 01 Aug 2011 12:58:39 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:37:49 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 01 Aug 2011 13:37:49 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 08:46:51 2011
From: report at bugs.python.org (Matt Joiner)
Date: Tue, 02 Aug 2011 06:46:51 +0000
Subject: [New-bugs-announce] [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 10:16:09 2011
From: report at bugs.python.org (Sagiv Malihi)
Date: Tue, 02 Aug 2011 08:16:09 +0000
Subject: [New-bugs-announce] [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 13:41:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 11:41:56 +0000
Subject: [New-bugs-announce] [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 17:07:11 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 15:07:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 03:43:18 2011
From: report at bugs.python.org (Matt Joiner)
Date: Wed, 03 Aug 2011 01:43:18 +0000
Subject: [New-bugs-announce] [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 05:40:57 2011
From: report at bugs.python.org (py.user)
Date: Wed, 03 Aug 2011 03:40:57 +0000
Subject: [New-bugs-announce] [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 09:23:41 2011
From: report at bugs.python.org (BJ Dierkes)
Date: Wed, 03 Aug 2011 07:23:41 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 23:18:47 2011
From: report at bugs.python.org (John Simon)
Date: Wed, 03 Aug 2011 21:18:47 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:33:31 2011
From: report at bugs.python.org (Gary Levin)
Date: Thu, 04 Aug 2011 02:33:31 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 07:02:31 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Aug 2011 05:02:31 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 11:29:01 2011
From: report at bugs.python.org (Alexander Belchenko)
Date: Fri, 05 Aug 2011 09:29:01 +0000
Subject: [New-bugs-announce] [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:53:43 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 10:53:43 +0000
Subject: [New-bugs-announce] [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 15:39:40 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Fri, 05 Aug 2011 13:39:40 +0000
Subject: [New-bugs-announce] [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 18:11:34 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 05 Aug 2011 16:11:34 +0000
Subject: [New-bugs-announce] [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:12:15 2011
From: report at bugs.python.org (jimmi)
Date: Fri, 05 Aug 2011 16:12:15 +0000
Subject: [New-bugs-announce] [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 22:23:11 2011
From: report at bugs.python.org (Feth AREZKI)
Date: Fri, 05 Aug 2011 20:23:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:46:59 2011
From: report at bugs.python.org (deadshort)
Date: Sat, 06 Aug 2011 02:46:59 +0000
Subject: [New-bugs-announce] [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 08:42:48 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 06 Aug 2011 06:42:48 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 20:12:26 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 06 Aug 2011 18:12:26 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:33:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:33:01 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:21:46 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 08:21:46 +0000
Subject: [New-bugs-announce] [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 12:10:09 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:10:09 +0000
Subject: [New-bugs-announce] [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 15:08:23 2011
From: report at bugs.python.org (Toni Boni)
Date: Mon, 08 Aug 2011 13:08:23 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 18:53:00 2011
From: report at bugs.python.org (Tim Holme)
Date: Mon, 08 Aug 2011 16:53:00 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 13:54:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 11:54:12 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 16:41:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 14:41:44 +0000
Subject: [New-bugs-announce] [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 17:07:33 2011
From: report at bugs.python.org (Mike Garabedian)
Date: Tue, 09 Aug 2011 15:07:33 +0000
Subject: [New-bugs-announce] [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 19:25:41 2011
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGA?=)
Date: Tue, 09 Aug 2011 17:25:41 +0000
Subject: [New-bugs-announce] [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 22:16:30 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Tue, 09 Aug 2011 20:16:30 +0000
Subject: [New-bugs-announce] [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:24:55 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 20:24:55 +0000
Subject: [New-bugs-announce] [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  Wed Aug 10 12:09:10 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 10 Aug 2011 10:09:10 +0000
Subject: [New-bugs-announce] [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 15:53:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 10 Aug 2011 13:53:17 +0000
Subject: [New-bugs-announce] [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 17:23:11 2011
From: report at bugs.python.org (Matthew Hemke)
Date: Wed, 10 Aug 2011 15:23:11 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:47:55 2011
From: report at bugs.python.org (Cris Simpson)
Date: Thu, 11 Aug 2011 02:47:55 +0000
Subject: [New-bugs-announce] [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 11:18:55 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 11 Aug 2011 09:18:55 +0000
Subject: [New-bugs-announce] [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 20:30:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Aug 2011 18:30:30 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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:18:31 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:18:31 +0000
Subject: [New-bugs-announce] [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:49:35 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:49:35 +0000
Subject: [New-bugs-announce] [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:59:53 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 19:59:53 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 23:39:44 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 21:39:44 +0000
Subject: [New-bugs-announce] [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:37:34 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Thu, 11 Aug 2011 22:37:34 +0000
Subject: [New-bugs-announce] [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 02:25:42 2011
From: report at bugs.python.org (Michael Hall)
Date: Fri, 12 Aug 2011 00:25:42 +0000
Subject: [New-bugs-announce] [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 05:20:24 2011
From: report at bugs.python.org (Joe Hu)
Date: Fri, 12 Aug 2011 03:20:24 +0000
Subject: [New-bugs-announce] [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 13:33:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 12 Aug 2011 11:33:27 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 16:01:39 2011
From: report at bugs.python.org (Adal Chiriliuc)
Date: Fri, 12 Aug 2011 14:01:39 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 18:26:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 16:26:23 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 06:12:01 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Aug 2011 04:12:01 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  Sun Aug 14 06:40:41 2011
From: report at bugs.python.org (hy)
Date: Sun, 14 Aug 2011 04:40:41 +0000
Subject: [New-bugs-announce] [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 17:47:39 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 14 Aug 2011 15:47:39 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 12:06:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Aug 2011 10:06:24 +0000
Subject: [New-bugs-announce] [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 13:12:42 2011
From: report at bugs.python.org (Julian Taylor)
Date: Mon, 15 Aug 2011 11:12:42 +0000
Subject: [New-bugs-announce] [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 19:48:34 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 15 Aug 2011 17:48:34 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 08:26:44 2011
From: report at bugs.python.org (Chandra Sekhar Reddy)
Date: Tue, 16 Aug 2011 06:26:44 +0000
Subject: [New-bugs-announce] [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:52:55 2011
From: report at bugs.python.org (Ben Finney)
Date: Tue, 16 Aug 2011 06:52:55 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:52:04 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 07:52:04 +0000
Subject: [New-bugs-announce] [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 13:54:14 2011
From: report at bugs.python.org (Alexander)
Date: Tue, 16 Aug 2011 11:54:14 +0000
Subject: [New-bugs-announce] [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 15:49:19 2011
From: report at bugs.python.org (David Townshend)
Date: Tue, 16 Aug 2011 13:49:19 +0000
Subject: [New-bugs-announce] [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 18:41:41 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 16 Aug 2011 16:41:41 +0000
Subject: [New-bugs-announce] [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:09:06 2011
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 16 Aug 2011 17:09:06 +0000
Subject: [New-bugs-announce] [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:59:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 17:59:04 +0000
Subject: [New-bugs-announce] [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 22:21:57 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Aug 2011 20:21:57 +0000
Subject: [New-bugs-announce] [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:33:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Aug 2011 20:33:36 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 04:37:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:37:09 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 15:06:11 2011
From: report at bugs.python.org (=?utf-8?q?Rafa=C5=82_Dowgird?=)
Date: Wed, 17 Aug 2011 13:06:11 +0000
Subject: [New-bugs-announce] [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 16:39:45 2011
From: report at bugs.python.org (Marcelo)
Date: Wed, 17 Aug 2011 14:39:45 +0000
Subject: [New-bugs-announce] [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:59:47 2011
From: report at bugs.python.org (Vlada Peric)
Date: Wed, 17 Aug 2011 14:59:47 +0000
Subject: [New-bugs-announce] [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 18:15:03 2011
From: report at bugs.python.org (Miguel de Val Borro)
Date: Wed, 17 Aug 2011 16:15:03 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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  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: [New-bugs-announce] [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 10:00:55 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 08:00:55 +0000
Subject: [New-bugs-announce] [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:57:58 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Thu, 18 Aug 2011 08:57:58 +0000
Subject: [New-bugs-announce] [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 16:32:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:32:27 +0000
Subject: [New-bugs-announce] [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 17:23:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 15:23:16 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 19:14:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 17:14:40 +0000
Subject: [New-bugs-announce] [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 23:46:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 18 Aug 2011 21:46:28 +0000
Subject: [New-bugs-announce] [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 04:10:17 2011
From: report at bugs.python.org (Julian Berman)
Date: Fri, 19 Aug 2011 02:10:17 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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 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: [New-bugs-announce] [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 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: [New-bugs-announce] [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 18:31:02 2011
From: report at bugs.python.org (Idan Kamara)
Date: Fri, 19 Aug 2011 16:31:02 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 03:07:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 01:07:22 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: [New-bugs-announce] [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 08:37:56 2011
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Aug 2011 06:37:56 +0000
Subject: [New-bugs-announce] [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 11:50:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 09:50:36 +0000
Subject: [New-bugs-announce] [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 13:52:54 2011
From: report at bugs.python.org (Jacek Pliszka)
Date: Sat, 20 Aug 2011 11:52:54 +0000
Subject: [New-bugs-announce] [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 17:30:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 15:30:40 +0000
Subject: [New-bugs-announce] [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 18:23:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Aug 2011 16:23:15 +0000
Subject: [New-bugs-announce] [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 22:27:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 20:27:34 +0000
Subject: [New-bugs-announce] [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 23:00:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 21:00:03 +0000
Subject: [New-bugs-announce] [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:49:06 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 21:49:06 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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: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: [New-bugs-announce] [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:47:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Aug 2011 23:47:31 +0000
Subject: [New-bugs-announce] [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 02:46:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Aug 2011 00:46:30 +0000
Subject: [New-bugs-announce] [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 09:28:26 2011
From: report at bugs.python.org (Adam Simpkins)
Date: Sun, 21 Aug 2011 07:28:26 +0000
Subject: [New-bugs-announce] [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 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: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 04:59:01 2011
From: report at bugs.python.org (John O'Connor)
Date: Mon, 22 Aug 2011 02:59:01 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:26:52 2011
From: report at bugs.python.org (Michael Farrell)
Date: Mon, 22 Aug 2011 03:26:52 +0000
Subject: [New-bugs-announce] [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 07:23:54 2011
From: report at bugs.python.org (Joel)
Date: Mon, 22 Aug 2011 05:23:54 +0000
Subject: [New-bugs-announce] [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 08:07:54 2011
From: report at bugs.python.org (Anthony Briggs)
Date: Mon, 22 Aug 2011 06:07:54 +0000
Subject: [New-bugs-announce] [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:30:56 2011
From: report at bugs.python.org (Joel)
Date: Mon, 22 Aug 2011 06:30:56 +0000
Subject: [New-bugs-announce] [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:41 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 22 Aug 2011 06:41:41 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 10:25:07 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 08:25:07 +0000
Subject: [New-bugs-announce] [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:45:33 2011
From: report at bugs.python.org (Tennessee Leeuwenburg)
Date: Mon, 22 Aug 2011 08:45:33 +0000
Subject: [New-bugs-announce] [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 13:13:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Aug 2011 11:13:31 +0000
Subject: [New-bugs-announce] [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 15:45:43 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Aug 2011 13:45:43 +0000
Subject: [New-bugs-announce] [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 20:51:35 2011
From: report at bugs.python.org (Torsten Becker)
Date: Mon, 22 Aug 2011 18:51:35 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 08:58:08 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 06:58:08 +0000
Subject: [New-bugs-announce] [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:43:36 2011
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 23 Aug 2011 07:43:36 +0000
Subject: [New-bugs-announce] [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 10:05:20 2011
From: report at bugs.python.org (Roger Li)
Date: Tue, 23 Aug 2011 08:05:20 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:49:11 2011
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Aug 2011 08:49:11 +0000
Subject: [New-bugs-announce] [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:54:48 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 08:54:48 +0000
Subject: [New-bugs-announce] [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 13:30:57 2011
From: report at bugs.python.org (Remi Pointel)
Date: Tue, 23 Aug 2011 11:30:57 +0000
Subject: [New-bugs-announce] [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 19:46:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 17:46:57 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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 12:18:09 2011
From: report at bugs.python.org (trevor)
Date: Wed, 24 Aug 2011 10:18:09 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:18:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:18:14 +0000
Subject: [New-bugs-announce] [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 19:00:12 2011
From: report at bugs.python.org (Idan Kamara)
Date: Wed, 24 Aug 2011 17:00:12 +0000
Subject: [New-bugs-announce] [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 20:45:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Aug 2011 18:45:05 +0000
Subject: [New-bugs-announce] [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 21:11:34 2011
From: report at bugs.python.org (David Watson)
Date: Wed, 24 Aug 2011 19:11:34 +0000
Subject: [New-bugs-announce] [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 23:53:55 2011
From: report at bugs.python.org (Benjamin Gilbert)
Date: Wed, 24 Aug 2011 21:53:55 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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 04:50:37 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 25 Aug 2011 02:50:37 +0000
Subject: [New-bugs-announce] [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 07:21:49 2011
From: report at bugs.python.org (rmtew)
Date: Thu, 25 Aug 2011 05:21:49 +0000
Subject: [New-bugs-announce] [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 09:22:35 2011
From: report at bugs.python.org (Luca Fabbri)
Date: Thu, 25 Aug 2011 07:22:35 +0000
Subject: [New-bugs-announce] [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 16:17:14 2011
From: report at bugs.python.org (Sebastien Luttringer)
Date: Thu, 25 Aug 2011 14:17:14 +0000
Subject: [New-bugs-announce] [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 22:31:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Aug 2011 20:31:25 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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: [New-bugs-announce] [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 12:29:45 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Aug 2011 10:29:45 +0000
Subject: [New-bugs-announce] [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 15:53:27 2011
From: report at bugs.python.org (Cem YILDIZ)
Date: Fri, 26 Aug 2011 13:53:27 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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:59:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Aug 2011 12:59:53 +0000
Subject: [New-bugs-announce] [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  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: [New-bugs-announce] [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  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: [New-bugs-announce] [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:58:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 29 Aug 2011 09:58:43 +0000
Subject: [New-bugs-announce] [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 14:30:08 2011
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 29 Aug 2011 12:30:08 +0000
Subject: [New-bugs-announce] [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 19:08:20 2011
From: report at bugs.python.org (Russell Owen)
Date: Mon, 29 Aug 2011 17:08:20 +0000
Subject: [New-bugs-announce] [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 20:02:45 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 29 Aug 2011 18:02:45 +0000
Subject: [New-bugs-announce] [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 23:42:30 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 21:42:30 +0000
Subject: [New-bugs-announce] [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  Tue Aug 30 02:31:53 2011
From: report at bugs.python.org (Ferringb)
Date: Tue, 30 Aug 2011 00:31:53 +0000
Subject: [New-bugs-announce] [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 07:54:27 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 30 Aug 2011 05:54:27 +0000
Subject: [New-bugs-announce] [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 16:41:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 14:41:18 +0000
Subject: [New-bugs-announce] [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 19:04:40 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:04:40 +0000
Subject: [New-bugs-announce] [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: [New-bugs-announce] [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:15:55 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 30 Aug 2011 17:15:55 +0000
Subject: [New-bugs-announce] [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:53 2011
From: report at bugs.python.org (Daniel Fortunov)
Date: Tue, 30 Aug 2011 17:30:53 +0000
Subject: [New-bugs-announce] [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 20:50:58 2011
From: report at bugs.python.org (GPU Group)
Date: Tue, 30 Aug 2011 18:50:58 +0000
Subject: [New-bugs-announce] [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 23:59:21 2011
From: report at bugs.python.org (simohe)
Date: Tue, 30 Aug 2011 21:59:21 +0000
Subject: [New-bugs-announce] [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:35:13 2011
From: report at bugs.python.org (Andrey Men)
Date: Tue, 30 Aug 2011 22:35:13 +0000
Subject: [New-bugs-announce] [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:52 2011
From: report at bugs.python.org (=?utf-8?q?Peder_J=C3=B8rgensen?=)
Date: Tue, 30 Aug 2011 22:51:52 +0000
Subject: [New-bugs-announce] [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 06:29:23 2011
From: report at bugs.python.org (Jordan Meyer)
Date: Wed, 31 Aug 2011 04:29:23 +0000
Subject: [New-bugs-announce] [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 09:55:33 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 31 Aug 2011 07:55:33 +0000
Subject: [New-bugs-announce] [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 16:38:38 2011
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 31 Aug 2011 14:38:38 +0000
Subject: [New-bugs-announce] [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 19:29:34 2011
From: report at bugs.python.org (Matt Chaput)
Date: Wed, 31 Aug 2011 17:29:34 +0000
Subject: [New-bugs-announce] [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 20:03:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Aug 2011 18:03:42 +0000
Subject: [New-bugs-announce] [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 23:51:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 31 Aug 2011 21:51:24 +0000
Subject: [New-bugs-announce] [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:57:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 31 Aug 2011 21:57:21 +0000
Subject: [New-bugs-announce] [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>
_______________________________________