From report at bugs.python.org  Mon Nov  1 01:13:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Nov 2010 00:13:42 +0000
Subject: [New-bugs-announce] [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

* Dedocument assertSetEqual, assertDictEqual, assertListEqual, and assertTupleEqual.  These are all automatically dispatched from assertEqual.  The user need not call any of these directly.  These methods should not have been exposed in the docs.

* Add new names and dedocument old names for assertLess, assertLessEqual, assertGreater, assertGreaterEqual.   The new names are modeled after the gt, le, lt convention used elsewhere in the language.  This avoids to problems remembering the current spelling quirks (dropping the Than in LessEqual, pluralization, camel casing, being too long, etc).  New names will be assertLE, assertLT, assertGE, and assertGT.

* Add news names and dedocument assertRegexpMatches and assertNotRegexpMatches.  These names haves have multiple issues (they actually do a re.search not a re.match, they are long, the pluralization is inconsistent with the assertEqual convention, they don't agree with the names used in other unittest implementations such as PHPunit and Junit).  The new names will be assertRegexp and assertNotRegexp.

* Remove the assertItemsEqual method (which is new in 3.2).  Its semantics are not obvious from its name (i.e. duplicates matter, order does not matter, expects elements not items, has O(n**2) behavior after an impending bug fix, uses on equality for matching not hashing or ordering).  In most common cases, it is more explicit and flexible to use assertEqual after casting to a set, a list, or sorted list.  Also note that other unittest implementations such as PHPunit and JUnit do not have this method.  See http://mail.python.org/pipermail/python-dev/2010-October/105073.html 

* Recombine the package into a single file.  See http://mail.python.org/pipermail/python-dev/2010-October/105025.html and http://mail.python.org/pipermail/python-dev/2010-October/104887.html

* We need to review the camel cased spelling on two methods that are new in 3.2.  Should it be assertIsinstance or assertIsInstance?
 assert

----------
assignee: rhettinger
messages: 120100
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Clean-up Unittest API
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 04:55:33 2010
From: report at bugs.python.org (david)
Date: Mon, 01 Nov 2010 03:55:33 +0000
Subject: [New-bugs-announce] [issue10274] imaplib should provide a means to
	validate a remote	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

imaplib should provide a means to validate a remote server ssl certificate(s).

So currently imaplib allows you to do the following:

import imaplib
conn = imaplib.IMAP4_SSL("imap.gmail.com")

#the following should fail
conn = imaplib.IMAP4_SSL("74.125.39.109")
conn = imaplib.IMAP4_SSL("i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org",
443)
conn = imaplib.IMAP4_SSL("insert_self_signed_imap_server_here")
However, only the first call("imap.gmail.com") should *NOT* result in an error being raised (if the certificate is being checked :) ).

I wasn't able to find a way to get imaplib.IMAP4_SSL to take the certificate for the remote server without wanting a private cert (which wasn't / isn't desired ).

If an option is added / method added that takes in an optional parameter to validate the remote IMAP's ssl certificate has been signed by a trusted certificate authority this would be a good solution.

----------
components: None
messages: 120108
nosy: db
priority: normal
severity: normal
status: open
title: imaplib should provide a means to validate a remote server ssl certificate(s)
type: security
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 05:41:35 2010
From: report at bugs.python.org (py.user)
Date: Mon, 01 Nov 2010 04:41:35 +0000
Subject: [New-bugs-announce] [issue10275] how to know that a module is a
	module, a function is a function ?
In-Reply-To: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>
Message-ID: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>


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

>>> import os
>>> m = os
>>> type(m)
<class 'module'>
>>> isinstance(m, module)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'module' is not defined
>>> n = 1
>>> type(n)
<class 'int'>
>>> isinstance(1, int)
True
>>>

----------
components: Interpreter Core
messages: 120109
nosy: py.user
priority: normal
severity: normal
status: open
title: how to know that a module is a module, a function is a function ?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  1 10:46:05 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 01 Nov 2010 09:46:05 +0000
Subject: [New-bugs-announce] [issue10276] zlib crc32/adler32 buffer length
	truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

zlib.crc32() and zlib.adler32() in Modules/zlibmodule.c don't handle buffers of >=4GB correctly. The length of a Py_buffer is of type Py_ssize_t, while the C zlib functions take length as an unsigned integer. This means that on a 64-bit build, the buffer length gets silently truncated to 32 bits, which results in incorrect output for large inputs.

Attached is a patch that fixes this by computing the checksum incrementally, using small-enough chunks of the buffer.

A better fix might be to have Modules/zlib/crc32.c use 64-bit lengths. I tried this, but I couldn't get it to work. It seems that if the system already has zlib installed, Python will link against the existing version instead of compiling its own.

Testing this might be a bit tricky. Allocating a 4+GB regular buffer isn't practical. Using a memory-mapped file would work, but I'm not sure having a unit test create a multi-gigabyte file is a great thing to do.

----------
components: Library (Lib)
files: zlib-checksum-truncation.diff
keywords: patch
messages: 120114
nosy: nvawda
priority: normal
severity: normal
status: open
title: zlib crc32/adler32 buffer length truncation (64-bit)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19453/zlib-checksum-truncation.diff

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

From report at bugs.python.org  Mon Nov  1 12:05:41 2010
From: report at bugs.python.org (Brian Brazil)
Date: Mon, 01 Nov 2010 11:05:41 +0000
Subject: [New-bugs-announce] [issue10277] sax leaks a fd if source is a
	filename
In-Reply-To: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>
Message-ID: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

If saxutils.prepare_input_source is passed a filename or url, it'll end up leaking an fd via IncrementalParser.parse and ExpatParser.parse. This can be seen by enabling resource warnings and running test_sax.

This should be fixed.

----------
components: Library (Lib)
messages: 120118
nosy: bbrazil
priority: normal
severity: normal
status: open
title: sax leaks a fd if source is a filename
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov  1 16:10:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 15:10:10 +0000
Subject: [New-bugs-announce] [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

If measuring time across blocking calls, such as thread synchronization, one currently must time.time().  This is because time.clock() measures cpu seconds on unix.  On windows, however, time.clock() would be more appropriate because it measures wall-clock time.

To avoid having to put platform clauses everywhere, this patch adds time.wallclock().
The current implementation is a simple alias to time.clock on windows and time.time otherwise.  Future improvements may add a better implementation on those non-windows platforms that support it.

----------
components: Interpreter Core
files: wallclock.patch
keywords: patch
messages: 120130
nosy: krisvale
priority: normal
severity: normal
status: open
title: add time.wallclock() method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19455/wallclock.patch

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

From report at bugs.python.org  Mon Nov  1 17:34:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Nov 2010 16:34:05 +0000
Subject: [New-bugs-announce] [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

======================================================================
FAIL: test_garbage_at_shutdown (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python-dev\py3k\lib\test\test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use'
 not found in b'sys:1: ResourceWarning: gc: %Id uncollectable objects at shutdow
n; use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them'


%Id isn't being replaced with the number in the format string. I only briefly looked into it, not sure why it would be Windows x64 specific (this doesn't happen on Win 32-bit or any *nix buildbots).

----------
messages: 120137
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gc failure on Windows x64
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 20:53:15 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 19:53:15 +0000
Subject: [New-bugs-announce] [issue10280] nntp_version set to the most
	recent advertised version
In-Reply-To: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>
Message-ID: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

The NNTP version is currently defined as follows in the source code:

self.nntp_version = int(caps['VERSION'][0])

However, Section 3.3.2 of RFC 3977 mentions:

   VERSION
      This capability MUST be advertised by all servers and MUST be the
      first capability in the capability list; it indicates the
      version(s) of NNTP that the server supports.  There must be at
      least one argument; each argument is a decimal number and MUST NOT
      have a leading zero.  Version numbers are assigned only in RFCs
      that update or replace this specification; servers MUST NOT create
      their own version numbers.

There can be more than one version.
See the example in Section 5.2.3:

      [S] VERSION 2 3

I believe the best thing to do would be to take the max of the numbers, that is to say:

self.nntp_version = max(map(int, caps['VERSION']))

----------
components: Extension Modules
messages: 120156
nosy: jelie
priority: normal
severity: normal
status: open
title: nntp_version set to the most recent advertised version
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 20:58:24 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 19:58:24 +0000
Subject: [New-bugs-announce] [issue10281] Exception raised when an NNTP
	overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

Following the first example of the documentation:

import nntplib

s = nntplib.NNTP('news.trigofacile.com')
resp, count, first, last, name = s.group('fr.comp.lang.python')
print('Group', name, 'has', count, 'articles, range', first, 'to', last)
resp, overviews = s.over((last - 9, last))
for id, over in overviews:
    print(id, nntplib.decode_header(over['subject']))
s.quit()


An exception is raised:
"OVER/XOVER response doesn't include names of additional headers"


I believe the issue comes from the fact that the source code does not
handle the case described in Section 8.3.2 of RFC 3977:

   For all fields, the value is processed by first removing all CRLF
   pairs (that is, undoing any folding and removing the terminating
   CRLF) and then replacing each TAB with a single space.  If there is
   no such header in the article, no such metadata item, or no header or
   item stored in the database for that article, the corresponding field
   MUST be empty.

   Example of a successful retrieval of overview information for a range
   of articles:

      [C] GROUP misc.test
      [S] 211 1234 3000234 3002322 misc.test
      [C] OVER 3000234-3000240
      [S] 224 Overview information follows
      [S] 3000234|I am just a test article|"Demo User"
          <nobody at example.com>|6 Oct 1998 04:38:40 -0500|
          <45223423 at example.com>|<45454 at example.net>|1234|
          17|Xref: news.example.com misc.test:3000363
      [S] 3000235|Another test article|nobody at nowhere.to
          (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425 at to.to>||
          4818|37||Distribution: fi
      [S] 3000238|Re: I am just a test article|somebody at elsewhere.to|
          7 Oct 1998 11:38:40 +1200|<kfwer3v at elsewhere.to>|
          <45223423 at to.to>|9234|51
      [S] .

   Note the missing "References" and Xref headers in the second line,
   the missing trailing fields in the first and last lines, and that
   there are only results for those articles that still exist.






Also please note that nntplib should also work in case the database is not consistent.  Some news servers might be broken and do not follow the MUST NOT...

   The LIST OVERVIEW.FMT command SHOULD list all the fields for which
   the database is consistent at that moment.  It MAY omit such fields
   (for example, if it is not known whether the database is consistent
   or inconsistent).  It MUST NOT include fields for which the database
   is inconsistent or that are not stored in the database.  Therefore,
   if a header appears in the LIST OVERVIEW.FMT output but not in the
   OVER output for a given article, that header does not appear in the
   article (similarly for metadata items).

----------
components: Extension Modules
messages: 120158
nosy: jelie
priority: normal
severity: normal
status: open
title: Exception raised when an NNTP overview field is absent
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:16:07 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:16:07 +0000
Subject: [New-bugs-announce] [issue10282] IMPLEMENTATION token differently
	delt with in NNTP	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

I believe the case of "IMPLEMENTATION" should be treated differently.
It is not helpful at all to split the argument.  It is meant to be a
text string and ['INN', '2.6.0', '(20101101', 'prelease)'] does not
have much meaning...

Suggestion:

            if line.startswith("IMPLEMENTATION"):
                 name, *tokens = line.split(None, 1)
            else:
                 name, *tokens = line.split()

or something else, though I do not believe another keyword will begin with "IMPLEMENTATION"...

Besides, shouldn't it be checked that the line is not empty, before splitting it?

----------
components: Extension Modules
messages: 120159
nosy: jelie
priority: normal
severity: normal
status: open
title: IMPLEMENTATION token differently delt with in NNTP capability
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:21:04 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:21:04 +0000
Subject: [New-bugs-announce] [issue10283] New parameter for an NNTP
	newsgroup pattern in LIST	ACTIVE
In-Reply-To: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>
Message-ID: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

NNTP.list(*, file=None)

Couldn't a "grouppattern" argument be added?
LIST ACTIVE handles a newsgroup pattern (and it would then answer
less groups -- also useful for the test suite of nntplib)


Something like that:


--- nntplib.py.OLD      2010-11-01 19:04:10.000000000 +0100
+++ nntplib.py  2010-11-01 19:57:50.000000000 +0100
@@ -568,14 +568,18 @@
         cmd = 'NEWNEWS {0} {1} {2}'.format(group, date_str, time_str)
         return self._longcmdstring(cmd, file)

-    def list(self, *, file=None):
+    def list(self, *, group_pattern=None, file=None):
         """Process a LIST command. Argument:
         - file: Filename string or file object to store the result in
         Returns:
         - resp: server response if successful
         - list: list of (group, last, first, flag) (strings)
         """
-        resp, lines = self._longcmdstring('LIST', file)
+        if group_pattern is not None:
+            command = 'LIST ACTIVE ' + group_pattern
+        else:
+            command = 'LIST'
+        resp, lines = self._longcmdstring(command, file)
         return resp, self._grouplist(lines)

     def _getdescriptions(self, group_pattern, return_all):





Then, you could perhaps re-activate the LIST test in the test suite...

    # Disabled with gmane as it produces too much data
    test_list = None



In the documentation:

- .. method:: NNTP.list(*, file=None)
+ .. method:: NNTP.list(*, grouppattern=None, file=None)

and describe it the same way grouppattern is described
in the following command (LIST NEWSGROUPS).

----------
components: Extension Modules
messages: 120160
nosy: jelie
priority: normal
severity: normal
status: open
title: New parameter for an NNTP newsgroup pattern in LIST ACTIVE
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:22:40 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:22:40 +0000
Subject: [New-bugs-announce] [issue10284] Exception raised when decoding
	NNTP newsgroup	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

> +# - all commands are encoded as UTF-8 data (using the "surrogateescape"
> +#   error handler), except for raw message data (POST, IHAVE)
> +# - all responses are decoded as UTF-8 data (using the "surrogateescape"
> +#   error handler), except for raw message data (ARTICLE, HEAD, BODY)

It does not seem to work on my news server (news.trigofacile.com):

print(s.descriptions('*'))

Exception raised with an UnicodeEncodeError.  I do not know what is happening.
The same command works fine with Python 2.7 and 3.0.



Also, for AUTHINFO, be careful that nntplib should not send an UTF-8 string but a byte string.  (I have not tested.)
The username and the password are byte strings.

----------
components: Extension Modules
messages: 120161
nosy: jelie
priority: normal
severity: normal
status: open
title: Exception raised when decoding NNTP newsgroup descriptions
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:25:23 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:25:23 +0000
Subject: [New-bugs-announce] [issue10285] Other status field flags in
	documentation for NNTP LIST	command
In-Reply-To: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>
Message-ID: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

> +.. method:: NNTP.list(*, file=None)
> +
> +   Send a ``LIST`` command.  Return a pair ``(response, list)`` where *list* is a
> +   list of tuples representing all the groups available from this NNTP server.
> +   Each tuple has the form ``(group, last, first, flag)``, where
> +   *group* is a group name, *last* and *first* are the last and first article
> +   numbers, and *flag* is ``'y'`` if posting is allowed, ``'n'`` if not,
> +   and ``'m'`` if the newsgroup is moderated.  (Note the ordering: *last*, *first*.)

There are other values:  'x', 'j', and '=' followed by the name of a newsgroup (alias).

I believe the best would be to use what INN mentions in its documentation!  (Or otherwise, RFC 3977 and RFC 6048.)

    http://www.eyrie.org/~eagle/software/inn/docs/active.html


It would then give:

-------------------------------------------------------------------------------------
... and *flag* usually takes one of these values:

    y         Local postings and articles from peers are allowed.
    m         The group is moderated and all postings must be approved.
    n         No local postings are allowed, only articles from peers.
    j         Articles from peers are filed in the junk group instead.
    x         No local postings, and articles from peers are ignored.
    =foo.bar  Articles are filed in the group foo.bar instead.

If *flag* has another value, then the status of the newsgroup should be considered
to be unknown.
-------------------------------------------------------------------------------------


Can a bullet list be used in the documentation, to properly indent the flag values?

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 120162
nosy: docs at python, jelie
priority: normal
severity: normal
status: open
title: Other status field flags in documentation for NNTP LIST command
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:28:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Nov 2010 20:28:55 +0000
Subject: [New-bugs-announce] [issue10286] URLOpener => URLopener x2 in
	fix_urllib.py
In-Reply-To: <1288643335.41.0.951306369167.issue10286@psf.upfronthosting.co.za>
Message-ID: <1288643335.41.0.951306369167.issue10286@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Lib/lib2to3/fixes/fix_urllib.py, near the top, has
'''
MAPPING = {'urllib':  [
                ('urllib.request',
                    ['URLOpener', 'FancyURLOpener', 'urlretrieve',
'''
'Opener' should by 'opener' in BOTH cases.

Non-fix of URLopener reported on python-list by Chris McDonald.

----------
components: 2to3 (2.x to 3.0 conversion tool)
keywords: easy
messages: 120165
nosy: benjamin.peterson, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: URLOpener => URLopener x2 in fix_urllib.py
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  1 22:56:32 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 21:56:32 +0000
Subject: [New-bugs-announce] [issue10287] NNTP authentication should check
	capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

RFC 4643:

   The server MAY list the AUTHINFO capability with no arguments, which
   indicates that it complies with this specification and does not
   permit any authentication commands in its current state.  In this
   case, the client MUST NOT attempt to utilize any AUTHINFO commands,
   even if it contains logic that might otherwise cause it to do so
   (e.g., for backward compatibility with servers that are not compliant
   with this specification).

Yet, nntplib attempts to authenticate.


self.capabilities() should be sent at startup.

If "READER" is advertised, no need to send a "MODE READER" command at all...

If "MODE-READER" is advertised, then "MODE READER" (if wanted) can be sent.
Then, self.capabilities() should be sent again.  Capabilities changed!

Then authentication if "AUTHINFO USER" is advertised with NNTP version >=2.  If "AUTHINFO" without "USER", no authentication at all.

And after authentication, self.capabilities() should be sent again.



Please note that the readermode_afterauth variable I see in the source code should normally not be used by a client...  RFC 4643 mentions:

   o  the MODE READER command MUST NOT be used in the
      same session following successful authentication.

----------
components: Library (Lib)
messages: 120183
nosy: jelie
priority: normal
severity: normal
status: open
title: NNTP authentication should check capabilities
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 23:41:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 01 Nov 2010 22:41:46 +0000
Subject: [New-bugs-announce] [issue10288] Remove
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Issue 5793 rationalized all usage of C "character" handling to use "Py_"-prefixed locale-unaware macros, at the "char" level.

In particular, this comment was added in two places to Include/bytes_methods.h in r72044:
http://svn.python.org/view/python/branches/py3k/Include/bytes_methods.h?view=diff&r1=72043&r2=72044

  /* These are left in for backward compatibility and will be removed
  in 2.8/3.2 */

Given that 3.2 is coming soon, is it time to remove these?  (also, the reference to "2.8" caught my eye)

Attached is a patch to py3k which removes them, and fixes up various users that were still in the source tree.

Am I right in thinking that the undef and redefinition of the various lower-case macros from <ctype.h> was already intended to be removed? (given that this messes about with a standard C library)

----------
files: py3k-remove-old-char-compat-macros.patch
keywords: patch
messages: 120185
nosy: dmalcolm, eric.smith, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Remove
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19459/py3k-remove-old-char-compat-macros.patch

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

From report at bugs.python.org  Tue Nov  2 00:54:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 23:54:56 +0000
Subject: [New-bugs-announce] [issue10289] Document magic methods called by
	built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

At the top of Doc/library/functions.rst, which documents built-in functions like abs, getattr or hash, a comment reads ?document all delegations to __special__ methods?.

Some functions are already good: enumerate for instance does link to the definition of iterator and hints about the __next__ method, format points to __format__, etc.  They can serve as example for how to add links (in plain text and in the global index).

----------
assignee: docs at python
components: Documentation
messages: 120189
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Document magic methods called by built-in functions
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  2 01:51:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Nov 2010 00:51:39 +0000
Subject: [New-bugs-announce] [issue10290] Fix resource warnings in distutils
In-Reply-To: <1288659099.71.0.79415360493.issue10290@psf.upfronthosting.co.za>
Message-ID: <1288659099.71.0.79415360493.issue10290@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

The attached patch cleans up the numerous ResourceWarning messages that distutils test runs generate. The changes basically just close all open files - some in the test suite, some in the library code.
No context managers were used since distutils appears in PEP 291 as requiring 2.3 support.

----------
assignee: tarek
components: Distutils, Library (Lib), Tests
messages: 120196
nosy: brian.curtin, eric.araujo, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Fix resource warnings in distutils
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 03:03:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Nov 2010 02:03:32 +0000
Subject: [New-bugs-announce] [issue10291] Clean-up turtledemo in-package
	documentation
In-Reply-To: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za>
Message-ID: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Since after closing of issue #10199, docstrings in demo scripts are accessible to pydoc, it is important to bring them up to date.  For example, turtledemo.wikipedia docstring contains a reference to nonexistent wikipedia1 and calls itself tdemo_wikipedia3.py.

In addition, the turtledemo package contains three text files: Lib/turtledemo/about_turtle.txt, Lib/turtledemo/about_turtledemo.txt, and Lib/turtledemo/demohelp.txt.  The contents of these files should be moved to appropriate (doc)strings inside appropriate .py files.

----------
assignee: belopolsky
components: Demos and Tools, Documentation
keywords: easy
messages: 120200
nosy: belopolsky, eric.araujo, georg.brandl, glingl, gregorlingl, gvanrossum, ned.deily, r.david.murray, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Clean-up turtledemo in-package documentation
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 06:58:11 2010
From: report at bugs.python.org (JP St. Pierre)
Date: Tue, 02 Nov 2010 05:58:11 +0000
Subject: [New-bugs-announce] [issue10292] tarinfo should use relative
	symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>


New submission from JP St. Pierre <jstpierre at mecheye.net>:

With all the tools I've used, the target of a symlink appears to be relative to the actual symlink entry. Fix this.

----------
components: Library (Lib)
messages: 120208
nosy: magcius
priority: normal
severity: normal
status: open
title: tarinfo should use relative symlinks
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  2 10:26:36 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Nov 2010 09:26:36 +0000
Subject: [New-bugs-announce] [issue10293] PyMemoryView object has obsolete
	members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The PyMemoryObject has a "base" member which appears to be obsolete.  Furthermore, the function do_release() attempt to perform some obsolete-looking woodo with base if it happens to be a tuple.  Looks dangerous.

----------
components: Interpreter Core
messages: 120211
nosy: krisvale
priority: normal
severity: normal
status: open
title: PyMemoryView object has obsolete members
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 17:09:48 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 02 Nov 2010 16:09:48 +0000
Subject: [New-bugs-announce] [issue10294] Lib/test/test_unicode_file.py
	contains dead code
In-Reply-To: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>
Message-ID: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Lib/test/test_unicode_file.py contains dead code:

    def _test_equivalent(self, filename1, filename2):
        remove_if_exists(filename1)
        self.assertTrue(not os.path.exists(filename2))
        f = file(filename1, "w")
        f.close()
        try:
            self._do_equivalent(filename1, filename2)
        finally:
            os.unlink(filename1)

Note how this refers to the now-gone "file()". The method is never used in the test code. Similarly, the "_do_equivalent()" method that it calls appears otherwise unused.

----------
components: Tests
messages: 120236
nosy: scoder
priority: normal
severity: normal
status: open
title: Lib/test/test_unicode_file.py contains dead code
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov  3 07:01:55 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 06:01:55 +0000
Subject: [New-bugs-announce] [issue10295] _socket.pyd uses winsock2,
	select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

These two socket modules link to a different winsock api, thus pulling two potentially incompatible dlls in to the process.  There is no guarantee that they interact.

I'll see if there is a simple patch for select module

----------
components: IO
messages: 120308
nosy: krisvale
priority: normal
severity: normal
status: open
title: _socket.pyd uses winsock2, select.pyd uses winsock 1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 09:20:33 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 08:20:33 +0000
Subject: [New-bugs-announce] [issue10296] ctypes catches BreakPoint error on
	windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

import ctypes
ctypes.windll.kernel32.DebugBreak()
This used to be a handy way to attach a debugger to a running program, by way of JIT debugging.  Now ctypes catches and handles this exception so a debugger is never invoked.  Bummer.

----------
messages: 120312
nosy: krisvale
priority: normal
severity: normal
status: open
title: ctypes catches BreakPoint error on windows 32
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 11:30:21 2010
From: report at bugs.python.org (hafiza jameel)
Date: Wed, 03 Nov 2010 10:30:21 +0000
Subject: [New-bugs-announce] [issue10297] decimal module documentation is
	misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>


New submission from hafiza jameel <fizabreeze at gmail.com>:

the documentation does not show the import statement of decimal module in the introduction:
http://docs.python.org/library/decimal.html

import should have been done like this:
from decimal import *

----------
assignee: docs at python
components: Documentation
messages: 120315
nosy: docs at python, hafiza.jameel
priority: normal
severity: normal
status: open
title: decimal module documentation is misguiding
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 15:00:39 2010
From: report at bugs.python.org (rep)
Date: Wed, 03 Nov 2010 14:00:39 +0000
Subject: [New-bugs-announce] [issue10298] zipfile: incorrect comment size
	will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>


New submission from rep <ms at mwcollect.org>:

Opening (and thus extracting) zip files with appended junk data is not possible with the way the current zipfile implementation checks validity. Basically the problem comes down to the comment size in the end-of-central-directory record being different from the size of the data following that record.

Unix unzip and similar utilities handle that case by looking at the eocd-record and taking that as the correct value. Zip files with data appended to them will be extracted just fine with these tools.

In python's zipfile the _EndRecData function will return None if the comment size does not match the record's value.

The patch modifies this behaviour and takes only the portion of trailing data that the record specifies and due to that it does not raise BadZipfile exceptions if there's any junk data appended to a zip file.

----------
components: Library (Lib)
files: zipfile_recover_commentsize.patch
keywords: patch
messages: 120326
nosy: rep
priority: normal
severity: normal
status: open
title: zipfile: incorrect comment size will prevent extracting
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19477/zipfile_recover_commentsize.patch

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

From report at bugs.python.org  Wed Nov  3 15:24:58 2010
From: report at bugs.python.org (nestor)
Date: Wed, 03 Nov 2010 14:24:58 +0000
Subject: [New-bugs-announce] [issue10299] Add index with links section for
	built-in functions
In-Reply-To: <1288794298.88.0.884491179751.issue10299@psf.upfronthosting.co.za>
Message-ID: <1288794298.88.0.884491179751.issue10299@psf.upfronthosting.co.za>


New submission from nestor <nestornissen at gmail.com>:

The built-in function page (http://docs.python.org/dev/py3k/library/functions.html) is pretty long. Each function has an anchor but unlike the built-in types section there is no quick way to get an overview or jump to a specific function (like open or print) short of scrolling through 22 pages. It would be nice to have an index of all built-in functions linked to the specific entry on the built-in functions page. This could be either somehow added to the index page (http://docs.python.org/dev/py3k/library/index.html) or to the top of the built-in functions page itself. For efficient use of real-estate multiple function names could be on one single line alphabetically sorted and separated by spaces.

----------
assignee: docs at python
components: Documentation
messages: 120327
nosy: docs at python, georg.brandl, nestor
priority: normal
severity: normal
status: open
title: Add index with links section for built-in functions
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov  3 16:54:19 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Nov 2010 15:54:19 +0000
Subject: [New-bugs-announce] [issue10300] Documentation of three PyDict_*
	functions
In-Reply-To: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>
Message-ID: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

The documentation of the functions PyDict_Items, PyDict_Keys and PyDict_Values is incorrect: They do return PyListObject, but in Python 3.x this is not the same as dict.items() etc.

----------
assignee: docs at python
components: Documentation
messages: 120328
nosy: docs at python, hagen
priority: normal
severity: normal
status: open
title: Documentation of three PyDict_* functions
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov  3 22:28:58 2010
From: report at bugs.python.org (t.steinruecken)
Date: Wed, 03 Nov 2010 21:28:58 +0000
Subject: [New-bugs-announce] [issue10301] Zipfile cannot be used in "with"
	Statement
In-Reply-To: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>
Message-ID: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>


New submission from t.steinruecken <t.steinruecken at service4every1.de>:

Using a ZipFile as a "with"-context dosnt work
(Im using the standard Ubuntu version of Python3.1)

Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from zipfile import ZipFile
>>> with ZipFile("test.zip","w") as z:
...     z.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ZipFile' object has no attribute '__exit__'
>>>

----------
components: Extension Modules
messages: 120346
nosy: t.steinruecken
priority: normal
severity: normal
status: open
title: Zipfile cannot be used in "with" Statement
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Nov  3 23:44:17 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Wed, 03 Nov 2010 22:44:17 +0000
Subject: [New-bugs-announce] [issue10302] Add class-functions to hash many
	small objects with	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>


New submission from Lukas Lueg <lukas.lueg at gmail.com>:

The objects provided by hashlib mainly serve the purpose of computing hashes over strings of arbitrary size. The user gets a new object (e.g. hashlib.sha1()), calls .update() with chunks of data and then finally uses .digest() or .hexdigest() to get the hash. For convenience reasons these steps can also be done in almost one step (e.g. hashlib.sha1('foobar').hexdigest()).
While the above approach basically covers all use-cases for hash-functions, when computing hashes of many small strings it is yet inefficient (e.g. due to interpreter-overhead) and leaves out the possibility for performance improvements.

There are many cases where we need the hashes of numerous (small) objects, most or all of which being available in memory at the same time.

I therefor propose to extend the classes provided by hashlib with an additional function that takes an iterable object, computes the hash over the string representation of each member and returns the result. Due to the aim of this interface, the function is a member of the class (not the instance) and has therefor no state bound to an instance. Memory requirements are to be anticipated and met by the programmer.

For example:

foo = ['my_database_key1', 'my_database_key2']
hashlib.sha1.compute(foo) 
>> ('\x00\x00', '\xff\xff')


I consider this interface to hashlib particular useful, as we can take advantage of vector-based implementations that compute multiple hashes in one pass (e.g. through SSE2). GCC has a vector-extension that provides a *somewhat* standard way to write code that can get compiled to SSE2 or similar machine code. Examples of vector-based implementations of SHA1 and MD5 can be found at https://code.google.com/p/pyrit/issues/detail?id=207


Contigency plan: We compile to code iterating over OpenSSL's EVP-functions if compiler is other than GCC or SSE2 is not available. The same approach can be used to cover hashlib-objects for which we don't have an optimized implementation.

----------
components: Library (Lib)
messages: 120351
nosy: ebfe
priority: normal
severity: normal
status: open
title: Add class-functions to hash many small objects with hashlib
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  4 01:21:21 2010
From: report at bugs.python.org (Malte Helmert)
Date: Thu, 04 Nov 2010 00:21:21 +0000
Subject: [New-bugs-announce] [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>


New submission from Malte Helmert <helmert at informatik.uni-freiburg.de>:

Section "3.1.2. Strings" says "*Once again*, the print() function produces the more readable output.", but as far as I can see (or grep), this is the first time that this aspect of print() is mentioned.

----------
assignee: docs at python
components: Documentation
messages: 120362
nosy: docs at python, maltehelmert
priority: normal
severity: normal
status: open
title: small inconsistency in tutorial
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 01:28:23 2010
From: report at bugs.python.org (Malte Helmert)
Date: Thu, 04 Nov 2010 00:28:23 +0000
Subject: [New-bugs-announce] [issue10304] error in tutorial triple-string
	example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>


New submission from Malte Helmert <helmert at informatik.uni-freiburg.de>:

>From Section 3.1.2 of the tutorial:

  print("""
  Usage: thingy [OPTIONS]
       -h                        Display this usage message
       -H hostname               Hostname to connect to
  """)

  produces the following output:

  _____________________________________________________________
  Usage: thingy [OPTIONS]
       -h                        Display this usage message
       -H hostname               Hostname to connect to
  _____________________________________________________________


That doesn't quite match the behaviour: there should be an extra blank line prepended to the output.

----------
assignee: docs at python
components: Documentation
messages: 120364
nosy: docs at python, maltehelmert
priority: normal
severity: normal
status: open
title: error in tutorial triple-string example
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 02:03:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Nov 2010 01:03:36 +0000
Subject: [New-bugs-announce] [issue10305] Cleanup up ResourceWarnings in
	multiprocessing
In-Reply-To: <1288832616.21.0.291852483251.issue10305@psf.upfronthosting.co.za>
Message-ID: <1288832616.21.0.291852483251.issue10305@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

As shown in a debug run of test_multiprocessing, at least two places in managers.py apparently leave open sockets. Lines 786 and 805 are the culprits, both util log lines.

----------
components: Library (Lib)
messages: 120367
nosy: asksol, brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Cleanup up ResourceWarnings in multiprocessing
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 04:49:56 2010
From: report at bugs.python.org (Julian)
Date: Thu, 04 Nov 2010 03:49:56 +0000
Subject: [New-bugs-announce] [issue10306] Weakref callback exceptions should
	be turned into	warnings.
In-Reply-To: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>
Message-ID: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>


New submission from Julian <python_org at somethinkodd.com>:

If a weakref callback raises an exception, weakref writes out some text (to stderr, I think) and ignores it.

I think it would be more appropriate if weakref emitted that text using the Python warning module, to allow it to be better controlled.

Consider this code with two foolish mistakes in it:
---------
import warnings
import weakref

warnings.simplefilter('ignore') # Whoops, ignoring warnings is foolish.

def callback(condemned_object):
    raise Exception("Failure") # Whoops, raising an exception in a callback is foolish.

class RandomObject(object):
    pass

strong_ref = RandomObject()
wr = weakref.proxy(strong_ref, callback)
print "Removing the only strong reference"
strong_ref = None
# No guarantee that the garbage collector will trigger
# in practice, in CPython, it does.
print "Shutting down now."

---------
When I run this I get:
Removing the only strong reference
Exception Exception: Exception('Failure',) in <function callback at 0x0280A1B0> ignored
Shutting down now.

The exception text is output even though I don't want it to be. To help me debug, I want for the exception text to be manageable (not by ignoring it, like in the example above, but using the other warnings module features.)

----------
components: Library (Lib)
messages: 120375
nosy: oddthinking
priority: normal
severity: normal
status: open
title: Weakref callback exceptions should be turned into warnings.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  4 04:50:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 04 Nov 2010 03:50:22 +0000
Subject: [New-bugs-announce] [issue10307] compile error in readline.c
In-Reply-To: <1288842622.31.0.254816051601.issue10307@psf.upfronthosting.co.za>
Message-ID: <1288842622.31.0.254816051601.issue10307@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

/py3k/Modules/readline.c: In function flex_complete:
/py3k/Modules/readline.c:877: error: on_completion  undeclared (first use in this function)

----------
assignee: orsenthil
messages: 120376
nosy: orsenthil
priority: normal
severity: normal
status: open
title: compile error in readline.c
type: compile error

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

From report at bugs.python.org  Thu Nov  4 12:27:43 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:27:43 +0000
Subject: [New-bugs-announce] [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Patches for getpath.c in Python 2.7 and 3.2a3:

2.7 chunk#2: copy_absolute() would use uninitialized data if getcwd()
failed.  The fix is equivalent to what 3.2a3 does.

3.2a3 chunk#2: search_for_exec_prefix() did 'unsigned value >= 0' on the
PyUnicode_AsWideChar() result.  (The fix just renames n to k of signed
type, and moves the variables.  An outer uninitialized 'size_t n' is in
scope, so renaming the inner n to k leaves 'n=fread()' still a size_t.)

Chunk #1, both versions: Fix an unlikely 'n+k' wraparound bug while I'm
at it.  The code has just checked that MAXPATHLEN-n will not wrap.

----------
files: getpath.diff
keywords: patch
messages: 120390
nosy: hfuru
priority: normal
severity: normal
status: open
title: Modules/getpath.c bugs
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19486/getpath.diff

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

From report at bugs.python.org  Thu Nov  4 12:43:47 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:43:47 +0000
Subject: [New-bugs-announce] [issue10309] dlmalloc.c needs _GNU_SOURCE for
	mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

dlmalloc uses mremap() which is undeclared on Linux, needs _GNU_SOURCE.
This can break at least on hosts where void* = 64 bits and int (default
return type) 32 bits, since some bits in the return type are lost.

A minimal patch is:

--- Modules/_ctypes/libffi/src/dlmalloc.c
+++ Modules/_ctypes/libffi/src/dlmalloc.c
@@ -459,2 +459,4 @@
 #define MMAP_CLEARS 0 /* WINCE and some others apparently don't clear */
+#elif !defined _GNU_SOURCE
+#define _GNU_SOURCE 1           /* mremap() in Linux sys/mman.h */
 #endif  /* WIN32 */

However the (char*)CALL_MREMAP() cast looks like a broken fix for this,
it suppresses a warning instead of fixing it.  Maybe you should remove
the cast and instead assign CALL_MREMAP() to a void*, to catch any
similar trouble in the future.

----------
components: Extension Modules
messages: 120391
nosy: hfuru
priority: normal
severity: normal
status: open
title: dlmalloc.c needs _GNU_SOURCE for mremap()
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 12:51:20 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:51:20 +0000
Subject: [New-bugs-announce] [issue10310] signed:1 bitfields rarely make
	sense
In-Reply-To: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>
Message-ID: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

In Python 2.7 and 3.2a3, Modules/_io/textio.c uses signed:1 bitfields.

They have value -1 or 0 in two's complement, but are not used thus here:
gcc complains of <bitfield> = 1 overflow.  If the point was that they
are assigned signed values, well, unsigned:1 is promoted to signed int.

I also fix a strange (int) cast doing (truncate flag to int) & 1.
My guess is someone shut up a compiler warning about the above,
by cleaning up in the wrong place.  I kept a cast in case that's
not it, and some compiler would get noisy anyway.

There are possibly-signed 1-bit fields Modules/_ctypes/_ctypes_test.c:
struct BITS too, but I don't know what that code is for.  It does not
specify signedness of the bitfields, which (as with char) makes it the
compiler's choice.  That's usually a bad idea, but maybe that code is
for exploring the compiler?

----------
components: IO
files: signed-1-bitfield.diff
keywords: patch
messages: 120392
nosy: hfuru
priority: normal
severity: normal
status: open
title: signed:1 bitfields rarely make sense
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19487/signed-1-bitfield.diff

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

From report at bugs.python.org  Thu Nov  4 13:18:18 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 12:18:18 +0000
Subject: [New-bugs-announce] [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Signal handlers that can change errno, must restore it.
I enclose a patch for <2.7, 3.2a3>/Modules/signalmodule.c
which also rearranges the code to make this a bit easier.

The patch does   if (errno != save_errno) errno = save_errno;
instead of just  errno = save_errno;
in case it's less thread-safe to write than to read errno,
which would not surprise me but may be pointless paranoia.

I don't know what needs to be done on non-Unix systems,
like Windows' WSAError stuff.

----------
components: Interpreter Core
files: signalmodule-errno.diff
keywords: patch
messages: 120395
nosy: hfuru
priority: normal
severity: normal
status: open
title: Signal handlers must preserve errno
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19488/signalmodule-errno.diff

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

From report at bugs.python.org  Thu Nov  4 13:49:02 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 12:49:02 +0000
Subject: [New-bugs-announce] [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Parser/intrcheck.c:intcatcher() can do FILE* operations, which can
deadlock if the interrupt happens while a FILE* operation on the same
FILE holds a mutex for the FILE.  I've seen this happen elsewhere.

It'd rather be a pity to remove Py_Exit(), so I suggest
switch(interrupted++) gets a case 3 or 4: which does _exit(1),
and 'interrupted = 0;' is moved there from case 2.

Also 'interrupted' should be volatile sig_atomic_t, and
the function should save/restore errno as in Issue 10311.

BTW, you could use strlen(message) instead of sizeof(message)-1.

----------
components: Interpreter Core
files: intrcheck.diff
keywords: patch
messages: 120399
nosy: hfuru
priority: normal
severity: normal
status: open
title: intcatcher() can deadlock
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19491/intrcheck.diff

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

From report at bugs.python.org  Thu Nov  4 15:03:17 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 14:03:17 +0000
Subject: [New-bugs-announce] [issue10313] Reassure user: test_os
	BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

A test giving a strange warning can make a poor user nervous.  Here's
a minimal patch to calm his nerves.  It would be better to only give
the message if python -b (not -bb) is active, but I do not know how.

diff -prU2 Lib/test/test_os.py Lib/test/test_os.py
--- Lib/test/test_os.py
+++ Lib/test/test_os.py
@@ -443,4 +443,7 @@ class EnvironTests(mapping_tests.BasicTe
         test_env = {'PATH': os.pathsep.join(test_path)}
 
+        if os.supports_bytes_environ:
+            print("This test may give some 'BytesWarning's.", file=sys.stderr)
+
         saved_environ = os.environ
         try:

----------
components: Tests
messages: 120407
nosy: hfuru
priority: normal
severity: normal
status: open
title: Reassure user: test_os BytesWarning is OK
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 17:31:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 16:31:38 +0000
Subject: [New-bugs-announce] [issue10314] Improve JSON encoding with
	sort_keys=True
In-Reply-To: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>
Message-ID: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>


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

This patch makes sorting of keys when encoding a dict into JSON faster by not calling pure Python code.

----------
components: Library (Lib)
files: jsonsort.patch
keywords: patch
messages: 120418
nosy: pitrou
priority: normal
severity: normal
status: open
title: Improve JSON encoding with sort_keys=True
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19496/jsonsort.patch

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

From report at bugs.python.org  Thu Nov  4 21:14:26 2010
From: report at bugs.python.org (Henning Hraban Ramm)
Date: Thu, 04 Nov 2010 20:14:26 +0000
Subject: [New-bugs-announce] [issue10315] smtplib.SMTP_SSL new in 2.6
In-Reply-To: <1288901666.81.0.218057119797.issue10315@psf.upfronthosting.co.za>
Message-ID: <1288901666.81.0.218057119797.issue10315@psf.upfronthosting.co.za>


New submission from Henning Hraban Ramm <hraban at fiee.net>:

The docs tell us that smtplib.SMTP_SSL was only changed in 2.6, but it is new (i.e. it didn't exist in 2.5.x).

----------
assignee: docs at python
components: Documentation
messages: 120432
nosy: docs at python, hraban
priority: normal
severity: normal
status: open
title: smtplib.SMTP_SSL new in 2.6
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov  4 21:56:11 2010
From: report at bugs.python.org (Peter Hall)
Date: Thu, 04 Nov 2010 20:56:11 +0000
Subject: [New-bugs-announce] [issue10316] tkFileDialog.askopenfilenames
	scrambling multiple file	selection
In-Reply-To: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>
Message-ID: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>


New submission from Peter Hall <Peter.F.Hall at nasa.gov>:

I am running the following :

Linux Centos version 2.6.18
Python version 2.5
tk version 8.5
tcl version 8.5


I have a Python GUI program (importing Tkinter and tkFileDialog)
which prompts the user to select a (one to many) list of file names. 
The code is :

fileList = tkFileDialog.askopenfilenames(initialdir=self.startfiledir,
                                         title="Select Files for Processing",
                                         filetypes=self.ftypes, multiple=1)

where "startfiledir" and "ftypes" are defined elsewhere.
When this code is run a file selection box pops up
listing the chosen directory. Selecting just one file works fine.

To select multiple files the user highlights a selection
of the displayed files by dragging the cursor over them 
with "SHIFT left-mouse-button" pressed. 
It also lists ALL the selected files in the "File names:" selection field
at the bottom of the selection box. These are separated by spaces.
Clicking "Open" results in the selection box program trying to treat
the entire list as a single file name.
IE. It looks for a single file called "/home/mydir/file1 file2 file3 file4".
Since there is no such file an error pop-up box appears with a 
"File ... does not exist." message.

It appears that the file name list is not being parsed into indivdual file names.
I have tried combinations with "askopenfilename" instead of "askopenfilenames"
and including/omitting "multiple=1". 
I have also tried "multiple=bool(1)" and "multiple=xxx"
where "xxx=1" and "xxx=bool(1)".
None of these change the behaviour.

Is there a fault with my code ?
Is this a bug in "tkFileDialog.askopenfilenames" ?
Is there a workaround ?

Suggestions are welcome.

----------
components: Tkinter
messages: 120438
nosy: pfhall
priority: normal
severity: normal
status: open
title: tkFileDialog.askopenfilenames scrambling multiple file selection
versions: Python 2.5

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

From report at bugs.python.org  Fri Nov  5 03:40:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 02:40:56 +0000
Subject: [New-bugs-announce] [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>
Message-ID: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

In r84640, Raymond added TurtleShell to the cmd module documentation as an example of a simple interpreter that can be written using that module.  I propose adding this code to turtle.py and make it runnable as python -m turtle.

----------
components: Library (Lib)
keywords: easy
messages: 120466
nosy: belopolsky, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add TurtleShell to turtle
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  5 04:10:10 2010
From: report at bugs.python.org (Allan McRae)
Date: Fri, 05 Nov 2010 03:10:10 +0000
Subject: [New-bugs-announce] [issue10318] "make altinstall" installs many
	files with incorrect	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>


New submission from Allan McRae <allan at archlinux.org>:

The following files are incorrectly installed with a "#!/usr/bin/env python" shebang when using "make altinstall":

usr/lib/python2.7/base64.py
usr/lib/python2.7/bsddb/dbshelve.py
usr/lib/python2.7/bsddb/test/test_dbtables.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/Cookie.py
usr/lib/python2.7/cProfile.py
usr/lib/python2.7/difflib.py
usr/lib/python2.7/distutils/tests/test_build_scripts.py
usr/lib/python2.7/distutils/tests/test_install_scripts.py
usr/lib/python2.7/distutils/unixccompiler.py
usr/lib/python2.7/encodings/rot_13.py
usr/lib/python2.7/idlelib/PyShell.py
usr/lib/python2.7/keyword.py
usr/lib/python2.7/lib2to3/pgen2/token.py
usr/lib/python2.7/lib2to3/tests/data/different_encoding.py
usr/lib/python2.7/lib2to3/tests/pytree_idempotency.py
usr/lib/python2.7/mailbox.py
usr/lib/python2.7/mimify.py
usr/lib/python2.7/pdb.py
usr/lib/python2.7/platform.py
usr/lib/python2.7/profile.py
usr/lib/python2.7/pydoc.py
usr/lib/python2.7/quopri.py
usr/lib/python2.7/smtpd.py
usr/lib/python2.7/smtplib.py
usr/lib/python2.7/symbol.py
usr/lib/python2.7/tabnanny.py
usr/lib/python2.7/tarfile.py
usr/lib/python2.7/test/curses_tests.py
usr/lib/python2.7/test/pystone.py
usr/lib/python2.7/test/regrtest.py
usr/lib/python2.7/test/re_tests.py
usr/lib/python2.7/test/test_al.py
usr/lib/python2.7/test/test_anydbm.py
usr/lib/python2.7/test/test_array.py
usr/lib/python2.7/test/test_binhex.py
usr/lib/python2.7/test/test_bsddb.py
usr/lib/python2.7/test/test_bz2.py
usr/lib/python2.7/test/test_cd.py
usr/lib/python2.7/test/test_cl.py
usr/lib/python2.7/test/test_cmd.py
usr/lib/python2.7/test/test_codecencodings_cn.py
usr/lib/python2.7/test/test_codecencodings_hk.py
usr/lib/python2.7/test/test_codecencodings_jp.py
usr/lib/python2.7/test/test_codecencodings_kr.py
usr/lib/python2.7/test/test_codecencodings_tw.py
usr/lib/python2.7/test/test_codecmaps_cn.py
usr/lib/python2.7/test/test_codecmaps_hk.py
usr/lib/python2.7/test/test_codecmaps_jp.py
usr/lib/python2.7/test/test_codecmaps_kr.py
usr/lib/python2.7/test/test_codecmaps_tw.py
usr/lib/python2.7/test/test_dl.py
usr/lib/python2.7/test/test_dumbdbm.py
usr/lib/python2.7/test/test_eof.py
usr/lib/python2.7/test/test_errno.py
usr/lib/python2.7/test/test___future__.py
usr/lib/python2.7/test/test_gl.py
usr/lib/python2.7/test/test_gzip.py
usr/lib/python2.7/test/test_imageop.py
usr/lib/python2.7/test/test_imgfile.py
usr/lib/python2.7/test/test_logging.py
usr/lib/python2.7/test/test_marshal.py
usr/lib/python2.7/test/test_multibytecodec.py
usr/lib/python2.7/test/test_multibytecodec_support.py
usr/lib/python2.7/test/test_multiprocessing.py
usr/lib/python2.7/test/test_popen2.py
usr/lib/python2.7/test/test_popen.py
usr/lib/python2.7/test/test_random.py
usr/lib/python2.7/test/test_sets.py
usr/lib/python2.7/test/test_smtpnet.py
usr/lib/python2.7/test/test_socket.py
usr/lib/python2.7/test/test_tcl.py
usr/lib/python2.7/test/test_urllib2_localnet.py
usr/lib/python2.7/test/test_urllib2net.py
usr/lib/python2.7/test/test_urllibnet.py
usr/lib/python2.7/test/test_urlparse.py
usr/lib/python2.7/test/test_userstring.py
usr/lib/python2.7/test/test_whichdb.py
usr/lib/python2.7/test/test_with.py
usr/lib/python2.7/timeit.py
usr/lib/python2.7/token.py
usr/lib/python2.7/trace.py
usr/lib/python2.7/UserString.py
usr/lib/python2.7/uu.py
usr/lib/python2.7/webbrowser.py
usr/lib/python2.7/whichdb.py

These should point to /usr/bin/python2.7 instead.

----------
components: Build
messages: 120468
nosy: allan
priority: normal
severity: normal
status: open
title: "make altinstall" installs many files with incorrect shebangs
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  5 06:38:39 2010
From: report at bugs.python.org (jrodman2)
Date: Fri, 05 Nov 2010 05:38:39 +0000
Subject: [New-bugs-announce] [issue10319] SocketServer.TCPServer truncates
	responses on close (in	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>


New submission from jrodman2 <jrodman at pythontracker.spamportal.net>:

Behavior exists in at least Python 2.5 through 3.1.

The issue regards the socketserver's handling of the tcp sockets it works with.  On object reaping, the sockets are properly closed (in some versions explicitly, in others implicitly).  However, closing a socket with unread data will in some operating systems prevent sent data from being sent.  Notably this occurs on Linux and Windows (I tested on Debian testing x86_64 and Windows Vista x86).

Extensive tcpdump sessions and a lot of head scratching finally clarified the issue.  The OS would send an RST packet after just the first bit of data handed over to the socket implementation, in typical cases meaning hte first line of text python is writing would be sent to the client, but no more, causing invalid HTTP replies.

Here is a change to force the socket to be drained on close.  It is of no matter that more data may arrive on the socket post-drain, because the socket implementation in the operating system should be happy to send off what was already queued by the python program at this point.

Testing bears this out, across many platforms here.

Here is one way to accomplish this in python 2.x, in 3.x the equivalent file is socketserver.py, but has the same issue.  It lacks the explicit request.close() call, bgut this seems a matter of aesthetics.

Note that the use of select.select() is documented by Linux to be unsafe for this purpose in some circumstances, and may be on other platforms as well.

I sort of would rather have sockets have a socket.drain() function which is known to be safe and correct for this type of socket programming issue.  If that would be more appropriate, please suggest.

select(2)
       Under  Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent
       read blocks.  This could for example happen when data has arrived but upon examination has wrong checksum  and  is
       discarded.   There may be other circumstances in which a file descriptor is spuriously reported as ready.  Thus it
       may be safer to use O_NONBLOCK on sockets that should not block.

--- SocketServer.py.orig	2010-11-04 21:36:23.000000000 -0700
+++ SocketServer.py	2010-11-04 21:38:19.000000000 -0700
@@ -445,6 +445,13 @@
 
     def close_request(self, request):
         """Called to clean up an individual request."""
+        # drain socket
+        request.setblocking(0)
+        try:
+            while True:
+                request.recv(4096)
+        except socket.error, e:
+            pass
         request.close()

----------
messages: 120469
nosy: jrodman2
priority: normal
severity: normal
status: open
title: SocketServer.TCPServer truncates responses on close (in some situations)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Nov  5 09:38:09 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 08:38:09 +0000
Subject: [New-bugs-announce] [issue10320] printf %qd is nonstandard
In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>
Message-ID: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Modules/_ctypes/callproc.c:PyCArg_repr() uses sprintf(%qd, long long),
which is a GNU (and more?) extension.  ISO C99 says %lld.

Instead, use "%" PY_FORMAT_LONG_LONG "d" from pyconfig.h/pyport.h.
Kills off #ifdef MS_WIN32 too.  If Python must support C libraries
that handle %qd but not %lld, configure.in seems the right place.

Index: ./Modules/_ctypes/callproc.c
@@ -468,8 +468,3 @@ PyCArg_repr(PyCArgObject *self)
     case 'Q':
-        sprintf(buffer,
-#ifdef MS_WIN32
-            "<cparam '%c' (%I64d)>",
-#else
-            "<cparam '%c' (%qd)>",
-#endif
+        sprintf(buffer, "<cparam '%c' (%" PY_FORMAT_LONG_LONG "d)>",
             self->tag, self->value.q);

pyport.h tests (defined(MS_WIN64) || defined(MS_WINDOWS)) instead of
#ifdef MS_WIN32 for when to use %I64d. I assume that's more up to date.

----------
assignee: theller
components: ctypes
messages: 120473
nosy: hfuru, theller
priority: normal
severity: normal
status: open
title: printf %qd is nonstandard
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 10:07:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:07:41 +0000
Subject: [New-bugs-announce] [issue10321] Add support for Message objects
	and binary data to	smtplib.sendmail
In-Reply-To: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
Message-ID: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>


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

The attached patch adds support to smtplib.SMTP.sendmail for the 'msg' argument to be, in addition to the currently accepted ASCII-only string, either a bytes string or a Message object.  It also adds support for byte strings to smtplib.SMPT.data.

Binary support is straightforward: if a byte string is passed, it is subject to leading '.' quoting but otherwise transmitted as is (that is, no \r\n transformation is done, unlike the string case).

For Message object support, the Message is serialized via BytesGenerator, meaning that a message parsed from a bytes source can be successfully re-transmitted via smtplib.  In addition to_addrs and from_addr can be set to None, in which case the addresses are obtained from the appropriate Message object headers (and, for safety, any Bcc header is deleted).

Although this patch is complete with docs, I'm not convinced this is the correct API.

First is the question of whether or not Message object support should be added.  It is in the patch because I started the work with the idea that serializing a Message via BytesGenerator was the "right way" to get binary data into smtplib, but as the implementation fell out I in fact ended up adding support for arbitrary binary data to sendmail (and data).  So in fact the Message object handling is not required in smtplib.

The feature is, however, clearly useful.  Perhaps, however, it should live in email as one or more helper methods instead.  I prefer having it in smtplib, but would like the opinions of others.

The second question is whether or not either functionality should be added to the existing sendmail method, or whether new methods should be created instead.  The alternative API might be:

    send_bytes(from_addr, to_addrs, msg, mail_options, rcpt_options)
    send_message(msg, mail_options, rcpt_options, from_addr=None, to_addrs=None)

Having completed the patch I'm neutral on this API refactoring, and again welcome other opinions.  'send_bytes' doesn't really seem like the right name, since it implies sending arbitrary bytes when in fact what is happening is a complete message transaction.  'send_bytesmail'?  Ugly :(

(See also issue 8050 and issue 4403.)

Note that I'd like to get some variation of this in (that at a minimum at least supports passing binary data to sendmail) before beta1, since it is the logical compliment to the new bytes support in the email package.

----------
assignee: r.david.murray
components: Library (Lib)
files: sendmail_message.patch
keywords: patch
messages: 120475
nosy: Allison.Vollmann, barry, ccgus, exarkun, giampaolo.rodola, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for Message objects and binary data to smtplib.sendmail
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19502/sendmail_message.patch

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

From report at bugs.python.org  Fri Nov  5 11:06:35 2010
From: report at bugs.python.org (=?utf-8?q?R=C3=BCgheimer?=)
Date: Fri, 05 Nov 2010 10:06:35 +0000
Subject: [New-bugs-announce] [issue10322] sys.argv and quoted arguments on
	command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>


New submission from R?gheimer <frueghei at pasteur.fr>:

Words in quoted command line arguments containing whitespace are split into separate entries of the argument vector sys.argv. This implemetation (quote removal + word splitting) removes information required to read string arguments passed via the command line.

The expected behaviour would be to unquote the argument, but not to conduct word splitting within the quoted text.

----
Test program output:

> ./argtest arg1 arg2 "this should be a single argument"
  
  ['./argtest', 'arg1', 'arg2', 'this', 'should', 'be', 'a', 'single', 'argument']
----

(observed with Python 3.1.2 (r312:79147, Oct 28 2010, 14:12:33)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2

----------
components: None
files: argtest
messages: 120480
nosy: fcr
priority: normal
severity: normal
status: open
title: sys.argv and quoted arguments on command line
type: behavior
versions: Python 2.5, Python 3.1
Added file: http://bugs.python.org/file19503/argtest

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

From report at bugs.python.org  Fri Nov  5 11:13:39 2010
From: report at bugs.python.org (Shashank)
Date: Fri, 05 Nov 2010 10:13:39 +0000
Subject: [New-bugs-announce] [issue10323] Final state of underlying sequence
	in islice
In-Reply-To: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>
Message-ID: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>


New submission from Shashank <shashank.sunny.singh at gmail.com>:

-- Converting the discussion here http://mail.python.org/pipermail/python-list/2010-November/1259601.html to a bug report (+nosy for everyone that responded, quoting the initial message for context)

Are there any promises made with regard to final state of the underlying sequence that islice slices?
for example consider this

>>> from itertools import *
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
51

Now, the doc [1] says "If stop is None, then iteration continues until the iterator is exhausted, if at all; otherwise, it stops at the specified position".
It clearly is not stopping at stop (3).

Further, the doc gives an example of how this is *equivalent* to a generator defined in the same section. It turns out, these two are not exactly the
same if the side-effect of the code is considered on the underlying sequence.

Redefining islice using the generator function defined in the doc gives different (and from one pov, expected) result
>>> def islice(iterable, *args):
...     # islice('ABCDEFG', 2) --> A B
...
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
2

While "fixing" this should be rather easy in terms of the change in code required it might break any code depending
on this seemingly incorrect behavior

----------
components: Interpreter Core
messages: 120482
nosy: ned.deily, rhettinger, shashank, terry.reedy
priority: normal
severity: normal
status: open
title: Final state of underlying sequence in islice
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 13:31:22 2010
From: report at bugs.python.org (Nicolas Kaiser)
Date: Fri, 05 Nov 2010 12:31:22 +0000
Subject: [New-bugs-announce] [issue10324] Modules/binascii.c: simplify
	expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>


New submission from Nicolas Kaiser <nikai at nikai.net>:

Hi there!

I noticed two expressions that can be simplified like:
 (a || (!a && b)) => (a || b)

Best regards,
Nicolas Kaiser
---
--- a/Modules/binascii.c	2010-11-05 13:21:22.075303326 +0100
+++ b/Modules/binascii.c	2010-11-05 13:24:16.986174756 +0100
@@ -1337,8 +1337,7 @@ binascii_b2a_qp (PyObject *self, PyObjec
             ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) ||
             ((data[in] < 33) &&
              (data[in] != '\r') && (data[in] != '\n') &&
-             (quotetabs ||
-            (!quotetabs && ((data[in] != '\t') && (data[in] != ' '))))))
+             (quotetabs || ((data[in] != '\t') && (data[in] != ' ')))))
         {
             if ((linelen + 3) >= MAXLINESIZE) {
                 linelen = 0;
@@ -1410,8 +1409,7 @@ binascii_b2a_qp (PyObject *self, PyObjec
             ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) ||
             ((data[in] < 33) &&
              (data[in] != '\r') && (data[in] != '\n') &&
-             (quotetabs ||
-            (!quotetabs && ((data[in] != '\t') && (data[in] != ' '))))))
+             (quotetabs || ((data[in] != '\t') && (data[in] != ' ')))))
         {
             if ((linelen + 3 )>= MAXLINESIZE) {
                 odata[out++] = '=';

----------
components: Extension Modules
messages: 120490
nosy: nikai
priority: normal
severity: normal
status: open
title: Modules/binascii.c: simplify expressions
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov  5 14:56:12 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 13:56:12 +0000
Subject: [New-bugs-announce] [issue10325] PY_LLONG_MAX & co - preprocessor
	constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Include/pyport.h invites potential compile errors with the definitions
  #define PY_LLONG_MIN LLONG_MIN
  #define PY_LLONG_MAX LLONG_MAX
  #define PY_ULLONG_MAX ULLONG_MAX
which can fall back to gcc variants or to
  #else
  /* Otherwise, rely on two's complement. */
  #define PY_ULLONG_MAX (~0ULL)
  #define PY_LLONG_MAX  ((long long)(PY_ULLONG_MAX>>1))
  #define PY_LLONG_MIN (-PY_LLONG_MAX-1)

Code developed with the former #definitions might use them in '#if's,
and then break when it meets a host where the fallbacks are used.

It would be safer if either all the macros and pyconfig variants used
casts, or all used predefined constants - from configure if needed.

The signed variants would break because '#if's do not accept casts.

PY_ULLONG_MAX is more insidious: If it meets a host which supports
a type bigger than unsigned long long, then preprocessor arithmetic
will happen in that type. ~0ULL in #if statements is then actually
the same as ~ULLL or whatever it would be spelled.  This one
definitely needs a cast to protect from the surprise that
preprocessor value != value outside preprocessor.

You get the same effect with ~0U vs ~0UL on a 64-bit compiler,
and ~0U vs ~0ULL on a C99 compiler:
#if (~0U) == (~0ULL)
# error "oops"
#endif

Incidentally, the "two's complement" comment is wrong.
It also relies on unsigned long long being widest type with no
padding bits, and -LLONG_MAX-1 not being a trap representation.
~0ULL is not two's complement since it is unsigned, it works
because it has the same result as -1ULL which is defined to
have the max value.
The PY_LLONG_MIN definitions rely on two's complement. If
anyone cared, one could avoid that with
#define PY_LLONG_MIN (-PY_LLONG_MAX-(/*two's complement*/(-1LL & 3)==3))


Anyway.  If they use casts, fix PY_TIMEOUT_MAX in 3.2a3 pythread.h:
#define PY_MIN(x, y) ((x) < (y) ? (x) : (y))
#define PY_TIMEOUT_MAXTMP instead of PY_TIMEOUT_MAX, and then
#ifndef NT_THREADS
#define PY_TIMEOUT_MAX PY_TIMEOUT_MAXTMP
#else
#define PY_TIMEOUT_MAX PY_MIN(Py_LL(0xFFFFFFFF)*1000, PY_TIMEOUT_MAXTMP)
#endif

----------
components: Interpreter Core
messages: 120492
nosy: hfuru
priority: normal
severity: normal
status: open
title: PY_LLONG_MAX & co - preprocessor constants or not?
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 15:17:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Nov 2010 14:17:29 +0000
Subject: [New-bugs-announce] [issue10326] Can't pickle unittest.TestCase
	instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 2.7 a change was introduced to TestCase which involves storing a dictionary of method objects on TestCase instances. This makes them unpickleable.

unittest2 stores strings (method names) instead of method objects (a fix to make TestCase instances copyable under earlier versions of Python). The same fix could be applied to unittest.

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 120496
nosy: michael.foord
priority: low
severity: normal
stage: needs patch
status: open
title: Can't pickle unittest.TestCase instances
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 15:31:53 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 05 Nov 2010 14:31:53 +0000
Subject: [New-bugs-announce] [issue10327] Abnormal SSL timeouts when using
	socket timeouts - once	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

On freebsd 8, using python 2.6.6, I've run into the bug already widely dealt with in these reports :
http://bugs.python.org/issue1380952
http://bugs.python.org/issue1153016

When using socket timeouts (eg. with socket.setdefaulttimeout()), whatever the timeout I use (eg. 10 seconds), I begin having random "SSLError: The read operation timed out" exceptions in my http calls, via urlopen or 3rd party libraries.

Here is an example of traceback ending:

...
  File "/usr/local/lib/python2.6/site-packages/ZSI-2.0-py2.6.egg/ZSI/client.py", line 349, in ReceiveRaw
    response = self.h.getresponse()
  File "/usr/local/lib/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/local/lib/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/local/lib/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/local/lib/python2.6/socket.py", line 427, in readline
    data = recv(1)
  File "/usr/local/lib/python2.6/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/usr/local/lib/python2.6/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out

I've checked the py2.6.6 sources, the patches described in previous reports are still applied (eg. SSL_pending() checks etc.), I have no idea of how so long socket timeouts might interfere with ssl operations...

----------
components: IO
messages: 120498
nosy: arekm, georg.brandl, maltehelmert, pakal, pristine777, tarek-ziade, twouters
priority: normal
severity: normal
status: open
title: Abnormal SSL timeouts when using socket timeouts - once again
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Nov  5 15:33:48 2010
From: report at bugs.python.org (Alexander Schmolck)
Date: Fri, 05 Nov 2010 14:33:48 +0000
Subject: [New-bugs-announce] [issue10328] re.sub[n] doesn't seem to handle
	/Z replacements	correctly in all cases
In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>
Message-ID: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>


New submission from Alexander Schmolck <a.schmolck+bug at gmail.com>:

In certain cases a zero-width /Z match that should be replaced isn't.

An example might help:

 re.compile('(?m)(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)').subn(lambda m:next('<'+k+'>' for k,v in m.groupdict().items() if v is not None), 'foobar ')

this gives

 ('foobar<trailing_ws>', 1)

I would have expected

('foobar<trailing_ws><no_final_newline>', 2)

Contrast this with the following behavior:

 [m.span() for m in re.compile('(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)', re.M).finditer('foobar ')]

gives
 
 [(6, 7), (7, 7)]

The matches are clearly not overlapping and the re module docs for sub say "Return the string obtained by replacing the leftmost non-overlapping occurrences of pattern in string by the replacement repl.", so I would have expected two replacements.


This seems to be what perl is doing:

 echo -n 'foobar ' | perl -pe 's/(?m)(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)/<$&>/g'                    

gives
 foobar< ><>%

----------
components: Regular Expressions
messages: 120499
nosy: Alexander.Schmolck
priority: normal
severity: normal
status: open
title: re.sub[n] doesn't seem to handle /Z replacements correctly in all cases
type: behavior
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Nov  5 16:01:38 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 05 Nov 2010 15:01:38 +0000
Subject: [New-bugs-announce] [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

It seems that on Python 3 (i.e. the py3k branch) trace.py can not handle source that includes Unicode characters. Running the test suite with code coverage info via

   ./python Lib/test/regrtest.py -T -N -uurlfetch,largefile,network,decimal

sometimes fails with the following exception:

Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1500, in <module>
    main()
  File "Lib/test/regrtest.py", line 696, in main
    r.write_results(show_missing=True, summary=True, coverdir=coverdir)
  File "/home/coverage/python/Lib/trace.py", line 319, in write_results
    lnotab, count)
  File "/home/coverage/python/Lib/trace.py", line 369, in write_results_file
    outfile.write(line.expandtabs(8))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in
position 30: ordinal not in range(128)

The script that produces code coverage info on http://coverage.livinglogic.de/ uses this feature to generate code coverage info.

Applying the attached patch (i.e. specifying an explicit encoding when opening the output file) fixes the problem.

----------
files: trace.diff
keywords: patch
messages: 120506
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: trace.py and unicode in Python 3
Added file: http://bugs.python.org/file19505/trace.diff

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

From report at bugs.python.org  Fri Nov  5 21:21:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 20:21:19 +0000
Subject: [New-bugs-announce] [issue10330] trace module doesn't work without
	threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>


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

The trace module doesn't work when threading is disabled ("./configure --without-threads"). The following patch fixes this:

diff -r 345827dcf409 Lib/trace.py
--- a/Lib/trace.py      Fri Nov 05 20:58:28 2010 +0100
+++ b/Lib/trace.py      Fri Nov 05 21:20:09 2010 +0100
@@ -53,7 +53,10 @@ import linecache
 import os
 import re
 import sys
-import threading
+try:
+    import threading
+except ImportError:
+    import dummy_threading as threading
 import time
 import token
 import tokenize

----------
assignee: belopolsky
components: Library (Lib)
messages: 120529
nosy: belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: trace module doesn't work without threads
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 22:30:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 21:30:26 +0000
Subject: [New-bugs-announce] [issue10331] test_gdb failure when warnings
	printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>


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

There is this kind of failures on Barry's new buildbot. It looks like warning messages should be ignored when checking gdb output:


======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 390, in test_NULL_ob_type
    'set v->ob_type=0')
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 361, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 150, in get_gdb_repr
    import_site=import_site)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 132, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: '\nwarning: not using untrusted file "/home/barry/.gdbinit"\n' != ''
- 
- warning: not using untrusted file "/home/barry/.gdbinit"


See http://www.python.org/dev/buildbot/builders/PPC%20Ubuntu%203.x/builds/0/steps/test/logs/stdio

----------
assignee: dmalcolm
components: Tests
messages: 120537
nosy: barry, dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb failure when warnings printed out
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 23:22:32 2010
From: report at bugs.python.org (James Hutchison)
Date: Fri, 05 Nov 2010 22:22:32 +0000
Subject: [New-bugs-announce] [issue10332] Multiprocessing maxtasksperchild
	results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

v.3.2a3

If the maxtasksperchild argument is used, the program will just hang after whatever that value is rather than working as expected. Tested in Windows XP 32-bit

test code:

import multiprocessing

def f(x):
    return 0;

if __name__ == '__main__':
    pool = multiprocessing.Pool(processes=2,maxtasksperchild=1);
    results = list();
    for i in range(10):
        results.append(pool.apply_async(f, (i)));
    pool.close();
    pool.join();
    for r in results:
        print(r);
    print("Done");

----------
components: Library (Lib)
messages: 120547
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Multiprocessing maxtasksperchild results in hang
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov  6 00:05:41 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Nov 2010 23:05:41 +0000
Subject: [New-bugs-announce] [issue10333] Remove ancient backwards
	compatibility GC API
In-Reply-To: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>
Message-ID: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

I think it should be safe to remove some backwards compatibility cruft.  This was introduced during the 2.3 development cycle.

----------
files: gc_cruft.txt
messages: 120554
nosy: nascheme
priority: low
severity: normal
status: open
title: Remove ancient backwards compatibility GC API
Added file: http://bugs.python.org/file19510/gc_cruft.txt

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

From report at bugs.python.org  Sat Nov  6 07:28:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Nov 2010 06:28:02 +0000
Subject: [New-bugs-announce] [issue10334] Add new reST directive for links
	to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In a few cases where the pure python source code is a helpful adjunct to the documentation, I've added some links using the "seealso" directive:

  .. seealso::
  
     Latest version of the `ast module Python source code
     <http://svn.python.org/view/python/branches/release27-maint/Lib/ast.py?view=markup>`_


It would be great if a new directive could be introduced for this purpose.  Something like:

.. sourcecode Lib/ast.py


With a directive, we could easily point the root directory to different releases or to a local source directory for local doc build.

----------
assignee: georg.brandl
components: Documentation
messages: 120587
nosy: georg.brandl, rhettinger
priority: low
severity: normal
status: open
title: Add new reST directive for links to source code
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov  6 11:49:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 10:49:39 +0000
Subject: [New-bugs-announce] [issue10335] tokenize.open_python(): open a
	Python file with the	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In Python3, the following pattern becomes common:

        with open(fullname, 'rb') as fp:
            coding, line = tokenize.detect_encoding(fp.readline)
        with open(fullname, 'r', encoding=coding) as fp:
            ...

It opens the file is opened twice, whereas it is unnecessary: it's possible to reuse the raw buffer to create a text file. And I don't like the detect_encoding() API: pass the readline function is not intuitive.

I propose to create tokenize.open_python() function with a very simple API: just one argument, the filename. This function calls detect_encoding() and only open the file once.

Attached python adds the function with an unit test and a patch on the documentation. It patchs also functions currently using detect_encoding().

open_python() only supports read mode. I suppose that it is enough.

----------
components: Library (Lib), Unicode
files: open_python.patch
keywords: patch
messages: 120600
nosy: haypo
priority: normal
severity: normal
status: open
title: tokenize.open_python(): open a Python file with the right encoding
versions: Python 3.2
Added file: http://bugs.python.org/file19518/open_python.patch

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

From report at bugs.python.org  Sat Nov  6 11:55:17 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 06 Nov 2010 10:55:17 +0000
Subject: [New-bugs-announce] [issue10336] test_xmlrpc fails if gzip is not
	supported by client
In-Reply-To: <1289040917.15.0.713563652016.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289040917.15.0.713563652016.issue10336@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

In test_xmlrpc.py,

    def test_gsip_response(self):
        # (sniP)
        self.assertTrue(a>b)

last line can fail if gzip is not supported by client.
(gzip is not set in HTTP header's Accept-Encoding)

======================================================================
FAIL: test_gsip_response (__main__.GzipServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_xmlrpc.py", line 722, in test_gsip_resp
onse
    self.assertTrue(a>b)
AssertionError: False is not True

----------
components: Library (Lib)
messages: 120602
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_xmlrpc fails if gzip is not supported by client
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov  6 12:03:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:03:55 +0000
Subject: [New-bugs-announce] [issue10337] testTanh() of test_math fails on
	"NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On "NetBSD 5 i386 3.x" buildbot, testTanh() of test_math fails because the sign of wrong.

configure scripts has a test to check if tanh(-0.0) keeps the sign or no, and on this buildbot the result is "no". pyconfig.h contains a TANH_PRESERVES_ZERO_SIGN define, but it is not used in Modules/mathmodule.c. Extract of configure comment:

# On FreeBSD 6.2, it appears that tanh(-0.) returns 0. instead of
# -0. on some architectures.

---

http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/configure/logs/stdio
...
checking whether tanh preserves the sign of zero... no
...

http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/test/logs/stdio
======================================================================
FAIL: testTanh (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.smith-netbsd-i386/build/Lib/test/test_math.py", line 898, in testTanh
    math.copysign(1., -0.))
AssertionError: 1.0 != -1.0

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

----------
components: Library (Lib)
messages: 120604
nosy: haypo
priority: normal
severity: normal
status: open
title: testTanh() of test_math fails on "NetBSD 5 i386 3.x"
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov  6 12:12:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:12:38 +0000
Subject: [New-bugs-announce] [issue10338] test_lib2to3 failure on buildbot
	x86 debian parallel	3.x: node is None in find_root()
In-Reply-To: <1289041958.15.0.549624913321.issue10338@psf.upfronthosting.co.za>
Message-ID: <1289041958.15.0.549624913321.issue10338@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86%20debian%20parallel%203.x/builds/806/steps/test/logs/stdio

test test_lib2to3 failed -- multiple errors occurred

======================================================================
ERROR: test_bom (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 239, in test_bom
    data = self.check_file_refactoring(fn)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_crlf_newlines (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 248, in test_crlf_newlines
    self.check_file_refactoring(fn, fixes)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_file_encoding (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 235, in test_file_encoding
    self.check_file_refactoring(fn)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_unencodable_diff (lib2to3.tests.test_main.TestMain)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_main.py", line 36, in test_unencodable_diff
    ret = self.run_2to3_capture(["-"], input_stream, out_enc, err)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_main.py", line 25, in run_2to3_capture
    return main.main("lib2to3.fixes", args)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/main.py", line 168, in main
    rt.refactor_stdin()
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 393, in refactor_stdin
    tree = self.refactor_string(input, "<stdin>")
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

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

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120607
nosy: benjamin.peterson, haypo
priority: normal
severity: normal
status: open
title: test_lib2to3 failure on buildbot x86 debian parallel 3.x: node is None in find_root()
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov  6 12:49:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Nov 2010 11:49:33 +0000
Subject: [New-bugs-announce] [issue10339] test_lib2to3 leaks
In-Reply-To: <1289044173.26.0.233554890418.issue10339@psf.upfronthosting.co.za>
Message-ID: <1289044173.26.0.233554890418.issue10339@psf.upfronthosting.co.za>


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

This is only on 3.1:

$ ./python -m test.regrtest -R 3:3 test_lib2to3
test_lib2to3
beginning 6 repetitions
123456
No handlers could be found for logger "RefactoringTool"
......
test_lib2to3 leaked [32, 32, 32] references, sum=96

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool), Tests
messages: 120609
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_lib2to3 leaks
type: resource usage
versions: Python 3.1

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

From report at bugs.python.org  Sat Nov  6 15:56:32 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 14:56:32 +0000
Subject: [New-bugs-announce] [issue10340] asyncore doesn't properly handle
	EINVAL on OSX
In-Reply-To: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>
Message-ID: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://code.google.com/p/pyftpdlib/issues/detail?id=143
This comes from a user who sent me a report via e-mail. Unfortunately I don't have an OSX box to test against.

Code which should replicate the problem is this:

import socket, struct
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
s.connect(('localhost', 21))
s.close()

...while this is a fix I think it should work:

Index: Lib/asyncore.py
===================================================================
--- Lib/asyncore.py	(revisione 86084)
+++ Lib/asyncore.py	(copia locale)
@@ -242,7 +242,7 @@
             try:
                 self.addr = sock.getpeername()
             except socket.error, err:
-                if err.args[0] == ENOTCONN:
+                if err.args[0] in (ENOTCONN, EINVAL):
                     # To handle the case where we got an unconnected
                     # socket.
                     self.connected = False


Nosying ixokai as I know he has an OSX box to test against.
Setting "high" priority and type == "security" as asyncore-based servers are likely to crash because of this.
It might even make sense to backport the fix in Python 2.6 because of the security implications.

----------
components: Library (Lib)
keywords: patch
messages: 120620
nosy: giampaolo.rodola, ixokai
priority: high
severity: normal
stage: patch review
status: open
title: asyncore doesn't properly handle EINVAL on OSX
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov  6 16:08:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:08:12 +0000
Subject: [New-bugs-announce] [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

There are some leftovers of the short-lived presence of setuptools in the CPython source tree, precisely in Tools/msi/msi.py and Makefile.pre.in.  Attached patch removes them.

----------
components: Build
files: remove-setuptools-leftovers.diff
keywords: patch
messages: 120621
nosy: eric.araujo, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Remove traces of setuptools
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19521/remove-setuptools-leftovers.diff

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

From report at bugs.python.org  Sat Nov  6 16:26:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 15:26:49 +0000
Subject: [New-bugs-announce] [issue10342] trace module cannot produce
	coverage reports for zipped	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Please run attached zip archive as a python script.  Note that the problem is not specific for using __main__.py - any module that comes from a zip archive or loaded by a custom loader would show the same bug. 

$ unzip -l test.zip 
Archive:  test.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
       79  10-24-08 18:26   __main__.py
 --------                   -------
       79                   1 file
$ $ cat __main__.py
from trace import Trace

def traced(flag):
    if flag:
        return 1
    else:
        return 2

tracer = Trace()
tracer.runfunc(traced, False)
results = tracer.results()
results.write_results(coverdir='.')

$ python testtrace.zip 
 --- modulename: __main__, funcname: traced
Not printing coverage data for 'testtrace.zip/__main__.py': [Errno 20] Not a directory: 'testtrace.zip/__main__.py'
__main__.py(4): __main__.py(7): $

----------
assignee: belopolsky
components: Library (Lib)
files: testtrace.zip
messages: 120626
nosy: belopolsky, haypo
priority: normal
severity: normal
stage: unit test needed
status: open
title: trace module cannot produce coverage reports for zipped modules
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19522/testtrace.zip

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

From report at bugs.python.org  Sat Nov  6 19:52:07 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sat, 06 Nov 2010 18:52:07 +0000
Subject: [New-bugs-announce] [issue10343] urllib.parse problems with bytes
	vs str
In-Reply-To: <1289069527.47.0.125931197964.issue10343@psf.upfronthosting.co.za>
Message-ID: <1289069527.47.0.125931197964.issue10343@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

urlunparse(url or params = bytes object) produces a result
with the repr of the bytes object.

urllib.parse.urlunparse(['http', 'host', '/dir', b'params', '', ''])
--> "http://host/dir;b'params'"

That's confusing since urllib/parse.py goes to a lot of trouble to
support both bytes and str.  Simplest fix is to only accept str:

Index: Lib/urllib/parse.py
@@ -219,5 +219,5 @@ def urlunparse(components):
     scheme, netloc, url, params, query, fragment = components
     if params:
-        url = "%s;%s" % (url, params)
+        url = ';'.join((url, params))
     return urlunsplit((scheme, netloc, url, query, fragment))
 
Some people at comp.lang.python tell me code shouldn't anyway do str()
just in case it is needed like urllib does, not that I can make much
sense of that discussion.  (Subject: harmful str(bytes)).

BTW, the str vs bytes code doesn't have to be quite as painful as in
urllib.parse, I enclose patch which just rearranges and factors out
some code.

----------
components: Library (Lib)
files: parse.diff
keywords: patch
messages: 120647
nosy: hfuru
priority: normal
severity: normal
status: open
title: urllib.parse problems with bytes vs str
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19525/parse.diff

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

From report at bugs.python.org  Sun Nov  7 00:00:18 2010
From: report at bugs.python.org (Santiago Piccinini)
Date: Sat, 06 Nov 2010 23:00:18 +0000
Subject: [New-bugs-announce] [issue10344] codecs.readline doesn't care
	buffering=0
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>


New submission from Santiago Piccinini <gringotumadre at gmail.com>:

codecs.readline has an internal buffer of 72 chars so calling codecs.open with buffering=0 doesn't work as expected although buffering is passed to the underlying __builtin__.open call.

Example session:

Python 3.2a3+ (py3k, Nov  6 2010, 16:17:14) 
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> f = codecs.open("foo.txt", "w", "utf-8")
>>> word = "bar\n"
>>> content = word * 1000
>>> f.write(content)
>>> f.close()
>>> f = codecs.open("foo.txt", "rb", "utf-8", buffering=0)
>>> f.readline()
'bar\n'
>>> f.tell()
72

----------
components: Library (Lib)
messages: 120652
nosy: Santiago.Piccinini
priority: normal
severity: normal
status: open
title: codecs.readline doesn't care buffering=0
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov  7 02:16:44 2010
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 07 Nov 2010 01:16:44 +0000
Subject: [New-bugs-announce] [issue10345] fcntl.ioctl always fails claiming
	an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>


New submission from Ben Gamari <bgamari at gmail.com>:

Even the simple example included below fails in the following manner,

$ sudo python3.1 hi.py 
<class 'int'> 3
Traceback (most recent call last):
  File "hi.py", line 13, in <module>
    ioctl(a, EVIOCGID, buf, True)
TypeError: ioctl requires a file or file descriptor, an integer and optionally an integer or buffer argument

As the debugging output demonstrates, the fileno() is in fact a valid fd.


#!/usr/bin/python
from fcntl import ioctl
EVIOCGID = 1
f = open('/dev/input/mouse0', 'w')
buf = bytes([0]*128)
a = (f.fileno(),)
print(a.__class__, a)
ioctl(a, EVIOCGID, buf, True)
print(buf)

----------
components: Extension Modules
messages: 120657
nosy: bgamari
priority: normal
severity: normal
status: open
title: fcntl.ioctl always fails claiming an invalid fd
versions: Python 3.1

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

From report at bugs.python.org  Sun Nov  7 11:40:19 2010
From: report at bugs.python.org (Alexey Radkov)
Date: Sun, 07 Nov 2010 10:40:19 +0000
Subject: [New-bugs-announce] [issue10346] strange arithmetic behaviour
In-Reply-To: <1289126419.86.0.576404326217.issue10346@psf.upfronthosting.co.za>
Message-ID: <1289126419.86.0.576404326217.issue10346@psf.upfronthosting.co.za>


New submission from Alexey Radkov <alexey.radkov at gmail.com>:

The following excerpt will show the issue:

$ python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 8 * 4 / ( 2 - 7 ) * 6 / 3
-14
>>>

Why it is evaluated to -14 ?? In floating point arithmetic it should be -12.8, in integer arithmetic i believe it should be -12 (at least bc and a small dedicated C program evaluate it to -12). Perhaps i do not understand some specific python arithmetic priority or associativity rules, anyway i cannot find a specific combinations of them to yield -14 in this expression.

----------
components: None
messages: 120665
nosy: alexey.radkov
priority: normal
severity: normal
status: open
title: strange arithmetic behaviour
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  7 15:25:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Nov 2010 14:25:15 +0000
Subject: [New-bugs-announce] [issue10347] regrtest progress counter makes -f
	option less useful
In-Reply-To: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>
Message-ID: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>


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

The regrtest progress counter ("[  1/350]") is very nice but makes it less practical to use the "-f" option to regrtest.

----------
components: Tests
messages: 120684
nosy: georg.brandl, pitrou
priority: low
severity: normal
status: open
title: regrtest progress counter makes -f option less useful
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  8 02:57:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 01:57:39 +0000
Subject: [New-bugs-announce] [issue10348] multiprocessing: use SYSV
	semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Support POSIX semaphore on FreeBSD is recent, optional (eg. disabled by default in FreeBSD 7) and limited (30 semaphores). SYSV should be used instead because they are less limited or more adjustable (at runtime: POSIX semaphore requires to recompile the kernel!).

This issue should fix test_concurrent_futures on FreeBSD 7.2 and 8.0: many tests use more than 30 semaphores. The maximum is test_all_completed_some_already_completed: 52 semaphores.

----------
components: Library (Lib)
keywords: buildbot
messages: 120705
nosy: db3l, haypo
priority: normal
severity: normal
status: open
title: multiprocessing: use SYSV semaphores on FreeBSD
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  8 07:52:23 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Mon, 08 Nov 2010 06:52:23 +0000
Subject: [New-bugs-announce] [issue10349] Error in Module/python.c when
	building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>


New submission from Prabhu Gurumurthy <pgurumu at gmail.com>:

When manually building on OpenBSD 4.8 using gcc 4.2.1, I got the following error:

g++ -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I/usr/home/pgurumur/temp/Python-3.1.2/Include -DTHREAD_STACK_SIZE=0x20000 -fPIC -I/usr/include  -DPy_BUILD_CORE -o Modules/python.o /usr/home/pgurumur/temp/Python-3.1.2/Modules/python.ccc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++/usr/home/pgurumur/temp/Python-3.1.2/Modules/python.c: In function 'wchar_t* char2wchar(char*)':/usr/home/pgurumur/temp/Python-3.1.2/Modules/python.c:60: error: invalid conversion from 'void*' to 'wchar_t*'*** Error code 1

I changed line 60 from:
res = PyMem_Malloc(argsize*sizeof(wchar_t));

to:
res = (wchar_t *)PyMem_Malloc(argsize*sizeof(wchar_t));

I was able to compile it successfully, another thing you would notice is that, -Wstrict-prototypes is not a valid option with g++, (just a warning though)

My configure options:

 /usr/home/pgurumur/temp/Python-3.1.2/configure --with-fpectl --with-threads --srcdir=/usr/home/pgurumur/temp/Python-3.1.2 --enable-ipv6 --enable-shared --with-cxx_main --with-signal-module --prefix=/opt/local

----------
components: Build
messages: 120714
nosy: pgurumur
priority: normal
severity: normal
status: open
title: Error in Module/python.c when building on OpenBSD 4.8
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  8 09:48:18 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 08:48:18 +0000
Subject: [New-bugs-announce] [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

errno is sometimes read too late after the error:  After another call
may have modified it.  Here's a patch against py3k.  Most of it or a
variant applies to 2.7 too, but I haven't really looked at that.

I've not looked at math code, where I don't even know what sets errno.

There might also be a late errno read at Modules/_ctypes/callproc.c
line 794: "space[0] = errno;".  Does it want the errno from before
_ctypes_get_errobj()?  I'm unsure what's going on there.

Modules/_multiprocessing/semaphore.c doesn't need the patch's extra
variable, it can instead be rearranged with the commented-out patch.

----------
components: None
files: late-errno.diff
keywords: patch
messages: 120719
nosy: hfuru
priority: normal
severity: normal
status: open
title: errno is read too late
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19539/late-errno.diff

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

From report at bugs.python.org  Mon Nov  8 10:22:40 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Mon, 08 Nov 2010 09:22:40 +0000
Subject: [New-bugs-announce] [issue10351] to introduce autocompletion for
	keys in dictionaries	(patch attached)
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

1. The patch introduces autocompletion for keys in dictionaries (patch attached)

2. The patched rlcompleter as such works OK for unicode dictionary keys as well. All tests pass OK. HOWEVER, readline's completion mechanism seem to be confused with unicode strings -- see comments to Completer.dict_key_matches(). So, perhaps, one day some changes should be applied to readline code too.

3. rlcompleter.py has no tests in trunk -- I spawn a separate issue for it. Meanwhile I took test_rlcompleter.py from 2.7 and extended it.

4. The following usual lines in .pythonstartup:
import readline
import rlcompleter
readline.parse_and_bind('tab: complete')
readline.parse_and_bind('Control-Space: complete')

should be extended by this one:
readline.set_completer_delims(re.compile(r'[\'"\\[]').sub('', readline.get_completer_delims()))

----------
components: Library (Lib)
files: rlcompleter-dict-keys-autocompletion.tar.gz
messages: 120721
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: to introduce autocompletion for keys in dictionaries (patch attached)
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19540/rlcompleter-dict-keys-autocompletion.tar.gz

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

From report at bugs.python.org  Mon Nov  8 10:27:43 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Mon, 08 Nov 2010 09:27:43 +0000
Subject: [New-bugs-announce] [issue10352] rlcompleter.py has no tests in
	trunk
In-Reply-To: <1289208463.71.0.79566317851.issue10352@psf.upfronthosting.co.za>
Message-ID: <1289208463.71.0.79566317851.issue10352@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

rlcompleter.py has no test_rlcompleter in trunk, see http://svn.python.org/view/python/trunk/Lib/test/
There is one in 2.7 though.

Remark: the issue http://bugs.python.org/issue10351 introduces autocompletion patch and comes with new tests. So, one may want to use it as for up-to-date test_rlcompleter.py, given the issue #10351 is accepted ;-)

----------
components: Library (Lib), Tests
messages: 120722
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: rlcompleter.py has no tests in trunk
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov  8 12:03:43 2010
From: report at bugs.python.org (Peter)
Date: Mon, 08 Nov 2010 11:03:43 +0000
Subject: [New-bugs-announce] [issue10353] 2to3 and places argument in
	unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

Consider the following example unit test using assertAlmostEqual which uses the places argument as a positional argument, call this places.py:

import unittest
class Tests(unittest.TestCase):
    def test_equal_to_five_decimal_places(self):
        """Check assertAlmostEqual using decimal places"""
        self.assertAlmostEqual(0.123456789, 0.123456, 5)
if __name__ == "__main__":
    runner = unittest.TextTestRunner(verbosity = 2)
    unittest.main(testRunner=runner)



This works fine with Python 2.6.6 (Linux),

$ python2.6 places.py
Check assertAlmostEqual using decimal places ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK




Trying 2to3 on it reports no changes needed:

$ 2to3 places.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No changes to places.py
RefactoringTool: Files that need to be modified:
RefactoringTool: places.py


Trying the test as is under Python 3.1.2 (Linux) fails:

$ python3.1 places.py
test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places ... ERROR

======================================================================
ERROR: test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places
----------------------------------------------------------------------
Traceback (most recent call last):
  File "places.py", line 5, in test_equal_to_five_decimal_places
    self.assertAlmostEqual(0.123456789, 0.123456, 5)
TypeError: assertAlmostEqual() takes exactly 3 positional arguments (4 given)

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)


The test can be fixed to run on Python 3.1 (any Python 2.6) by supplying the places argument by name:


import unittest
class Tests(unittest.TestCase):
    def test_equal_to_five_decimal_places(self):
        """Check assertAlmostEqual using decimal places"""
        self.assertAlmostEqual(0.123456789, 0.123456, places=5)
if __name__ == "__main__":
    runner = unittest.TextTestRunner(verbosity = 2)
    unittest.main(testRunner=runner)


Note http://docs.python.org/library/unittest.html does not explicitly discuss passing places by name vs position. On the other hand, http://docs.python.org/py3k/library/unittest.html explicitly shows the by name form only.

I think the 2to3 script needs to be extended to use the places argument by name.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120728
nosy: maubp
priority: normal
severity: normal
status: open
title: 2to3 and places argument in unitests assertAlmostEqual
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov  8 12:28:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 11:28:15 +0000
Subject: [New-bugs-announce] [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>>> import tempfile
>>> tempfile.template = 'XXX'
>>> tempfile.mkdtemp()
'/tmp/tmpPf5lML'
>>>

Functions that use template use it as an argument default, so changing it afterwards has no effect.

----------
components: Library (Lib)
messages: 120729
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: tempfile.template is broken
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  8 13:14:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 12:14:02 +0000
Subject: [New-bugs-announce] [issue10355] SpooledTemporaryFile's name
	property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>>> import tempfile
>>> tempfile.SpooledTemporaryFile().name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/giampaolo/svn/python-2.7/Lib/tempfile.py", line 574, in name
    return self._file.name
AttributeError: 'cStringIO.StringO' object has no attribute 'name'

----------
messages: 120736
nosy: georg.brandl, giampaolo.rodola
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile's name property is broken
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  8 13:34:03 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 08 Nov 2010 12:34:03 +0000
Subject: [New-bugs-announce] [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

When the __hash__ method is called directly, the hash of -1
is -1:

>>> from decimal import *
>>> Decimal(-1).__hash__()
-1
>>> hash(Decimal(-1))
-2


I've a patch, which also sneaks in a ValueError.

----------
components: Library (Lib)
files: decimal_hash.patch
keywords: needs review, patch
messages: 120738
nosy: mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: decimal.py: hash of -1
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19543/decimal_hash.patch

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

From report at bugs.python.org  Mon Nov  8 14:16:27 2010
From: report at bugs.python.org (Fergal Daly)
Date: Mon, 08 Nov 2010 13:16:27 +0000
Subject: [New-bugs-announce] [issue10357] ** and "mapping" are poorly
	defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>


New submission from Fergal Daly <fergald at gmail.com>:

According to the index, the only place that mentions ** in argument lists is

http://docs.python.org/tutorial/controlflow.html#index-1099

and gives no indication of what an object must support to allow **.

When you attempt to ** an object the real attribute exception is suppressed and you get a message

"argument after ** must be a mapping"

"mapping" is quite loosely defined. There are 3 definitions, the glossary entry seems the most complete

http://docs.python.org/library/stdtypes.html#index-625
http://docs.python.org/reference/datamodel.html#index-842
http://docs.python.org/glossary.html#term-mapping

But even the glossary entry doesn't tell you what you need for **.

Only by reading the C source code did I discover that to be usable in **, an object must implement .keys() and .__getitem__().

The docs either should add .keys() to the definition of mapping or the code should use some other term or simply allow the original exception to reach the user.

----------
assignee: docs at python
components: Documentation
messages: 120739
nosy: Fergal.Daly, docs at python
priority: normal
severity: normal
status: open
title: ** and "mapping" are poorly defined in python docs
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  8 14:48:06 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 08 Nov 2010 13:48:06 +0000
Subject: [New-bugs-announce] [issue10358] Doc styles for print should only
	use dark colors
In-Reply-To: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>
Message-ID: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

The HTML version of the documentation should include style settings for printing that use fairly dark colors, so that printed copies of pages are more readable.

Using a printer that reduces colors to grays causes the light colors in code examples (or inlined references to classes and the like) to nearly drop out, making the result very painful to read.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 120741
nosy: docs at python, fdrake
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc styles for print should only use dark colors
type: feature request

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

From report at bugs.python.org  Mon Nov  8 15:11:33 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 14:11:33 +0000
Subject: [New-bugs-announce] [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Here are some ISO C conformance patches, and
a minor cleanup I encountered along the way.

Lib/distutils/tests/test_config_cmd.py // comment --> /* comment */.
Lib/distutils/tests/test_build_ext.py,
Objects/weakrefobject.c,
Modules/_pickle.c,
Modules/_testcapimodule.c,
Python/import.c  .  .  .  .  .  .  .   Remove some invalid ',' and ';'s.
Python/Python-ast.c,
Modules/arraymodule.c  .  .  .  .  .   Non-constant array initializer.
Modules/_csv.c   .  .  .  .  .  .  .   Slight cleanup.
Modules/_ctypes/libffi/src/x86/ffi.c   Empty translation unit.

TODO when bored, if anyone cares for more pedantic ISO patches:
- printf(%p, non-void* pointer): The pointer should be cast to void*.
- More // comments -> /**/, but mostly in system-specific code so I
  can't test any patches I make.

----------
components: None
files: iso-c.zip
messages: 120742
nosy: hfuru
priority: normal
severity: normal
status: open
title: ISO C cleanup
type: compile error
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19544/iso-c.zip

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

From report at bugs.python.org  Mon Nov  8 15:12:43 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 14:12:43 +0000
Subject: [New-bugs-announce] [issue10360] _weakrefset.WeakSet.__contains__
	should not propagate	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>


New submission from Tres Seaver <tseaver at agendaless.com>:

Because application code which tests for the presence of
an object in a WeakSet may not be able to ensure that the
object is weak-referenceable, the set should just return
False for any object passed to '__contains__' which causes
'ref' to raise a TypeError.

Patch forthcoming.

----------
messages: 120743
nosy: tseaver
priority: normal
severity: normal
status: open
title: _weakrefset.WeakSet.__contains__ should not propagate TypeErrors
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  8 18:17:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 17:17:17 +0000
Subject: [New-bugs-announce] [issue10361] Fix issue 9995 - distutils forces
	developers to store	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <90e6ba476adb7467fe04948dcbf2@google.com>


New submission from ?ric Araujo <merwok at netwok.org>:

Looks globally good to me.

http://codereview.appspot.com/2874041/diff/2001/cmd.py
File cmd.py (right):

http://codereview.appspot.com/2874041/diff/2001/cmd.py#newcode55
cmd.py:55: :param distutils.dist.Distribution dist: distribution to work
with
Please don?t include unrelated changes in your patch.

Also, Python does not use :param: in docstrings.

http://codereview.appspot.com/2874041/diff/2001/command/upload.py
File command/upload.py (right):

http://codereview.appspot.com/2874041/diff/2001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
I?d prefer a clearer comparison, please use ?is [not] None? and parens.

http://codereview.appspot.com/2874041/

----------
messages: 120776
nosy: eric.araujo, techtonik
priority: normal
severity: normal
status: open
title: Fix issue 9995 - distutils forces developers to store password in cleartext (issue2874041)

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

From report at bugs.python.org  Mon Nov  8 18:38:17 2010
From: report at bugs.python.org (ProgVal)
Date: Mon, 08 Nov 2010 17:38:17 +0000
Subject: [New-bugs-announce] [issue10362] AttributeError: addinfourl
	instance has no attribute	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>


New submission from ProgVal <progval at gmail.com>:

Hello,

I had this traceback:

Traceback (most recent call last):
...
  File "/home/progval/workspace/Supybot/Supybot-plugins/Packages/plugin.py", line 123, in extractData
    file = tarfile.open(fileobj=file_)
  File "/usr/lib/python2.6/tarfile.py", line 1651, in open
    saved_pos = fileobj.tell()
AttributeError: addinfourl instance has no attribute 'tell'

The repr(file_) is : <addinfourl at 47496224 whose fp = <socket._fileobject object at 0x2c933d0>> (the file has been downloaded with urllib).

I use Python 2.6.6 (from Debian Sid repo)

Best regards,
ProgVal

----------
messages: 120781
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: AttributeError: addinfourl instance has no attribute 'tell'

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

From report at bugs.python.org  Mon Nov  8 18:38:51 2010
From: report at bugs.python.org (Martin Dunschen)
Date: Mon, 08 Nov 2010 17:38:51 +0000
Subject: [New-bugs-announce] [issue10363] Embedded python,
	handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>


New submission from Martin Dunschen <mdunschen at gmail.com>:

I found a number of 'handle leaks' in the core code to embed python into a C/C++ application on windows. 
To reproduce: 
The simplest possible embedded application only calls:

#include <Python.h>
void entry()
{
    Py_Initialize();
    Py_Finalize();
}

I found (but this does not seem important to the problem) that when the above code is compiled into a Windows DLL, and from another simple app this DLL is loaded, the entry function is called and then the DLL is unloaded, the number of handles held by the application is increasing (by 3). Calling the steps "LoadLibrary, entry, FreeLibrary" in a loop will increase the number of held handles by 3 every time.

I can propose fixes for these 3 leaks, please find attached in the zip file patches for the files I have fixed.

But there are some issues remaining:
PyEval_InitThreads
allocates 'interpreter_lock', but there is nothing in the API that allows you to free this lock again. Should there maybe a function, in the API

void PyEval_FinishThreads(void)
{
    if (!interpreter_lock)
	return;
    PyThread_free_lock(interpreter_lock);
}

That would get rid of another handle leak if a DLL embedding python would use PyEval_InitThreads.

In a specific DLL I am debugging just now I observe 2 more handle leaks (The 4 I report here, and 2 more I have not yet found).

I hope my report is comprehensive and can be reproduced. I am happy to be of assistance if there are any questions.

Martin

----------
components: Interpreter Core
messages: 120782
nosy: martind
priority: normal
severity: normal
status: open
title: Embedded python, handle (memory) leak
type: resource usage
versions: Python 2.5, Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Nov  8 18:58:22 2010
From: report at bugs.python.org (Typo)
Date: Mon, 08 Nov 2010 17:58:22 +0000
Subject: [New-bugs-announce] [issue10364] Color coding fails after running
	program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>


New submission from Typo <lol.rabbit at yahoo.com>:

Whenever I run a program in Python 3.1.2 (windows), the color coding disappears. print() is no longer purple, def is no longer orange, etc. It all turns black, and there doesn't seem to be a way to repair this. I've installed and uninstalled Python 3.1.2 several times and it's done nothing. Loading previous programs also causes this. Only if I am making a new program is the coding separated by color. Can anyone help?

----------
components: None
messages: 120785
nosy: Typo
priority: normal
severity: normal
status: open
title: Color coding fails after running program.
type: performance
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  8 20:03:01 2010
From: report at bugs.python.org (William Barr)
Date: Mon, 08 Nov 2010 19:03:01 +0000
Subject: [New-bugs-announce] [issue10365] IDLE Crashes on File Open Dialog
	when code window closed	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>


New submission from William Barr <webmaster961 at gmail.com>:

Steps for reproduction:
1.  Open IDLE (Python 3.1.2)
2.  Open a .py file
3.  With the code window (not the shell window) in focus, Ctrl + O to bring up the open file dialog.  Do not select a file or press open.  
4.  Close the code window.  
5.  Select a file and try to open it.
6.  The IDLE process will terminate.  

This test was performed on Windows 7 Professional 32-bit as well as Windows XP Professional 32-bit.  

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32

----------
components: IDLE, Windows
messages: 120793
nosy: william.barr
priority: normal
severity: normal
status: open
title: IDLE Crashes on File Open Dialog when code window closed before other file opened
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  8 20:19:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Nov 2010 19:19:12 +0000
Subject: [New-bugs-announce] [issue10366] Remove unneeded '(object)' from
	3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 3.x, "(object)" is now superfluous in class statements. Reference manual 7.7. Class definitions has simply
    class Foo: pass

In library manual 2. Built-in Functions, class examples for classmethod and staticmethod are the same. Class examples for dir, property, and type still have '(object)' in their class examples. Section 5.11.4. Methods example omits it. I cannot think of anywhere else there should be such examples.

I think we should be consistent and remove the remaining occurrences of '(object)' in the function examples. They can only confuse newcomers.

This part is easy.

I also think the doc for 'class' should say that the default inheritance is from the base class *object* (I presume this should be true in all implementations) and that 
    class Foo(object): pass
is the same as the above (unless the name 'object' has been rebound!).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 120795
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove unneeded '(object)' from 3.x class examples
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  8 22:36:52 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 08 Nov 2010 21:36:52 +0000
Subject: [New-bugs-announce] [issue10367] "python setup.py sdist upload
	--show-response" can fail	with "UnboundLocalError: local
	variable 'result' referenced	before assignment"
In-Reply-To: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>
Message-ID: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Uploading a new release of one of my libraries to PYPI I got this error:

"""
Submitting dist/bsddb3-5.1.1.tar.gz to http://pypi.python.org/pypi
Upload failed (400): A file named "bsddb3-5.1.1.tar.gz" already exists for  bsddb3-5.1.1. To fix problems with that file you should create a new release.
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import setup2
  File "/home/pybsddb/setup2.py", line 415, in <module>
    'Programming Language :: Python :: 3.2',
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 189, in upload_file
    self.announce('-'*75, result.read(), '-'*75)
UnboundLocalError: local variable 'result' referenced before assignment
"""

Checking the code, I see this:

"""
        # send the data
        try:
            result = urlopen(request)
            status = result.getcode()
            reason = result.msg
        except socket.error, e:
            self.announce(str(e), log.ERROR)
            return
        except HTTPError, e:
            status = e.code
            reason = e.msg

        if status == 200:
            self.announce('Server response (%s): %s' % (status, reason),
                          log.INFO)
        else:
            self.announce('Upload failed (%s): %s' % (status, reason),
                          log.ERROR)
        if self.show_response:
            self.announce('-'*75, result.read(), '-'*75)
"""

Here, if we selected "show_response" *AND* some error happens, "result" will be undefined and the last line will fail.

This bug was introduced in Python 2.7. It used to work correctly under Python 2.6.

I didn't check Python 3.x.

I think this bug is trivial to reproduce: just try to upload any file with no permissions for it, using "--show_response" command line option.

----------
keywords: easy
messages: 120804
nosy: jcea
priority: high
severity: normal
stage: needs patch
status: open
title: "python setup.py sdist upload --show-response" can fail with "UnboundLocalError: local variable 'result' referenced before assignment"
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  8 22:43:58 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 08 Nov 2010 21:43:58 +0000
Subject: [New-bugs-announce] [issue10368] "python setup.py sdist upload
	--show-response" fails
In-Reply-To: <1289252638.8.0.398810501872.issue10368@psf.upfronthosting.co.za>
Message-ID: <1289252638.8.0.398810501872.issue10368@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Uploading a new module/update to PYPI, when requesting "--show_response" in the command line, will fail:

"""
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import setup2
  File "/home/pybsddb/setup2.py", line 415, in <module>
    'Programming Language :: Python :: 3.2',
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 194, in upload_file
    self.announce('-'*75, result, '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)
"""

This works correctly under Python 2.6. I haven't checked Python 3.x.

----------
keywords: easy
messages: 120806
nosy: jcea
priority: high
severity: normal
stage: needs patch
status: open
title: "python setup.py sdist upload --show-response" fails
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  9 00:42:07 2010
From: report at bugs.python.org (Dan Stromberg)
Date: Mon, 08 Nov 2010 23:42:07 +0000
Subject: [New-bugs-announce] [issue10369] tarfile requires an actual file on
	disc; a file-like object is insufficient
In-Reply-To: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>
Message-ID: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>


New submission from Dan Stromberg <strombrg at gmail.com>:

The tarfile module's gettarinfo callable insists on stat'ing the file in question, preventing one from dynamically generating file content by passing a file-like object for addfile's fileobj argument.

I believe the attached patch fixes this issue.  I generated the patch against 2.7 and tested it with 2.7, but it applies cleanly against 3.1 and "feels innocuous".  I've also included my test code at the bottom of this comment.

Why would you want to do this?  Imagine you've stored a file in three smaller files (perhaps to save the pieces on small external media, or as part of a deduplication system), with the content divided up into thirds.  To subsequently put this file as a whole into a tar archive, it'd be nice if you could just create a file-like object to emit the catenation, rather than having to create a temporary file holding that catenation.

It's occurred to me that this should be done in a more object oriented style, but that feels a bit inconsistent given that fstat is in the os module, and not provided as an attribute of a file(-like) object.  Comments?

Here's the test code:

#!/usr/local/cpython-2.7/bin/python

import os
import sys
import copy
import array
import stat_tarfile

def my_stat(filename):
        class mutable_stat:
                pass
        readonly_statobj = os.lstat(filename)
        mutable_statobj = mutable_stat()
        for attribute in dir(readonly_statobj):
                if not attribute.startswith('_'):
                        value = getattr(readonly_statobj, attribute)
                        setattr(mutable_statobj, attribute, value)
        return mutable_statobj

class generate_file_content:
        def __init__(self, number):
                self._multiplier = 100
                self._multipleno = 0
                self._number = str(number)
                self._buffer = ''

        def read(self, length):
                while self._multipleno < self._multiplier and len(self._buffer) < length:
                        self._buffer += self._number
                        self._multipleno += 1
                if self._buffer == '':
                        return ''
                else:
                        result = self._buffer[:length]
                        self._buffer = self._buffer[length:]
                        return result

def main():
        with stat_tarfile.open(fileobj = sys.stdout, mode = "w|") as tar:
                for number in xrange(100):
                        #string = str(number) * 100
                        fileobj = generate_file_content(number)
                        statobj = my_stat('/etc/passwd')
                        statobj.st_size = len(str(number)) * 100
                        filename = 'file-%d.txt' % number
                        tarinfo = tar.gettarinfo(filename, statobj = statobj)
                        tarinfo.uid = 1000
                        tarinfo.gid = 1000
                        tarinfo.uname = "dstromberg"
                        tarinfo.gname = "dstromberg"
                        tar.addfile(tarinfo, fileobj)

main()

----------
components: Library (Lib)
files: tarfile.diff
keywords: patch
messages: 120822
nosy: strombrg
priority: normal
severity: normal
status: open
title: tarfile requires an actual file on disc; a file-like object is insufficient
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19549/tarfile.diff

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

From report at bugs.python.org  Tue Nov  9 02:05:15 2010
From: report at bugs.python.org (Brian Warner)
Date: Tue, 09 Nov 2010 01:05:15 +0000
Subject: [New-bugs-announce] [issue10370] py3 readlines() reports wrong
	offset for	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>


New submission from Brian Warner <warner at users.sourceforge.net>:

I noticed that the UnicodeDecodeError exception produced by trying to do open(fn).readlines() (i.e. using the default ASCII encoding) on a file that's actually UTF-8 reports the wrong offset for the first undecodeable character. From what I can tell, it reports (offset%4096) instead of the actual offset.

I've attached a test case. It emits "all good" when run against py2.x (well, after converting the print() expressions back into statements), but reports an error at offset 4096 (reported as "0") on py3.1.2 and py3.2a3 . I'm running on a debian (sid) x86 box.

The misreported offset does not occur with read(), just with readlines().

----------
components: IO
files: test.py
messages: 120830
nosy: warner
priority: normal
severity: normal
status: open
title: py3 readlines() reports wrong offset for UnicodeDecodeError
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19552/test.py

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

From report at bugs.python.org  Tue Nov  9 03:32:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 02:32:32 +0000
Subject: [New-bugs-announce] [issue10371] Deprecate trace module
	undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Following python-dev discussion on the issue, I would like to propose trace-deprecations.diff patch for review.

I would like to make these changes before turning to issue10342 which will require changing many of these APIs that take a source path to take a module object (or possibly a loader).

Note that CoverageResults presents an interesting case of a class that does not need to be public, but its methods, particularly write_results() need to be documented.

----------
assignee: belopolsky
components: Library (Lib)
files: trace-deprecations.diff
keywords: patch
messages: 120833
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate trace module undocumented API
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19553/trace-deprecations.diff

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

From report at bugs.python.org  Tue Nov  9 11:05:49 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 09 Nov 2010 10:05:49 +0000
Subject: [New-bugs-announce] [issue10372] [REGRESSION] test_gc fails on Mac
	OSX 10.6
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

py3k r86351,


======================================================================
FAIL: test_garbage_at_shutdown (__main__.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use' not found in b''

----------------------------------------------------------------------
Ran 28 tests in 0.226s

FAILED (failures=1)
restoring automatic collection
Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 682, in <module>
    test_main()
  File "./Lib/test/test_gc.py", line 669, in test_main
    run_unittest(GCTests, GCTogglingTests)
  File "/Users/cartman/Sources/py3k/Lib/test/support.py", line 1141, in run_unittest
    _run_suite(suite)
  File "/Users/cartman/Sources/py3k/Lib/test/support.py", line 1124, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use' not found in b''

----------
components: Tests
messages: 120854
nosy: cartman
priority: normal
severity: normal
status: open
title: [REGRESSION] test_gc fails on Mac OSX 10.6
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  9 14:09:06 2010
From: report at bugs.python.org (Kirk Clendinning)
Date: Tue, 09 Nov 2010 13:09:06 +0000
Subject: [New-bugs-announce] [issue10373] Setup Script example incorrect
In-Reply-To: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>
Message-ID: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>


New submission from Kirk Clendinning <kirk at heliospectra.se>:

In 2.7. Installing Additional Files the example shows:

setup(...,
      data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
                  ('config', ['cfg/data.cfg']),
                  ('/etc/init.d', ['init-script'])]
     )

However, running easy_install with setuptools results in a error:

Setup script exited with error: SandboxViolation: open('/etc/init.d/init-script', 'wb') {}

Perhaps the documentation should be changed and more explanation added.

----------
assignee: docs at python
components: Documentation
messages: 120863
nosy: docs at python, lensart
priority: normal
severity: normal
status: open
title: Setup Script example incorrect
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Nov  9 14:11:29 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 09 Nov 2010 13:11:29 +0000
Subject: [New-bugs-announce] [issue10374] setup.py caches outdated scripts
	in the build tree
In-Reply-To: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>
Message-ID: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

I have the following setup.py script:

#!/usr/bin/env python
from distutils.core import setup

scripts=["hello.py"]

setup(scripts=scripts)

I have two different python installations (using virtualenv) where I
wish to install this program. So I do

~/tmp/test_setup/python1/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like
this:

#!/users/geoff/tmp/test_setup/python1/bin/python

print "Hello"

So far so good. But then I also install it somewhere else:

~/tmp/test_setup/python2/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python2/bin/hello.py which refers to
"python1", i..e it has the same contents as the first one. Which is
clearly not what I want.

The cached script in the build tree appears not to get updated once it exists.

----------
assignee: tarek
components: Distutils
messages: 120864
nosy: eric.araujo, gjb1002, tarek
priority: normal
severity: normal
status: open
title: setup.py caches outdated scripts in the build tree
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Nov  9 15:12:22 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 14:12:22 +0000
Subject: [New-bugs-announce] [issue10375] 2to3 print(single argument)
In-Reply-To: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>
Message-ID: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Could 2to3 without -p notice more cases of print(single argument),
to avoid slapping another () around them?  For example:

  print(2*3)
  print(", ".join(dir))
  print(very + long
        + single + argument)

My internal bug detector zooms in on ((foo)) when I read Python code -
I'm seeing code where something was apparently left out, maybe an inner
comma to make it a tuple.

[Copied from Issue10070.]

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120866
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 print(single argument)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  9 16:51:55 2010
From: report at bugs.python.org (James Hutchison)
Date: Tue, 09 Nov 2010 15:51:55 +0000
Subject: [New-bugs-announce] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

The Unzip module is always unbuffered (tested v.3.1.2 Windows XP, 32-bit). This means that if one has to do many small reads it is a lot slower than reading a chunk of data to a buffer and then reading from that buffer. It seems logical that the unzip module should default to buffered reading and/or have a buffered argument. Likewise, the documentation should clarify that there is no buffering involved when doing a read, which runs contrary to the default behavior of a normal read.

start Zipfile read
done
27432 reads done
took 0.859 seconds
start buffered Zipfile read
done
27432 reads done
took 0.072 seconds
start normal read (default buffer)
done
27432 reads done
took 0.139 seconds
start buffered normal read
done
27432
took 0.137 seconds

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 120871
nosy: Jimbofbx, docs at python
priority: normal
severity: normal
status: open
title: ZipFile unzip is unbuffered
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Nov  9 20:15:57 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 09 Nov 2010 19:15:57 +0000
Subject: [New-bugs-announce] [issue10377] cProfile incorrectly labels its
	output
In-Reply-To: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>
Message-ID: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

Consider this transcript:

>>> cProfile.run("import time; time.sleep(1)")
         4 function calls in 1.012 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.011    0.011    1.012    1.012 <string>:1(<module>)
        1    0.000    0.000    1.012    1.012 {built-in method exec}
        1    1.001    1.001    1.001    1.001 {built-in method sleep}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}


>>> 

It is not the case that the profiled code uses >1 CPU seconds.  It spends the entire time sleeping.  The default timer for cProfile is a wallclock timer.  The output should reflect this.

----------
messages: 120890
nosy: exarkun
priority: normal
severity: normal
status: open
title: cProfile incorrectly labels its output
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  9 22:00:53 2010
From: report at bugs.python.org (Richard Fuhr)
Date: Tue, 09 Nov 2010 21:00:53 +0000
Subject: [New-bugs-announce] [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>
Message-ID: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>


New submission from Richard Fuhr <richard.fuhr at gmail.com>:

When running Python 2.7 if you invoke 

help(divmod)

the first line of the resulting help displays

Help on built-in function divmod in module __builtin__:

but I believe that the name of the module is __builtins__

so the line should say

Help on built-in function divmod in module __builtinsq__:

----------
assignee: docs at python
components: Documentation
messages: 120900
nosy: docs at python, rdfuhr
priority: normal
severity: normal
status: open
title: Typo in results of help(divmod)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 10 00:33:26 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Nov 2010 23:33:26 +0000
Subject: [New-bugs-announce] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

@mission[~:1001]% python2.7 -c "import locale; print locale.format('%.0f KB', 100)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/locale.py", line 189, in format
    "format specifier, %s not valid") % repr(percent))
ValueError: format() must be given exactly one %char format specifier, '%.0f KB' not valid
@mission[~:1002]% python2.6 -c "import locale; print locale.format('%.0f KB', 100)"
100 KB

----------
messages: 120905
nosy: barry
priority: normal
severity: normal
status: open
title: locale.format() input regression
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 10 07:29:25 2010
From: report at bugs.python.org (Peda Venkateswarlu Pola)
Date: Wed, 10 Nov 2010 06:29:25 +0000
Subject: [New-bugs-announce] [issue10380] AttributeError: 'module' object
	has no attribute	'exc_traceback'
In-Reply-To: <1289370565.38.0.315034311665.issue10380@psf.upfronthosting.co.za>
Message-ID: <1289370565.38.0.315034311665.issue10380@psf.upfronthosting.co.za>


New submission from Peda Venkateswarlu Pola <pola.venki at gmail.com>:

As we have some new requirements in standard logging, We have written wrapper logger. This includes find caller which gives information about filename , line number , class name and method name. As i found that python logger doesn't give class name so we get the code from python logger and modified to our requirement. 

We end up with the following error intermittently from the function "currentframe()" .

"AttributeError: 'module' object has no attribute 'exc_traceback'"


def currentframe():
    """Return the frame object for the caller's stack frame."""
    try:
        raise Exception
    except:
        return sys.exc_traceback.tb_frame.f_back

Please help me out ASAP.

Great thanks in advance.

----------
components: None
files: findcaller_modi.py
messages: 120913
nosy: polavenki
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'exc_traceback'
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file19563/findcaller_modi.py

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

From report at bugs.python.org  Thu Nov 11 03:54:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 02:54:05 +0000
Subject: [New-bugs-announce] [issue10385] Mark up "subprocess" as module in
	its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I was going to commit this patch, but decided to ask for a second opinion.  I think module names in section titles should be marked up with :mod:.

----------
assignee: belopolsky
components: Documentation
files: subprocess-doc.diff
keywords: patch
messages: 120937
nosy: belopolsky
priority: normal
severity: normal
stage: commit review
status: open
title: Mark up "subprocess" as module in its doc
versions: Python 3.2
Added file: http://bugs.python.org/file19567/subprocess-doc.diff

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

From report at bugs.python.org  Wed Nov 10 21:31:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Nov 2010 20:31:26 +0000
Subject: [New-bugs-announce] [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>


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

Y:\>py3k\__svn__\PCbuild\python_d.exe -m test.regrtest -R 3:2 test_os
[1/1] test_os
[33558 refs]
beginning 5 repetitions
12345
[33558 refs]
.[33558 refs]
.[33558 refs]
.[33558 refs]
.[33558 refs]
.
test_os leaked [3, 3] references, sum=6
1 test failed:
    test_os
[117612 refs]

----------
components: Library (Lib), Windows
messages: 120931
nosy: amaury.forgeotdarc, brian.curtin, ocean-city, pitrou, rhettinger, tim.golden
priority: normal
severity: normal
status: open
title: test_os leaks under Windows
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 10 20:36:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 19:36:15 +0000
Subject: [New-bugs-announce] [issue10382] Command line error marker
	misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> ??????????
  File "<stdin>", line 1
    ??????????
                          ^
SyntaxError: invalid character in identifier


It looks like strlen() is used instead of number of characters in the decoded string.

----------
components: Interpreter Core
messages: 120930
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Command line error marker misplaced on unicode entry
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 11 05:08:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 04:08:44 +0000
Subject: [New-bugs-announce] [issue10386] token module should define __all__
In-Reply-To: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>
Message-ID: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The token module appears to be designed to be used with import *.  In fact it is used this way in the tokenize module.  However it does not define __all__ and as a result, from token import * leaks symbol "main":

>>> import tokenize
>>> tokenize.main.__module__
'token'

Attached patch adds token.__all__ and "modernizes" generation of the tok_name dictionary.

I also renamed main to _main because it is hard to imagine that any user code would ever want to use it.

----------
components: Library (Lib)
files: token-all.diff
keywords: patch
messages: 120938
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: token module should define __all__
versions: Python 3.2
Added file: http://bugs.python.org/file19568/token-all.diff

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

From report at bugs.python.org  Wed Nov 10 19:50:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 18:50:57 +0000
Subject: [New-bugs-announce] [issue10381] Add timezone support to datetime C
	API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With timezone class added to datetime module, C API should be extended to at the minimum support efficient creation of timezone instances and access to the singleton UTC instance.

I am not sure whether PyDateTime_TimeZone details should be exposed in datetime.h because presumably programmers should access it through the abstract tzinfo interface.

----------
assignee: belopolsky
components: Extension Modules
messages: 120928
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Add timezone support to datetime C API
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 11 02:34:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 01:34:45 +0000
Subject: [New-bugs-announce] [issue10384] SyntaxError should contain exact
	location of the invalid	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Can you see the error in the following?

>>> inv?alid = 5
  File "<stdin>", line 1
    inv?alid = 5
             ^
SyntaxError: invalid character in identifier

The problem is that an invisible space character crept into the identifier:

>>> repr("inv?alid")
"'inv\\u200balid'"

With full unicode available in most OSes, the potential for errors like this (accidental or as a result of a practical joke) increases.  It would be much easier to spot the offending character if ^ marker pointed at the exact location rather than at the end of the identifier.


See also issue #10382.

----------
components: Interpreter Core
messages: 120936
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: SyntaxError should contain exact location of the invalid character in identifier
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 11 13:06:24 2010
From: report at bugs.python.org (Felix Laurie von Massenbach)
Date: Thu, 11 Nov 2010 12:06:24 +0000
Subject: [New-bugs-announce] [issue10387] ConfigParser's getboolean method
	is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>


New submission from Felix Laurie von Massenbach <fantasizer at gmail.com>:

If the config file has a boolean formatted as either True or False, python raises an attribute error when doing str.lower() on it. In my code I've worked around this in the following way:

class MyConfigParser(ConfigParser.RawConfigParser):
    def getboolean(self, section, option):
        result = self.get(section, option)
        try:
            trues = ["1", "yes", "true", "on"]
            falses = ["0", "no", "false", "off"]
            if result in trues:
                return True
            if result in falses:
                return False
        except AttributeError as err:
            if str(err) == "\'bool\' object has no attribute \'lower\'":
                return result
            raise err

Felix

(p.s. first bug report, sorry if it's a bit of a mess...)

----------
components: Extension Modules
messages: 120943
nosy: Felix.Laurie.von.Massenbach
priority: normal
severity: normal
status: open
title: ConfigParser's getboolean method is broken
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 11 15:03:12 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 11 Nov 2010 14:03:12 +0000
Subject: [New-bugs-announce] [issue10388] spwd returning different value
	depending on privileges
In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>
Message-ID: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As root:

>>> import spwd
>>> spwd.getspall()
[spwd.struct_spwd(sp_nam='root', sp_pwd='!', sp_lstchg=14895, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)
 ...
]

As limited user:

>>> import spwd
>>> spwd.getspall()
[]
>>> 

Wouldn't it be better for consistency to raise OSError EACCES instead?

----------
messages: 120950
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: spwd returning different value depending on privileges
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Nov 11 16:05:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 15:05:56 +0000
Subject: [New-bugs-announce] [issue10389] Document rules for use of case in
	section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Following a brief and consensual discussion on docs at python and #python-dev, I am proposing attached patch for the Python documentation style guide.

----------
assignee: belopolsky
components: Documentation
files: style-guide.diff
keywords: patch
messages: 120955
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Document rules for use of case in section titles
versions: Python 3.2
Added file: http://bugs.python.org/file19570/style-guide.diff

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

From report at bugs.python.org  Thu Nov 11 17:50:05 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 11 Nov 2010 16:50:05 +0000
Subject: [New-bugs-announce] [issue10390] json.load should handle bytes input
In-Reply-To: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>
Message-ID: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

The following code produces an error:

# APIKEY defined above
r = urllib.request.urlopen('http://api.billboard.com/apisvc/chart/v1/'
                           'list/spec?api_key={}&format=JSON'
                           .format(APIKEY))
j = json.load(r)

Specifically, the urlopen() function returns a request object that can be read, the request object returns a bytes object containing JSON, and the json.load() function tries to mix str and bytes objects when using the re module.

json.load() should convert bytes to str. It is reasonable that one should be able to open a url and pass the result directly to json.load().

----------
components: Library (Lib)
messages: 120960
nosy: jfinkels
priority: normal
severity: normal
status: open
title: json.load should handle bytes input
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 11 21:53:43 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Nov 2010 20:53:43 +0000
Subject: [New-bugs-announce] [issue10391] obj2ast's error handling can lead
	to python crashing	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

In various places within the generated Python/Python-ast.c, error handling generates a repr() and raises exceptions accordingly.

Currently in py3k the generated code uses PyBytes_AS_STRING() on the repr.  My understanding is that repr() should be a PyUnicodeObject, not a PyBytesObject.  This seems to be unchanged from r63682, which was a mass-change of PyString to PyBytes from 2 years ago.

This leads to a python crashing with an assertion failure:
test_compile_ast (__main__.TestSpecifics) ... python: Python/Python-ast.c:5835: obj2ast_expr: Assertion `((((((PyObject*)(tmp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.

when invoking compile() on certain (malformed) trees of ast objects.

----------
components: Interpreter Core
messages: 120967
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: obj2ast's error handling can lead to python crashing with a C-level assertion failure
type: crash
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov 12 06:58:44 2010
From: report at bugs.python.org (Brad Greenlee)
Date: Fri, 12 Nov 2010 05:58:44 +0000
Subject: [New-bugs-announce] [issue10392] GZipFile crash when fileobj.mode
	is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>


New submission from Brad Greenlee <brad at footle.org>:

If GZipFile.__init_ is passed a fileobj that has a mode attribute set to None, it will crash with a "'NoneType' object is unsubscriptable" error when it tries to read the first character of the mode.

I ran across this when trying to pass GZipFile an uploaded file in Django 1.2.3. Django produced an InMemoryUploadedFile object that has a mode attribute set to None.

The attached patch fixes the issue by only using fileobj.mode if it exists and is not None.

(The patch is against 2.7, although the issue exists in all versions I've looked at.)

----------
components: Library (Lib)
files: gzip_mode_fix.diff
keywords: patch
messages: 121021
nosy: bgreenlee
priority: normal
severity: normal
status: open
title: GZipFile crash when fileobj.mode is None
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19576/gzip_mode_fix.diff

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

From report at bugs.python.org  Fri Nov 12 15:04:00 2010
From: report at bugs.python.org (Abyx)
Date: Fri, 12 Nov 2010 14:04:00 +0000
Subject: [New-bugs-announce] [issue10393] "with" statement isn't thread-safe
In-Reply-To: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>
Message-ID: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>


New submission from Abyx <fl.lllj at gmail.com>:

Code to reproduce the bug:

#include <python.h>
#include <windows.h>

DWORD WINAPI thread_fn(void* code)
{
	PyGILState_STATE state = PyGILState_Ensure();
	PyRun_SimpleString("with sync: print('.')\n");
	PyGILState_Release(state);
	return 0;
}

int main()
{
	PyEval_InitThreads();
	Py_Initialize();
	PyRun_SimpleString("import _thread\n");
	PyRun_SimpleString("sync = _thread.allocate_lock()\n");
	PyThreadState* mainstate = PyEval_SaveThread();

	HANDLE hThread1 = CreateThread(0, 0, thread_fn, 0, 0, 0);
	HANDLE hThread2 = CreateThread(0, 0, thread_fn, 0, 0, 0);
	WaitForSingleObject(hThread1, INFINITE);
	WaitForSingleObject(hThread2, INFINITE);

	PyEval_RestoreThread(mainstate);
	Py_Finalize();
}

------------ Output ------
.
.
Traceback (most recent call last):
  File "<string>", line 2, in <module>
NameError: name '_[1]' is not defined
----------- End of output -----

Probably both threads uses the same "_" global variable. First thread releases GIL in "print" function, then second thread overwrites "_", and then first thread raises the NameError accessing "_" later. Sometimes (not ever) the "sync" kept locked, and program deadlocks on next "sync.acquire()" call from another thread (if any).

----------
components: Interpreter Core
messages: 121035
nosy: Abyx
priority: normal
severity: normal
status: open
title: "with" statement isn't thread-safe
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Fri Nov 12 15:05:08 2010
From: report at bugs.python.org (Christoph Mathys)
Date: Fri, 12 Nov 2010 14:05:08 +0000
Subject: [New-bugs-announce] [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>


New submission from Christoph Mathys <eraserix at gmail.com>:

The ctor of subprocess.Popen has a race condition, which the attached program should demonstrate (on my computer a few seconds are enough). Program One sleeps for 2 seconds, Program Two exits right after execve. Now I would expect Program Two to take a very short time between Popen and the completion of wait(), but it regularly takes about 2 seconds.

The problem is this: Popen._execute_child opens a pipe and sets the FD_CLOEXEC flag. If thread_1 just finished creating the pipe but could not yet set FD_CLOEXEC when thread_2 fork()s, thread_1 will lock up when it reads on the pipe (errpipe_read). The process forked by thread_1 will close the pipe, but the process forked by thread_2 will only close the pipe when it exits, blocking thread_1 inside the read function until then.

I see different options:
Linux has the platform specific flag O_CLOEXEC to set this flag during open() (the manpage of open says since 2.6.23, so highly platform dependent)

To just solve the problem for Popens ctor it is enough to serialize all code from before pipe() until after fork(). This can still lead to problems if fork is called in other contexts than Popens ctor.

A general solution would be to use a socket which can be shutdown().

If close_fds is set for Popens ctor, the problem does not occur because the extra pipe of the forked process will be closed.

----------
components: Library (Lib)
files: deadlock.py
messages: 121036
nosy: Christoph.Mathys
priority: normal
severity: normal
status: open
title: subprocess Popen deadlock
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19579/deadlock.py

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

From report at bugs.python.org  Fri Nov 12 16:14:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 12 Nov 2010 15:14:07 +0000
Subject: [New-bugs-announce] [issue10395] os.path.commonprefix broken by
	design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for os.path.commonprefix notes:

os.path.commonprefix(list)
Return the longest path prefix (taken character-by-character) that is a prefix of all paths in list. If list is empty, return the empty string (''). Note that this may return invalid paths because it works a character at a time.

And indeed:


>>> os.path.commonprefix(['/usr/bin', '/usr/bicycle'])
'/usr/bi'


This is IMHO useless behaviour for a function in the os.path namespace, I'd expect that os.path.commonprefix works with path elements (e.g. that the call above would have returned '/usr').

----------
components: Library (Lib)
messages: 121038
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: os.path.commonprefix broken by design
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 12 18:50:21 2010
From: report at bugs.python.org (Michael Hoffman)
Date: Fri, 12 Nov 2010 17:50:21 +0000
Subject: [New-bugs-announce] [issue10396] stdin argument to pdb.Pdb doesn't
	work unless you also	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>


New submission from Michael Hoffman <qq9jsuvyyw at snkmail.com>:

If you create a Pdb instance with an stdin argument, the default behavior is for commands to be retrieved using raw_input(), which uses sys.stdin instead, thereby causing the stdin argument to be without effect.

You can work around this by setting the use_rawinput attribute of the instance to False, but this should be done whenever an stdin argument is given to the constructor.

----------
components: Library (Lib)
files: testcase.py
messages: 121050
nosy: hoffman
priority: normal
severity: normal
status: open
title: stdin argument to pdb.Pdb doesn't work unless you also set Pdb.use_rawinput = False
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19580/testcase.py

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

From report at bugs.python.org  Fri Nov 12 20:21:51 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Fri, 12 Nov 2010 19:21:51 +0000
Subject: [New-bugs-announce] [issue10397] Unified Benchmark Suite fails on
	py3k with --track-memory
In-Reply-To: <1289589711.2.0.279349979417.issue10397@psf.upfronthosting.co.za>
Message-ID: <1289589711.2.0.279349979417.issue10397@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

Steps to reproduce (requires linux because the --track-memory (-m) option to perf.py is linux-only):
hg clone http://hg.python.org/benchmarks/ py2benchmarks
mkdir py3benchmarks
cd py3benchmarks
../py2benchmarks/make_perf3.sh ../py2benchmarks
py3k perf.py -f -m -b normal_startup old_py3k new_py3k

With --track-memory, the normal_startup benchmark (which is part of the py3k benchmark group) invokes the interpreter under test as:
py3k -c 'for _ in xrange(200000): pass'

This fails on py3k due to the use of xrange, which is not caught by 2to3 since it appears inside a quoted string (the command line argument).

A patch is attached that resolves the issue by changing the for loop with xrange into a while loop.

----------
assignee: collinwinter
components: Benchmarks
files: perf.patch
keywords: patch
messages: 121060
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Unified Benchmark Suite fails on py3k with --track-memory
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19582/perf.patch

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

From report at bugs.python.org  Fri Nov 12 20:36:08 2010
From: report at bugs.python.org (Jani Poikela)
Date: Fri, 12 Nov 2010 19:36:08 +0000
Subject: [New-bugs-announce] [issue10398] errors in docs re module
	initialization vs self arg to	functions
In-Reply-To: <1289590568.94.0.655390055242.issue10398@psf.upfronthosting.co.za>
Message-ID: <1289590568.94.0.655390055242.issue10398@psf.upfronthosting.co.za>


New submission from Jani Poikela <poppis.poikela at gmail.com>:

Copy of issue 6421
Affects 2.7 too...

----------
assignee: docs at python
components: Documentation
messages: 121064
nosy: Jani.Poikela, aleax, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: errors in docs re module initialization vs self arg to functions
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 12 21:16:52 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 12 Nov 2010 20:16:52 +0000
Subject: [New-bugs-announce] [issue10399] AST Optimization: inlining of
	function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

In msg#120541 of issue#1346238 Raymond suggested to "aim high", so here goes...

I'm opening this as a separate bug as it's a very different approach to the patches in that bug; adding those on the nosy list for that bug.  Sorry in advance about the epic length of this comment.

I've been experimenting with AST optimizations, and have a (very) primitive implementation of function-call inlining.  As is, it's deeply flawed, but in a spirit of "Release Early, Release Often" I though I'd post what I have so far, and try to enumerate the rest of the work that would need doing to get this into, say Python 3.3

The attached patch adds an AST optimization pass to Python/compiler.c.  It does this by adding an __optimizer__.py module: the compiler converts the AST to a Python representation using ast2mod, and calls out to __optimizer__.optimize_ast().  This can then (potentially) apply a series of manipulations to the tree.  The result is then converted back from python to ast objects, and compilation proceeds as normal on the modified AST tree.

I initially was experimenting with a .c implementation, but moving to .py makes things _much_ easier to develop and debug.  In particular, I'm using graphviz's "dot" tool to generate before/after visualizations of the AST.

The optimizer doesn't try to optimize itself (or anything that it imports), to avoid infinite recursion when we have a cold .pyo cache.

Currently I'm doing the AST optimization before symbol table generation.  This means that the inlining is deeply flawed, as it has no knowledge of the scope of names.  A robust implementation would compare the scopes of the callsite and that of the function body, and remap locals accordingly.  The current implementation renames all name references in the function body, which is clearly wrong for e.g. references to globals.  See below for notes on that.

Here's my test code::
    def function_to_be_inlined(x, y, z):
        return (2 * x * y) + z
    print(function_to_be_inlined(3, 4, 5))

Here's what it compiles to after going through the inliner (clearly, line numbering needs some work).  Note the removal of the CALL_FUNCTION of our target call site; the remaining CALL_FUNCTION is to "print":
  2           0 LOAD_CONST               0 (<code object function_to_be_inlined at 0x1e9b998, file "<dis>", line 2>) 
              3 MAKE_FUNCTION            0 
              6 STORE_NAME               0 (function_to_be_inlined) 

  4           9 LOAD_CONST               1 (3) 
             12 STORE_NAME               1 (__inline1f22840__x) 
             15 LOAD_CONST               2 (4) 
             18 STORE_NAME               2 (__inline1f22840__y) 
             21 LOAD_CONST               3 (5) 
             24 STORE_NAME               3 (__inline1f22840__z) 

259          27 LOAD_CONST               4 (2) 
             30 LOAD_NAME                1 (__inline1f22840__x) 
             33 BINARY_MULTIPLY      
             34 LOAD_NAME                2 (__inline1f22840__y) 
             37 BINARY_MULTIPLY      
             38 LOAD_NAME                3 (__inline1f22840__z) 
             41 BINARY_ADD           
             42 STORE_NAME               4 (__inline1f22840____returnval__) 

260          45 LOAD_NAME                5 (print) 
             48 LOAD_NAME                4 (__inline1f22840____returnval__) 
             51 CALL_FUNCTION            1 
             54 POP_TOP              
             55 LOAD_CONST               5 (None) 
             58 RETURN_VALUE         

The idea is that a further optimization pass would go through and ellide the unnecessary store-to-local/load-from-local instructions, followed by const folding, getting this down to:
   LOAD_CONST (<code object>)
   MAKE_FUNCTION
   STORE_NAME (function_to_be_inlined)
; inlined callsite:
   LOAD_NAME  (print)
   LOAD_CONST (29)
   CALL_FUNCTION 1


The biggest issue here is dealing with runtime differences between which function was inlined, and which function is being called, either via monkeypatching, or in method calls - we can inline intra-method calls within one class, but we have to cope with overriding of those methods in subclasses.

Thinking aloud of a way of solving this (this isn't implemented yet):
   add to AST:
     Specialize(expr name,
                stmt* specialized,
                stmt* generalized)

where you have some interpretation of name (e.g. "self.do_something"), and carry two different implementations.

  so that e.g.
  class Something:
     def foo(self, x, y, z):
           ... # some code
           self.bar(x, y, z)
           ... # more code
  the:
     Call(Attribute(Name(id='self'), id='bar'), args=[etc])
  becomes
     Specialize(name=Attribute(Name(id='self'), id='bar'),
                specialized=[inlined implementation of Something.bar for "self"],
                generalized=[Call(Attribute(Name(id='self'), id='bar'), args=[etc])])

Similarly, would need a new bytecode, say "JUMP_IF_SPECIALIZABLE"

      LOAD_NAME (self)
      GET_ATTR  ('bar')
  ; method self.bar is now on top of stack
      LOAD_CONST (<code object for the regular implementation of "bar">)
      JUMP_IF_SPECIALIZABLE -> label_inline_body
  ; Start of non-inlined call
      eval and push args
      CALL_FUNCTION
      JUMP_ABSOLUTE -> label_after
  ; ...end of non-inlined call; return value is top-of-stack

label_inline_body:
      eval args (potentially optimizing with knowledge of what's to come)
      inlined call
      push "return value"
  ; ...end of inlined call; "return value" is top-of-stack

label_after:     

   ; etc


JUMP_IF_SPECIALIZABLE
Inputs:
TOS    : A: code object we inlined for (via a LOAD_CONST, injected by the inliner)
TOS -1 : B: function object via runtime lookup (LOAD_GLOBAL, or e.g. LOAD_LOCAL "self"; GET_ATTR "do_something")

Action:
  if B's __code__ is A, we can specialize:
     PC += oparg
     POP
  else:
     PC += 1
     POP
     POP

I'm not sure if this covers all cases (e.g. specializing a CFunction such as the builtins), or if this a sane approach that actually works; need to have a standard interpretation of what a name lookup means, and to inject LOAD_CONST of that value into the bytecode, for use by the JUMP_IF_SPECIALIZABLE operation.

As I understand it, functions are "name-resolved" before the arguments are evaluated, so if argument evaluation leads to the name being bound to a different function (as a side effect), the status quo in CPython currently is that the old function is used for that call; JUMP_IF_SPECIALIZABLE would preserve that behavior.

It could also slightly slow down overridden method calls, as it would add a test for "am I overridden" that would generally take the "overridden" branch; perhaps we could detect classes with subclasses in the same AST and suppress inlining for this case.  Similarly, it could spot the
    def override_me(self):
         raise NotImplementedError
pattern and not try to inline.


Other issues:
  - Somehow need to tie together symbol tables with ast2mod.  One approach: do the symtable generation first, then adjust ast2mod so that it adds PySymtableEntry references to the generated python tree as appopriate.  This would expose the name scope structure.  But after the tree changes, do we need to regenerate the symbol table?  Or we could annotate the python ast.Name objects with scope information, and the ast optimizer would be responsible for keeping this correct.  The compiler could then rerun the symtable analysis on the returned AST, or could trust the optimizer's info.

  - What to do with the "locals()" builtin?  Inlined functions could save a copy of locals with duplicate names, keeping their existing names for the locals in the inlined copy.  This would lead to "locals()" having additional items when called from an inlined function.

  - Many optimizations would have to assume that locals don't change value.  Can we assume that in an optimized build that it's acceptable that code that use the inspect module and manipulates the f_locals of a frame may have surprising behavior in the face of optimization?  (e.g. I'd like to be able to optimize away locals if we can prove that absence of side-effects).

  - PyAST_obj2mod enforces checking for a particular top-level element.  To cope with this, I needed to pass this around in a few places, so I introduced "enum PyCompilationMode" to avoid having the magic 0, 1, or 2 to designate the grammar variant.  This better distinguishes these values from other places which use the ID of the start token: semantically equivalent, but with different constants.  I haven't yet fixed this up in Modules/parsermodule.c

  - Plenty of FIXMEs in the code, many of which are in themselves major issues
 
  - I'm not yet checking the optimization flag; that should probably be required to be on for this to be called.

  - Is "__optimizer__" a sane name?  perhaps just "optimizer"

  - Too unstable to benchmark as yet.

  - There are probably other issues I haven't thought of yet.

Notes:
  - the patch also contains a fix for issue 10391 (error handling is important when manipulating the AST)
  - potentially could add an optimize_cfg() hook, and expose the CFG struct basicblock and struct instr as Python objects in a similar way, as a later optimization pass
  
Thanks to Red Hat for giving me time to experiment on this

----------
components: Interpreter Core
files: py3k-ast-optimization-inlining-2010-11-12-001.patch
keywords: patch
messages: 121068
nosy: alex, belopolsky, benjamin.peterson, dmalcolm, jhylton, nnorwitz, rhettinger, sdahlbac, thomas.lee, titanstar
priority: normal
severity: normal
status: open
title: AST Optimization: inlining of function calls
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19583/py3k-ast-optimization-inlining-2010-11-12-001.patch

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

From report at bugs.python.org  Fri Nov 12 21:23:08 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 12 Nov 2010 20:23:08 +0000
Subject: [New-bugs-announce] [issue10400] updating unicodedata to Unicode 6
In-Reply-To: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>
Message-ID: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

I'd like to suggest updating the unicodedata module according to the recent Unicode standard 6.0
http://www.unicode.org/versions/Unicode6.0.0/
I'm sorry to bother, in case this is planned automatically, I just wasn't able to find the respective information.
Would it be possible to apply such update also for the upcomming python 2.7.1, or are there some showstoppers/incompatibilities... with regard to the new unicode version?
  regards,
      vbr

----------
components: Unicode
messages: 121070
nosy: vbr
priority: normal
severity: normal
status: open
title: updating unicodedata to Unicode 6
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/issue10400>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:24:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 21:24:40 +0000
Subject: [New-bugs-announce] [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>


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

Here is the Nth patch for a globals/builtins cache. As other caches at the same kind, it shows very small to no gain on non-micro benchmarks, showing that contrary to popular belief, globals/builtins lookup are not a major roadblock in today's Python performance.

However, this patch could be useful in combination with other optimizations such as issue10399.  Indeed, using the globals/builtins version id, it is easy and very cheap to detect whether the function pointed to by a global name has changed or not.

As for micro-benchmarks, they show that there is indeed a good improvement on builtins lookups:

$ ./python -m timeit "x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;"
-> without patch:
1000000 loops, best of 3: 0.282 usec per loop
-> with patch:
10000000 loops, best of 3: 0.183 usec per loop

----------
components: Interpreter Core
files: globcache5.patch
keywords: patch
messages: 121081
nosy: alex, belopolsky, benjamin.peterson, dmalcolm, jhylton, nnorwitz, pitrou, rhettinger, sdahlbac, thomas.lee, titanstar
priority: low
severity: normal
stage: patch review
status: open
title: Globals / builtins cache
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19590/globcache5.patch

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

From report at bugs.python.org  Sat Nov 13 01:51:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 00:51:37 +0000
Subject: [New-bugs-announce] [issue10402] sporadic test_bsddb3 failures
In-Reply-To: <1289609497.28.0.489511317462.issue10402@psf.upfronthosting.co.za>
Message-ID: <1289609497.28.0.489511317462.issue10402@psf.upfronthosting.co.za>


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

test_bsddb3 often produces the following failure under the Windows buildbots. It could probably be solved by choosing a larger timeout (time.time() on Windows is rather imprecise):

test test_bsddb3 failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_lock.py", line 139, in test04_lock_timeout2
    self.assertTrue((end_time-start_time) >= 0.0999)
AssertionError: False is not True

----------
assignee: jcea
components: Library (Lib), Tests
keywords: buildbot
messages: 121100
nosy: jcea, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sporadic test_bsddb3 failures
type: behavior
versions: Python 2.7

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

From marcorossi200489 at gmail.com  Sat Nov 13 01:40:30 2010
From: marcorossi200489 at gmail.com (Marco Rossi)
Date: Sat, 13 Nov 2010 01:40:30 +0100
Subject: [New-bugs-announce] (no subject)
Message-ID: <AANLkTindwskz1RdwTQoeHdw4pa2bHYBUE2m-v2d0hhn7@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20101113/dfdf4186/attachment.html>

From report at bugs.python.org  Sat Nov 13 05:37:22 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 13 Nov 2010 04:37:22 +0000
Subject: [New-bugs-announce] [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

Some portions of the documentation are using the term "member" to mean "data attribute".  This appears to be an aberration at this time, but occurrences should be identified and corrected, and "Documenting Python" updated to note correct usage.

Example use:

http://docs.python.org/dev/py3k/library/xmlrpc.client.html#fault-objects

http://docs.python.org/dev/py3k/library/urllib.request.html#basehandler-objects
(paragraph starting "The following members and methods should")

"Members and methods" should just be "attributes".

----------
assignee: docs at python
components: Documentation
messages: 121110
nosy: docs at python, fdrake
priority: normal
severity: normal
status: open
title: Use "member" consistently

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

From report at bugs.python.org  Sat Nov 13 09:39:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:39:23 +0000
Subject: [New-bugs-announce] [issue10404] IDLE on OS X popup menus do not
	work: cannot set/clear	breakpoints
In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>
Message-ID: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In several contexts, IDLE binds clicking of the right mouse button to context popup menus, most importantly, to provide the Set Breakpoint and Clear Breakpoint actions in edit windows.  On OS X systems, however, one cannot assume there will be more than one (e.g. the left) mouse button.  Further, Aqua Tk, the default on OS X, binds a right button if present to <Button-2>, rather than <Button-3> as with other Tk implementations and ignores <Button-3> bindings.  The net effect is that there is currently no way to use IDLE's breakpoint facility with Aqua Tk, with or without a multi-button mouse.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 121118
nosy: ned.deily, ronaldoussoren
priority: critical
severity: normal
stage: patch review
status: open
title: IDLE on OS X popup menus do not work: cannot set/clear breakpoints
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov 13 09:54:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:54:34 +0000
Subject: [New-bugs-announce] [issue10405] IDLE breakpoint facility
	undocumented
In-Reply-To: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>
Message-ID: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In neither the IDLE section of the Library Reference nor in IDLE's own help file is there any documentation on how to use its breakpoint capability.  Since the menu options only appear if the user knows to Right-click (or Control-click on OS X - see issue10404), it would be easy for a user to never realize that the breakpoint capability exists.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 121121
nosy: docs at python, kbk, ned.deily, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE breakpoint facility undocumented
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov 13 10:26:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 09:26:42 +0000
Subject: [New-bugs-announce] [issue10406] IDLE 2.7 on OS X does not enable
	Rstrip extension by	default
In-Reply-To: <1289640402.26.0.448285710534.issue10406@psf.upfronthosting.co.za>
Message-ID: <1289640402.26.0.448285710534.issue10406@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

r73001 for Issue5150 added the Rstrip extension to IDLE and modified the extensions configuration file, config-extensions.def, to enable it by default.  For Python 2 OS X installs, however, the config-extensions.def file from Lib/idlelib is replaced by a tailored one from Mac/IDLE and the changes for Issue5101 are lost.  The attached patch updates the Mac/IDLE version appropriately.  Note, for Python 3 installs, this is not a problem as there is no longer a separate Mac-only copy of the file.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 121123
nosy: Bruce.Sherwood, kbk, ned.deily, ronaldoussoren, taleinat
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE 2.7 on OS X does not enable Rstrip extension by default
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 13 15:06:39 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 13 Nov 2010 14:06:39 +0000
Subject: [New-bugs-announce] [issue10407] missing errno import in
	distutils/dir_util.py
In-Reply-To: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>
Message-ID: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

Fix is trivial:
diff -r 8daacdacf720 -r 1a821081b470 Lib/distutils/dir_util.py
--- a/Lib/distutils/dir_util.py Sat Nov 13 13:27:49 2010 +0100
+++ b/Lib/distutils/dir_util.py Sat Nov 13 14:37:49 2010 +0100
@@ -5,6 +5,7 @@
 __revision__ = "$Id: dir_util.py 86244 2010-11-06 04:48:05Z eric.araujo $"
 
 import os, sys
+import errno
 from distutils.errors import DistutilsFileError, DistutilsInternalError
 from distutils import log

----------
assignee: tarek
components: Distutils
messages: 121137
nosy: eric.araujo, tarek, zbysz
priority: normal
severity: normal
status: open
title: missing errno import in distutils/dir_util.py
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 13 15:48:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 14:48:12 +0000
Subject: [New-bugs-announce] [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>


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

This is a patch experiment which does two things:
- make dicts denser by making the resize factor 2 instead of 4 for small dicts
- improve cache locality on collisions by using linear probing

It should be noted that these two changes are not independent. Improving cache locality on collisions makes probing cheaper, and in turn should allow to make small dicts denser.

Linear probing is motivated by the fact that collisions can happen frequently.  The comments in dictobject.c seem a bit mistaken:

?If we *usually* find the key we're looking for on the first try (and, it turns out, we usually do -- the table load factor is kept under 2/3, so the odds are solidly in our favor), then it makes best sense to keep the initial index computation dirt cheap.?

According to http://www.cse.ust.hk/~yike/pods10-hashing.pdf, however, things are not so rosy. The average number of probes for successful lookups, depending on the load factor "alpha", is given by:

>>> c = lambda alpha: 0.5 * (1 + 1/(1-alpha))

while the average number of probes for unsuccessful lookups is:

>>> cp = lambda alpha: 0.5 * (1 + 1/(1-alpha)**2)

(note: this is with a perfectly random hash function; I intuitively assume an imperfect random function gives higher figures)

For a load factor of 2/3, we then get:

>>> c(2/3)
1.9999999999999998
>>> cp(2/3)
4.999999999999999

Since the current non-linear probing schemes guarantees that each probing will access a different cache line, the cache locality of a lookup becomes very poor.

The problem with linear probing, as noted in the comments, is that it degrades performance quite a lot when the hashing function clusters results. The solution I'm proposing is to apply an *initial* perturbation, by multiplying the hash() with a prime number. Multiplication is very fast on modern CPUs, so this doesn't adversely affect performance.

----------
components: Interpreter Core
files: dictopts.patch
keywords: patch
messages: 121139
nosy: mark.dickinson, pitrou, rhettinger, tim_one
priority: normal
severity: normal
status: open
title: Denser dicts and linear probing
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19595/dictopts.patch

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

From report at bugs.python.org  Sat Nov 13 16:31:11 2010
From: report at bugs.python.org (Stein Magnus Jodal)
Date: Sat, 13 Nov 2010 15:31:11 +0000
Subject: [New-bugs-announce] [issue10409] mkcfg crashes with ValueError
In-Reply-To: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>
Message-ID: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>


New submission from Stein Magnus Jodal <stein.magnus at jodal.no>:

I'm using Distutils2 1.0a3 with Python 2.6.6.


To reproduce:

1. Run ``python -m distutils2.mkcfg``
2. When you get to the Trove classifier step enter e.g. "Apache 2" as license
3. When asked to select a matching license, enter something else than a number, e.g. "Apache"
4. mkcfg crashes with a ValueError


Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 415, in <module>
    main()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 409, in main
    program.query_user()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 242, in query_user
    self.set_classifier()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 254, in set_classifier
    self.set_license(self.classifiers)
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 319, in set_license
    foundIndex = foundList[int(troveLicense) - 1]
ValueError: invalid literal for int() with base 10: 'Apache'

----------
assignee: tarek
components: Distutils2
messages: 121142
nosy: eric.araujo, jodal, tarek
priority: normal
severity: normal
status: open
title: mkcfg crashes with ValueError
versions: 3rd party

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

From report at bugs.python.org  Sat Nov 13 20:18:28 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 13 Nov 2010 19:18:28 +0000
Subject: [New-bugs-announce] [issue10410] Is iterable a container type?
In-Reply-To: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>
Message-ID: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

In http://docs.python.org/release/2.6.6/glossary.html, "iterable" is described as
"A container object capable of returning its members one at a time."
Is it correct? Is stream object like file a container type?

Container ABC requires only "__contains__" abstract method. I think file
is iterable but is not container.

Likewise, "and objects of any classes you define with an __iter__() or
__getitem__() method." is wrong because __getitem__ method is not relate to
iterable.

----------
assignee: docs at python
components: Documentation
messages: 121152
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Is iterable a container type?
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Nov 14 00:00:37 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 23:00:37 +0000
Subject: [New-bugs-announce] [issue10411] Pickle benchmark fails after
	converting Benchmark Suite	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

After checking out and converting the benchmark suite to py3k, the py3k benchmark set fails because of an ImportError in bm_pickle.py.  

Steps to reproduce:
hg clone http://hg.python.org/benchmarks/ py2benchmarks
mkdir py3benchmarks
cd py3benchmarks
../py2benchmarks/make_perf3.sh ../py2benchmarks
py3k perf.py -f -b py3k old_py3k new_py3k

The ImportError comes from the new py2k/ py3k compatibility code. bm_pickle imports "long" from compat.py. However, when 2to3 is run, it changes the import line from saying "import ... long" to saying "import ... int", which fails because compat.py does not define "int".

Is this a bug in lib2to3? I would not expect names used as lvalues to get converted. I'm using lib2to3 from python 2.6.5.

A similar case is that the line
    unicode = str
in compat.py gets changed by 2to3 to:
    str = str
This isn't currently causing any problems because no one is trying to import "unicode" from compat, but if they did, they would fail on py3k.

Regardless, a patch is attached that fixes bm_pickle by using "int_" as the name for our typedef instead of "long".

----------
assignee: collinwinter
components: Benchmarks
files: compat.patch
keywords: patch
messages: 121154
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Pickle benchmark fails after converting Benchmark Suite to py3k
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19598/compat.patch

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

From report at bugs.python.org  Sun Nov 14 00:55:38 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 23:55:38 +0000
Subject: [New-bugs-announce] [issue10412] Add py3k support for "slow" pickle
	benchmark in	Benchmark Suite
In-Reply-To: <1289692538.69.0.952593194282.issue10412@psf.upfronthosting.co.za>
Message-ID: <1289692538.69.0.952593194282.issue10412@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

A patch is attached that does the following:
1) Add py3k support for the "slow" (pure-Python) pickle/ unpickle benchmarks.
2) Add a runtime check to the pickle benchmark verifying that we do or don't have the C accelerators as expected.
3) Rename the cPickle versions to "fastpickle"/ "fastunpickle" and add a group called "pickle" that contains all of the pickling benchmarks.
4) Add the "pickle" benchmark group to the py3k and 2n3 groups.

----------
assignee: collinwinter
components: Benchmarks
files: slowpickle.patch
keywords: patch
messages: 121167
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Add py3k support for "slow" pickle benchmark in Benchmark Suite
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19600/slowpickle.patch

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

From report at bugs.python.org  Sun Nov 14 01:34:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 14 Nov 2010 00:34:16 +0000
Subject: [New-bugs-announce] [issue10413] Comments in unicode.h are out of
	date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch updates some comments in unicode.h mostly reflecting the fact that the default encoding is now unconditionally UTF-8.

----------
assignee: belopolsky
components: Documentation, Interpreter Core
files: unicode-comments.diff
keywords: patch
messages: 121168
nosy: belopolsky, haypo, lemburg, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Comments in unicode.h are out of date
versions: Python 3.2
Added file: http://bugs.python.org/file19601/unicode-comments.diff

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

From report at bugs.python.org  Sun Nov 14 05:35:18 2010
From: report at bugs.python.org (david)
Date: Sun, 14 Nov 2010 04:35:18 +0000
Subject: [New-bugs-announce] [issue10414] socket.gethostbyname doesn't
	return an ipv6 address
In-Reply-To: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za>
Message-ID: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

(socket.gethostbyname  doesn't return an ipv6 address)
So just to start with I know the documentation says [0] "and getaddrinfo() should be used instead for IPv4/v6 dual stack support."
However, the getaddrinfo() method provides more information than required. Why can't getaddrinfo support ipv6 ? or a method for ipv6 added to the socket module to make getting a host address by name easier (for ipv6) ? 



[0] - http://docs.python.org/library/socket.html#socket.gethostbyname

----------
messages: 121174
nosy: db
priority: normal
severity: normal
status: open
title: socket.gethostbyname  doesn't return an ipv6 address

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

From report at bugs.python.org  Sun Nov 14 08:12:14 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sun, 14 Nov 2010 07:12:14 +0000
Subject: [New-bugs-announce] [issue10415] readline.insert_text documentation
	incomplete
In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>
Message-ID: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>


New submission from Justin Lebar <justin.lebar at gmail.com>:

The readline documentation currently says:

> readline.insert_text(string)
>     Insert text into the command line.

But as far as I can tell, readline.insert_text() does something only when called from startup_hook or pre_input_hook.

Here's an example of someone using the module in a way that works:

http://swapoff.org/svn/cly/tags/0.7/cly/interactive.py

----------
assignee: docs at python
components: Documentation
messages: 121178
nosy: Justin.Lebar, docs at python
priority: normal
severity: normal
status: open
title: readline.insert_text documentation incomplete
versions: Python 3.1

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

From report at bugs.python.org  Sun Nov 14 12:34:05 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 14 Nov 2010 11:34:05 +0000
Subject: [New-bugs-announce] [issue10416] UnicodeDecodeError when 2to3 is
	run on a dir with numpy	.npy files
In-Reply-To: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>
Message-ID: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

1. 2to3 should work only only files ending with '.py', but it takes
   anything which has a dot and ends with 'py'. I'm having trouble
   with numpy .npy files.
2. 2to3 tries to decode the file and fails with traceback that is not useful:
   the name of the failing file is not given.

A patch is attached.

% ls *.npy|head -n1
S_18_7000_899811b572b309161cbb34f185b82fb618ed81da.npy

% 2to3-3.2 /usr/local/bin/2to3-3.2 .
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/local/bin/2to3-3.2", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/local/lib/python3.2/lib2to3/main.py", line 172, in main
    options.processes)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 699, in refactor
    items, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 294, in refactor
    self.refactor_dir(dir_or_file, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 313, in refactor_dir
    self.refactor_file(fullname, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 740, in refactor_file
    *args, **kwargs)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 335, in refactor_file
    input, encoding = self._read_python_source(filename)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 331, in _read_python_source
    return _from_system_newlines(f.read()), encoding
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x93 in position 0: invalid start byte

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: diff.diff
keywords: patch
messages: 121188
nosy: zbysz
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when 2to3 is run on a dir with numpy .npy files
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19605/diff.diff

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

From report at bugs.python.org  Sun Nov 14 14:04:51 2010
From: report at bugs.python.org (Johannes Ammon)
Date: Sun, 14 Nov 2010 13:04:51 +0000
Subject: [New-bugs-announce] [issue10417] unittest triggers
	UnicodeEncodeError with non-ASCII	character in the docstring
	of the test function
In-Reply-To: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>
Message-ID: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>


New submission from Johannes Ammon <johannes.ammon at gmail.com>:

When there is a non-ASCII character in the docstring of a test function, unittest triggers an UnicodeEncodeError when called with "--verbose".

I have this file unicodetest.py:
-----------------------------------------
# -*- coding: utf-8 -*-
import unittest

class UnicodeTest(unittest.TestCase):
    def test_unicode_docstring(self):
        u"""t?st - docstring with unicode character"""
        self.assertEqual(1+1, 2)

if __name__ == '__main__':
    unittest.main()
-----------------------------------------

Running it normally is ok:

$ python unicodetest.py 
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK


But with "--verbose" it breaks:

$ python unicodetest.py --verbose
Traceback (most recent call last):
  File "unicodetest.py", line 10, in <module>
    unittest.main()
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 817, in __init__
    self.runTests()
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 861, in runTests
    result = testRunner.run(self.test)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 753, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 464, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 460, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 464, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 460, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 300, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 266, in run
    result.startTest(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 693, in startTest
    self.stream.write(self.getDescription(test))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128)


Found with Python 2.6 on MacOS X 10.6.4

----------
components: Tests, Unicode
messages: 121193
nosy: jammon
priority: normal
severity: normal
status: open
title: unittest triggers UnicodeEncodeError with non-ASCII character in the docstring of the test function
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov 14 15:13:34 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Nov 2010 14:13:34 +0000
Subject: [New-bugs-announce] [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

I downloaded Python 3.1.3rc1 this morning to do my civic duty of testing it. I don't know what I'm doing wrong, but for me, test_io hangs and never completed. I'm on OS X 10.6.5. I ran it with:

$ ./python.exe Lib/test/regrtest.py test_io

And I got:

test_io

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
<hangs at this point>

I build Python with this configuration:

$ ./configure --enable-universalsdk=/ --enable-framework --with-universal-archs=intel

Oh, and it's being run as 64-bit.
By looking at the size being allocated, by guess that it's some kind of overflow thing or something.

----------
components: Tests
messages: 121194
nosy: vdupras
priority: release blocker
severity: normal
status: open
title: test_io hangs on 3.1.3rc1
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Sun Nov 14 21:32:33 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 14 Nov 2010 20:32:33 +0000
Subject: [New-bugs-announce] [issue10419] distutils command build_scripts
	fails with	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

As suggested in issue 9561, I'm creating a new bug for the encoding problem in build_scripts: If a script file can't be decoded with the (locale dependent) standard encoding, then "build_scripts" fails with UnicodeDecodeError. Reproducable e.g. with LANG=C and a script file containing non ASCII chars near the beginning (so that they're read on a single readline()).

Attaching a patch that uses "surrogateescape", as proposed for issue 6011.

----------
assignee: tarek
components: Distutils
files: surrogateescape.patch
keywords: patch
messages: 121207
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: distutils command build_scripts fails with UnicodeDecodeError
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19607/surrogateescape.patch

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

From report at bugs.python.org  Mon Nov 15 00:01:14 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 14 Nov 2010 23:01:14 +0000
Subject: [New-bugs-announce] [issue10420] Document of Bdb.effective is wrong.
In-Reply-To: <1289775674.64.0.742644713798.issue10420@psf.upfronthosting.co.za>
Message-ID: <1289775674.64.0.742644713798.issue10420@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/bdb.html#bdb.effective

>Determine if there is an effective (active) breakpoint at this line of code.
>Return breakpoint number or 0 if none.

bdb.effective doesn't return 0. If no breakpoint is found, it returns
(None, None).

----------
assignee: docs at python
components: Documentation
messages: 121211
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Document of Bdb.effective is wrong.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 15 00:30:46 2010
From: report at bugs.python.org (admin)
Date: Sun, 14 Nov 2010 23:30:46 +0000
Subject: [New-bugs-announce] [issue10421] Failed issue tracker submission
In-Reply-To: <20101114233044.91B391DB89@psf.upfronthosting.co.za>
Message-ID: <20101114233044.91B391DB89@psf.upfronthosting.co.za>


New submission from admin <roundup-admin at psf.upfronthosting.co.za>:

You are not a registered user.

Unknown address: Order Real Pfizer <tracker at psf.upfronthosting.co.za>

----------
files: unnamed
messages: 121212
nosy: admin
priority: normal
severity: normal
status: open
title: Failed issue tracker submission
Added file: http://bugs.python.org/file19609/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10421>
_______________________________________
-------------- next part --------------
Return-Path: <tracker at psf.upfronthosting.co.za>
X-Original-To: tracker at psf.upfronthosting.co.za
Delivered-To: tracker at psf.upfronthosting.co.za
Received: from [190.232.74.29] (unknown [190.232.74.29])
	by psf.upfronthosting.co.za (Postfix) with ESMTP id 911921DE56
	for <tracker at psf.upfronthosting.co.za>; Mon, 15 Nov 2010 00:30:42 +0100 (CET)
From: "Order Real Pfizer <tracker at psf.upfronthosting.co.za>
To: tracker at psf.upfronthosting.co.za
Reply-To: tracker at psf.upfronthosting.co.za
Subject: Hi tracker, Best Deals. of advent were
Mime-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20101114233043.911921DE56 at psf.upfronthosting.co.za>
Date: Mon, 15 Nov 2010 00:30:42 +0100 (CET)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Newsletter</title>
</head>
<body>
<table width="650" cellspacing="0" cellpadding="0" bgcolor="#F2F2F2" align="center">
	<tr>
    	<td height="52" style="text-align:center;">
		<span style="color:#464646; font-size:10px; font-family:arial, helvetica, sans-serif;">View <a href="http://youve.demedics.ru/?94e8CA7dE5856" style="color:#0093D9;">Mobile</a> | View
		<a href="http://ado.demedics.ru/?23ed94aB61C" style="color:#0093D9;">Webpage</a></span></td>
    </tr>
    <tr>
    	<td>
        	<table width="600" bgcolor="#FFFFFF" cellspacing="0" cellpadding="0" align="center">
            	<tr>
                	<td style="text-align: center">
                    	<a href="http://ho.demedics.ru/?be6b30bBAD37E">
                    	<img alt="Cheapest Pills. Click here" src="http://b.demedics.ru/vue.jpg" style="border-width: 0px"></a></td>
                </tr>
			</table>
            <table width="600" bgcolor="#F2F2F2" cellspacing="0" cellpadding="0" align="center">
                <tr>
                	<td height="27"> </td>
                </tr>
            	<tr>
   	  				<td align="left">
                        <font color="#A2A2A2" face="arial, helvetica, sans-serif" size="1">
                        	PLEASE DO NOT REPLY TO THIS MESSAGE.<br>
                        	This is a system-generated Newsletter email. Replies will not be read or forwarded for handling.<br><br>
                        This message was sent to tracker at psf.upfronthosting.co.za.<br><br>
                            <a href="http://lelim.demedics.ru/?4855711607" style="color:#817979;">Contact Us</a> |
                            <a href="http://yn.demedics.ru/?3B3d0AeC42ba61&remove=tracker at psf.upfronthosting.co.za" style="color:#817979;">Unsubscribe</a> |
                            <a href="http://iibe.demedics.ru/?969972df718296E4" style="color:#817979;">Update Email Address</a> |
                            <a href="http://pele.demedics.ru/?08D96a30dEf400B7" style="color:#817979;">Privacy Policy</a><br><br>
                            Copyright 2010 leadership of Warrior. All rights reserved.
                        </font>
                    </td>
                </table>
        </td>
    </tr>
</table>
<IMG SRC="http://www.hufisymawa.com/55f8dc5160986988F81ca99e7f7C6fb6e15380bAA67AB"></body>
</html>

From report at bugs.python.org  Mon Nov 15 09:42:30 2010
From: report at bugs.python.org (Stephane Ruchet)
Date: Mon, 15 Nov 2010 08:42:30 +0000
Subject: [New-bugs-announce] [issue10422] pstats.py : error when loading
	multiple stats files
In-Reply-To: <1289810550.6.0.241071976053.issue10422@psf.upfronthosting.co.za>
Message-ID: <1289810550.6.0.241071976053.issue10422@psf.upfronthosting.co.za>


New submission from Stephane Ruchet <sruchet at parkeon.com>:

When using pstats constructor with multiple files, the add_callers method fails. Actually, add_callers need to add values of tuples, but it uses the "+" operator, that appends tuples.

I submit the fix (pstats.py.fix file) and the old one (pstats.py.bug.2.5)

----------
components: Library (Lib)
files: pstats.zip
messages: 121216
nosy: sruchet
priority: normal
severity: normal
status: open
title: pstats.py : error when loading multiple stats files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file19611/pstats.zip

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

From report at bugs.python.org  Mon Nov 15 11:30:35 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 15 Nov 2010 10:30:35 +0000
Subject: [New-bugs-announce] [issue10423] s/args/options in arpgarse
	"Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From a personal email:

----------------------------------------------------------------------
I'm not signed up for all the Python issue tracking stuff, but thought I'd let you know about a problem with the argparse doc page:

     http://docs.python.org/library/argparse.html

It says at the end:

     Replace options, args = parser.parse_args() with args = parser.parse_args() and add additional ArgumentParser.add_argument() calls for the positional arguments.

But I think it should be options = parser.parse_args(), not args.
----------------------------------------------------------------------

They're not options, so I don't like encouraging people to continue to call them options, but the docs should at least make clear that the namespace object that used to be called "options" is now called "args".

----------
assignee: docs at python
components: Documentation
messages: 121219
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: s/args/options in arpgarse "Upgrading optparse code"
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 15 11:38:44 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 15 Nov 2010 10:38:44 +0000
Subject: [New-bugs-announce] [issue10424] better error message from argparse
	when positionals	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From a private email in respect to the following class of error messages:

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--foo')
>>> parser.add_argument('--bar')
>>> parser.add_argument('ham')
>>> parser.add_argument('spam', nargs='+')
>>> parser.parse_args(['HAM'])
usage: PROG [-h] [--foo FOO] [--bar BAR] ham spam [spam ...]
PROG: error: too few arguments

----------------------------------------------------------------------
One suggestion would be that when it displays the error "too few arguments", it would nice if it said something about the argument(s) that are missing.

I modified argparse's error message when there are too few arguments.  I didn't examine the code a lot, so there might be cases where this doesn't work, but here's what I did:

    if positionals:
        self.error(_('too few arguments: %s is required' % positionals[0].dest))
----------------------------------------------------------------------

This would be a nice feature - I haven't checked if the suggested approach works in general though.

----------
components: Library (Lib)
messages: 121220
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: better error message from argparse when positionals missing
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 15 13:27:17 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Mon, 15 Nov 2010 12:27:17 +0000
Subject: [New-bugs-announce] [issue10425] xmlrpclib support for None isn't
	compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>


New submission from Adam Biela?ski <abgans at gmail.com>:

XMLRPC standard doesn't support None/nil/null values. Element `<nil/>` was added as an extension to original protocol.

Currently sending None object through xmlrpclib produces `<value><nil/></value>` string. This causes parsing errors in more sophisticated XMLRPC parsers (like org.apache.xmlrpc for Java) which require `<nil/>` element to be declared in namespace for extensions: xmlns:ex='http://ws.apache.org/xmlrpc/namespaces/extensions'

Attached patch makes xmlrpclib use that namespace for sending None values both in method calls and responses, so None value might be passed both ways. It isn't bound to use fixed prefix for extensions namespace and it also parses XML produced by original xmlrpclib (without any namespace at all), so it is backward compatible.

It does its job communicating with org.apache.xmlrpc library now, using default parser on the Python side which is an improvement to original version, so I'd like to see it included in the next Python 2.x release, if possible.

----------
components: Library (Lib), XML
files: xmlrpclib.diff
keywords: patch
messages: 121224
nosy: Adam.Biela?ski
priority: normal
severity: normal
status: open
title: xmlrpclib support for None isn't compliant with XMLRPC
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19612/xmlrpclib.diff

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

From report at bugs.python.org  Mon Nov 15 15:06:58 2010
From: report at bugs.python.org (Joshua Purcell)
Date: Mon, 15 Nov 2010 14:06:58 +0000
Subject: [New-bugs-announce] [issue10426] The whole thing is NOT good
In-Reply-To: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>
Message-ID: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>


New submission from Joshua Purcell <spamail.08jpurcellserver at gmail.com>:

There is a complete FAIL in this versionand all other versions like 3.*
THEY ALL FREEZE UP MY SYSTEM (Windows) HELP

----------
components: Windows
messages: 121227
nosy: 08jpurcell
priority: normal
severity: normal
status: open
title: The whole thing is NOT good
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 15 15:38:00 2010
From: report at bugs.python.org (ingo janssen)
Date: Mon, 15 Nov 2010 14:38:00 +0000
Subject: [New-bugs-announce] [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>


New submission from ingo janssen <ingoogni at gmail.com>:

Short:
make the DateTime class and related also accept 24 for the hour instead of stopping at 23:59:59.

from the python doc:

"class datetime.datetime(year, month, day[, hour[, minute[, second[,
microsecond[, tzinfo]]]]])
The year, month and day arguments are required. tzinfo may be None, or
an instance of a tzinfo subclass. The remaining arguments may be ints
or longs, in the following ranges:
[...]
0 <= hour < 24
[...]
If an argument outside those ranges is given, ValueError is raised."


from http://en.wikipedia.org/wiki/ISO_8601 :

"ISO 8601 uses the 24-hour clock system. The basic format is
[hh][mm][ss] and the extended format is [hh]:[mm]:[ss].

* [hh] refers to a zero-padded hour between 00 and 24 (where 24 is
only used to notate midnight at the end of a calendar day).
[...]
Midnight is a special case and can be referred to as both "00:00" and
"24:00". The notation "00:00" is used at the beginning of a calendar
day and is the more frequently used. At the end of a day use "24:00".
Note that "2007-04-05T24:00" is the same instant as "2007-04-06T00:00"
(see Combined date and time representations below)."

The use of 24:00 is very comfortable when using hourly datasets, the
first set of a day is saved under 1:00, the fifth (4:00 to 5:00) under
5:00 and the last (23:00 - 24:00) under 24:00. No need to suddenly use
23:59:59 or 0:00 the next day. 

Actually in another part of Python SQLlite's date and time functions accept and outputs the 24:00. Adding some Python to an existing database made me aware of the problem.

----------
messages: 121230
nosy: ingo.janssen
priority: normal
severity: normal
status: open
title: 24:00 Hour in DateTime
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 15 21:49:51 2010
From: report at bugs.python.org (Eli)
Date: Mon, 15 Nov 2010 20:49:51 +0000
Subject: [New-bugs-announce] [issue10428] IDLE Trouble shooting
In-Reply-To: <1289854191.01.0.577719650425.issue10428@psf.upfronthosting.co.za>
Message-ID: <1289854191.01.0.577719650425.issue10428@psf.upfronthosting.co.za>


New submission from Eli <eliandkatie at acsalaska.net>:

I am having trouble with python. I use python 2.5.1, and have windows 7.
I used to be able to use IDLE, but now it says its opening and it never does. I also could use recovery to fix it. but that does not work now. Any Ideas?

----------
components: Windows
messages: 121240
nosy: creat0r
priority: normal
severity: normal
status: open
title: IDLE Trouble shooting
versions: Python 2.5

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

From report at bugs.python.org  Tue Nov 16 01:09:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Nov 2010 00:09:13 +0000
Subject: [New-bugs-announce] [issue10429] bug in test_imaplib
In-Reply-To: <1289866153.11.0.678652692288.issue10429@psf.upfronthosting.co.za>
Message-ID: <1289866153.11.0.678652692288.issue10429@psf.upfronthosting.co.za>


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

The following warning suggests the test is wrong:

c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_imaplib.py:231: BytesWarning: Comparison between bytes and string
  self.assertFalse('LOGINDISABLED' in self.server.capabilities)

----------
assignee: pitrou
components: Library (Lib), Tests
messages: 121255
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bug in test_imaplib
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 16 08:36:55 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 16 Nov 2010 07:36:55 +0000
Subject: [New-bugs-announce] [issue10430] _sha.sha().digest() method is
	endian-sensitive. and	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

in shamodule.c, the digest() method just creates a simple bytes string of the digest.  The digest is stored as an array of 32 bit integers in the native representation.  Therefore, the digest will be different on big-  and little-endian machines.

The specification (http://en.wikipedia.org/wiki/SHA-1) suggest that the digest should actually be big endian, so the standard implementation on most home machines is actually wrong

Actually, looking at the code, hexdigest() has the same problem!

----------
components: Extension Modules
messages: 121268
nosy: krisvale
priority: normal
severity: normal
status: open
title: _sha.sha().digest() method is endian-sensitive. and hexdigest()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 16 10:56:04 2010
From: report at bugs.python.org (admin)
Date: Tue, 16 Nov 2010 09:56:04 +0000
Subject: [New-bugs-announce] [issue10431] Failed issue tracker submission
In-Reply-To: <20101116095559.EA25110402E@psf.upfronthosting.co.za>
Message-ID: <20101116095559.EA25110402E@psf.upfronthosting.co.za>


New submission from admin <roundup-admin at psf.upfronthosting.co.za>:

You are not a registered user.

Unknown address: Order Real Pfizer <report at bugs.python.org>

----------
files: unnamed
messages: 121278
nosy: admin
priority: normal
severity: normal
status: open
title: Failed issue tracker submission
Added file: http://bugs.python.org/file19614/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10431>
_______________________________________
-------------- next part --------------
Return-Path: <report at bugs.python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from [123.26.137.99] (unknown [123.26.137.99])
	by psf.upfronthosting.co.za (Postfix) with ESMTP id F017410402D
	for <report at bugs.python.org>; Tue, 16 Nov 2010 10:55:58 +0100 (CET)
From: "Order Real Pfizer <report at bugs.python.org>
To: report at bugs.python.org
Reply-To: report at bugs.python.org
Subject: Hi report, Best Deals. one In largest In Forum
Mime-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20101116095558.F017410402D at psf.upfronthosting.co.za>
Date: Tue, 16 Nov 2010 10:55:58 +0100 (CET)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Newsletter</title>
</head>
<body>
<table width="650" cellspacing="0" cellpadding="0" bgcolor="#F2F2F2" align="center">
	<tr>
    	<td height="52" style="text-align:center;">
		<span style="color:#464646; font-size:10px; font-family:arial, helvetica, sans-serif;">View <a href="http://xeqiyb.medicsri.ru/?BaBed4D4FF59d198F" style="color:#0093D9;">Mobile</a> | View
		<a href="http://wuren.medicsri.ru/?5262b3319Cb9cc94" style="color:#0093D9;">Webpage</a></span></td>
    </tr>
    <tr>
    	<td>
        	<table width="600" bgcolor="#FFFFFF" cellspacing="0" cellpadding="0" align="center">
            	<tr>
                	<td style="text-align: center">
                    	<a href="http://ke.medicsri.ru/?8bb7A4a93d3eEc">
                    	<img alt="Cheapest Pills. Click here" src="http://b.medicsri.ru/osaa.jpg" style="border-width: 0px"></a></td>
                </tr>
			</table>
            <table width="600" bgcolor="#F2F2F2" cellspacing="0" cellpadding="0" align="center">
                <tr>
                	<td height="27"> </td>
                </tr>
            	<tr>
   	  				<td align="left">
                        <font color="#A2A2A2" face="arial, helvetica, sans-serif" size="1">
                        	PLEASE DO NOT REPLY TO THIS MESSAGE.<br>
                        	This is a system-generated Newsletter email. Replies will not be read or forwarded for handling.<br><br>
                        This message was sent to report at bugs.python.org.<br><br>
                            <a href="http://neaova.medicsri.ru/?B9FC632154FE73F1" style="color:#817979;">Contact Us</a> |
                            <a href="http://upejem.medicsri.ru/?40C41b61a8CB2&remove=report at bugs.python.org" style="color:#817979;">Unsubscribe</a> |
                            <a href="http://ezaha.medicsri.ru/?794148936577" style="color:#817979;">Update Email Address</a> |
                            <a href="http://kyewoc.medicsri.ru/?F1F19646a5441" style="color:#817979;">Privacy Policy</a><br><br>
                            Copyright 2010 The For. All rights reserved.
                        </font>
                    </td>
                </table>
        </td>
    </tr>
</table>
<IMG SRC="http://www.quawysuqoeg.com/07006aefAd4E8DD6f6d6C99806dC48C"></body>
</html>

From report at bugs.python.org  Tue Nov 16 11:59:36 2010
From: report at bugs.python.org (Scott Dial)
Date: Tue, 16 Nov 2010 10:59:36 +0000
Subject: [New-bugs-announce] [issue10432] concurrent.futures.as_completed()
	spins waiting for	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>


New submission from Scott Dial <scott at scottdial.com>:

The code in as_completed() waits on a FIRST_COMPLETED event, which means that after the first future completes, it will no longer wait at all. The proposed patch adds a _AsCompletedWaiter and uses a lock to swap out the finished list and reset the event.

This is a difficult problem to create a test case for without adding intrusive code to as_completed() to count how many times it loops or create a mock Event object that counts it, so I have not proposed a test.

----------
components: Library (Lib)
files: futures-r86476.patch
keywords: patch
messages: 121280
nosy: scott.dial
priority: normal
severity: normal
status: open
title: concurrent.futures.as_completed() spins waiting for futures to complete
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19615/futures-r86476.patch

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

From report at bugs.python.org  Tue Nov 16 15:06:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 14:06:07 +0000
Subject: [New-bugs-announce] [issue10433] Document unique behavior of
	'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>


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

Per issue 7900, os.getgroups on OSX does not behave the same way as on any other unix platform.  This seems worthy of a documentation note, since anyone trying to write portable code could get bit by this.

I don't really understand the relationship on OSX between what the current os.getgroups returns, what the normal unix os.getgroups returns, and what things a process can actually *do*, so I can't write that documentation.  Hopefully someone else can.

A doc note is probably also needed about the relationship between os.setgroups and os.getgroups on OSX, which again I do not understand and so cannot write.

----------
messages: 121293
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unique behavior of 'getgroups' on OSX
type: behavior

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

From report at bugs.python.org  Tue Nov 16 15:55:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 14:55:38 +0000
Subject: [New-bugs-announce] [issue10434] Document the rules for "public
	names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As discussed in "Breaking undocumented API" thread [1] on python-dev,  a definition of "public names" is buried deep in the language reference manual:

"""
The public names defined by a module are determined by checking the
module?s namespace for a variable named __all__; if defined, it must
be a sequence of strings which are names defined or imported by that
module. The names given in __all__ are all considered public and are
required to exist. If __all__ is not defined, the set of public names
includes all names found in the module?s namespace which do not begin
with an underscore character ('_'). __all__ should contain the entire
public API. It is intended to avoid accidentally exporting items that
are not part of the API (such as library modules which were imported
and used within the module).
"""  [2]

It has been argued that this is not the authoritative definition and alternatives have been suggested such as "any name that does not begin with an underscore except imported modules."
mportant for the users and developers of cpython and other python implementations to know what names they can rely upon to stay defined between releases, the rules for "public names" should be documented.

I agree that the library manual is a more appropriate place for such documentation.  The definition should include the naming conventions and the set of promises that Python makes about public name availability in the future releases.


[1] http://mail.python.org/pipermail/python-dev/2010-November/105490.html
[2] http://docs.python.org/reference/simple_stmts.html

----------
assignee: docs at python
components: Documentation
messages: 121297
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document the rules for "public names"
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 16 17:16:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 16:16:46 +0000
Subject: [New-bugs-announce] [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The following C-APIs are only documented in comments inside unicode.h:

PyUnicode_GetMax
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_FromOrdinal
PyUnicode_GetDefaultEncoding
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_EncodeDecimal
PyUnicode_Append
PyUnicode_AppendAndDel
PyUnicode_Partition
PyUnicode_RPartition
PyUnicode_RSplit
PyUnicode_IsIdentifier
Py_UNICODE_strlen
Py_UNICODE_strcpy
Py_UNICODE_strcat
Py_UNICODE_strncpy
Py_UNICODE_strcmp
Py_UNICODE_strncmp
Py_UNICODE_strchr
Py_UNICODE_strrchr

----------
assignee: belopolsky
components: Documentation
messages: 121302
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unicode C-API in reST
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 16 19:17:44 2010
From: report at bugs.python.org (David Nesting)
Date: Tue, 16 Nov 2010 18:17:44 +0000
Subject: [New-bugs-announce] [issue10436] tarfile.extractfile in "r|" stream
	mode fails with	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>


New submission from David Nesting <david at fastolfe.net>:

When opening a tarfile with mode "r|" (streaming mode), extractfile("filename") and extractfile(mytarfile.getmembers()[0]) raise "tarfile.StreamError: seeking backwards is not allowed".  extractfile(mytarfile.next()) succeeds.  A more complete test case:

"""
import tarfile
import StringIO

# Create a simple tar file in memory.  This could easily be a real tar file
# though.
data = StringIO.StringIO()
tf = tarfile.open(fileobj=data, mode="w")
tarinfo = tarfile.TarInfo(name="testfile")
filedata = StringIO.StringIO("test data")
tarinfo.size = len(filedata.getvalue())
tf.addfile(tarinfo, fileobj=filedata)
tf.close()
data.seek(0)

# Open as an uncompressed stream
tf = tarfile.open(fileobj=data, mode="r|")

#f = tf.extractfile("testfile")
#print "%s: %s" % (f.name, f.read())
#
#Traceback (most recent call last):
#  File "./bug.py", line 19, in <module>
#    print "%s: %s" % (f.name, f.read())
#  File "/usr/lib/python2.7/tarfile.py", line 815, in read
#    buf += self.fileobj.read()
#  File "/usr/lib/python2.7/tarfile.py", line 735, in read
#    return self.readnormal(size)
#  File "/usr/lib/python2.7/tarfile.py", line 742, in readnormal
#    self.fileobj.seek(self.offset + self.position)
#  File "/usr/lib/python2.7/tarfile.py", line 554, in seek
#    raise StreamError("seeking backwards is not allowed")
#tarfile.StreamError: seeking backwards is not allowed

#for member in tf.getmembers():
#  f = tf.extractfile(member)
#  print "%s: %s" % (f.name, f.read())
#
# Same traceback

while True:
  member = tf.next()
  if member is None:
    break
  f = tf.extractfile(member)
  print "%s: %s" % (f.name, f.read())

# This works.
"""

It appears that extractfile("filename") invokes getmember("filename"), which invokes getmembers().  getmembers() scans the entire file before returning results, and by doing so, it's read past and discarded the actual file data, which makes it impossible for us to actually extract it.

If this is accurate, this seems tricky to completely fix.  You could make getmembers() a generator that doesn't read too far ahead so that the file's contents are still available if someone wants to retrieve them for each file yielded.  getmember("filename") could just scan forward through the file until it hits a match, but you'd still lose the ability to do a getmember("filename") on a file that we skipped over.

If nothing else, document that extractfile("filename"), getmember() and getmembers() won't work reliably in streaming mode, and possibly raise an exception whenever someone tries just to make behavior consistent.

----------
components: Library (Lib)
messages: 121308
nosy: David.Nesting
priority: normal
severity: normal
status: open
title: tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers()
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Nov 16 20:36:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 16 Nov 2010 19:36:14 +0000
Subject: [New-bugs-announce] [issue10437] ThreadPoolExecutor should accept
	max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

ProcessPoolExecutor allows the max_workers parameter to the constructor to be omitted or None, in which case it will set the max_workers based on the number of CPUs.

It would be nice if ThreadPoolExecutor's constructor worked the same way; having the same interface is one of the wonderful things about this pair of classes.

I have a patch pretty much ready (with tests and a doc update), but it causes concurrent/futures/thread.py to import multiprocessing.  Were you trying to avoid that?

----------
assignee: stutzbach
components: Library (Lib)
messages: 121311
nosy: bquinlan, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: ThreadPoolExecutor should accept max_workers=None
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 16 21:23:32 2010
From: report at bugs.python.org (Ian)
Date: Tue, 16 Nov 2010 20:23:32 +0000
Subject: [New-bugs-announce] [issue10438] list an example for calling static
	methods from WITHIN	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>


New submission from Ian <ifreecarve at gmail.com>:

Concerning this section of the docs:
http://docs.python.org/library/functions.html#staticmethod

There is no example for calling a static method from another static method within the same class.

As I discovered later, it's simple: C.f() -- from inside the class or outside it.

A total newbie will accept this and move on... but in other programming languages, it's frowned upon to the class name from within the class.  For example, in PHP you use the "self::" prefix and Java you don't need a prefix at all.  

So, even though I had it right the first time, it didn't SEEM right... so I went on a wild goose chase, for nothing.  Googling "java call static method" will get you java documentation that lists both cases, as does "c++ call static method" and "php call static method".  

I feel that by adding "Note: you must also use the C.f() syntax when calling from within the class", the documentation will be more complete.

----------
assignee: docs at python
components: Documentation
messages: 121314
nosy: docs at python, ifreecarve
priority: normal
severity: normal
status: open
title: list an example for calling static methods from WITHIN classes
type: feature request

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

From report at bugs.python.org  Wed Nov 17 01:08:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 00:08:56 +0000
Subject: [New-bugs-announce] [issue10439] PyCodec C API is not documented in
	reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Python Codec Registry and support functions are well documented in codecs.h header file.  It should be easy to convert that to reST.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 121329
nosy: belopolsky, docs at python, haypo, lemburg, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: PyCodec C API is not documented in reST
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 17 05:59:48 2010
From: report at bugs.python.org (Robert Collins)
Date: Wed, 17 Nov 2010 04:59:48 +0000
Subject: [New-bugs-announce] [issue10440] support RUSAGE_THREAD as a
	constant in the resource	module
In-Reply-To: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>
Message-ID: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

RUSAGE_THREAD (since Linux 2.6.26)
              Return resource usage statistics for the calling thread.

This is very handy for multi threaded apps in determining runtime in a thread, page faults from the thread etc.

----------
messages: 121336
nosy: rbcollins
priority: normal
severity: normal
status: open
title: support RUSAGE_THREAD as a constant in the resource module
type: feature request

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

From report at bugs.python.org  Wed Nov 17 10:26:35 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 09:26:35 +0000
Subject: [New-bugs-announce] [issue10442] Please by default enforce ssl
	certificate checking in	modules that can have user's which
	*depend* on the security of	the ssl connection.
In-Reply-To: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>
Message-ID: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

See https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/675120
http://bugs.python.org/issue10274
http://bugs.python.org/issue1589

and http://seclists.org/oss-sec/2010/q4/33

So I will name the following modules(as a  starting point):
1. httplib http://docs.python.org/library/httplib.html
2. urllib http://docs.python.org/library/urllib.html
3. urllib2 http://docs.python.org/library/urllib2.html
4. imaplib http://docs.python.org/library/imaplib.html

----------
messages: 121338
nosy: db
priority: normal
severity: normal
status: open
title: Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

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

From report at bugs.python.org  Wed Nov 17 10:26:32 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 09:26:32 +0000
Subject: [New-bugs-announce] [issue10441] Please by default enforce ssl
	certificate checking in	modules that can have user's which
	*depend* on the security of	the ssl connection.
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

See https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/675120
http://bugs.python.org/issue10274
http://bugs.python.org/issue1589

and http://seclists.org/oss-sec/2010/q4/33

So I will name the following modules(as starting point):
1. httplib http://docs.python.org/library/httplib.html
2. urllib http://docs.python.org/library/urllib.html
3. urllib2 http://docs.python.org/library/urllib2.html
4. imaplib http://docs.python.org/library/imaplib.html

----------
messages: 121337
nosy: db
priority: normal
severity: normal
status: open
title: Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

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

From report at bugs.python.org  Wed Nov 17 13:04:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 12:04:48 +0000
Subject: [New-bugs-announce] [issue10443] add wrapper for
	SSL_CTX_set_default_verify_paths
In-Reply-To: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>
Message-ID: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>


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

SSL_CTX_set_default_verify_paths allows to select the system-wide CA certificates on an SSL context, if OpenSSL was built with the right options.

We could also try to expose those default paths by calling X509_get_default_cert_file() / X509_get_default_cert_dir(), but these seem even less documented (private?).

----------
components: Library (Lib)
messages: 121351
nosy: pitrou
priority: normal
severity: normal
status: open
title: add wrapper for SSL_CTX_set_default_verify_paths
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 17 15:04:21 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:04:21 +0000
Subject: [New-bugs-announce] [issue10444] A mechanism is needed to override
	waiting for Python	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>


New submission from Michael Hughes <michaelahughes at gmail.com>:

We use the Python interpreter embedded in our application, and would prefer to not block an exit of our application waiting for non-daemon threads to finish.

I would like a mechanism exposed that queries for whether or not to wait.

----------
components: Library (Lib)
messages: 121354
nosy: michaelahughes
priority: normal
severity: normal
status: open
title: A mechanism is needed to override waiting for Python threads to finish
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 17 15:15:28 2010
From: report at bugs.python.org (Emile Anclin)
Date: Wed, 17 Nov 2010 14:15:28 +0000
Subject: [New-bugs-announce] [issue10445] _ast py3k : add lineno back to
	"args" node
In-Reply-To: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za>
Message-ID: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za>


New submission from Emile Anclin <emile.anclin at logilab.fr>:

For Python3x, in the tree generated by _ast, for the "args" node (representing an argument of a function), the "lineno" (and the "col_offset") information disappeared from those nodes.

It would be nice to have them back (for instance for Pylint)

----------
components: None
messages: 121357
nosy: emile.anclin
priority: normal
severity: normal
status: open
title: _ast py3k : add lineno back to "args" node
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 17 18:32:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 17:32:23 +0000
Subject: [New-bugs-announce] [issue10446] pydoc3 links to 2.x library
	reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ pydoc3.1 pydoc

Help on module pydoc:

NAME
    pydoc - Generate Python documentation in HTML or text for interactive use.

FILE
    /opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pydoc.py

MODULE DOCS
    http://docs.python.org/library/pydoc

I suggest changing the default base URL to

http://docs.python.org/release/X.Y.Z

I would also like to take this opportunity and make some other improvements:

1. Clarify that the linked document is the authoritative reference and that generated documentation may expose functions that are considered internal and subject to change or removal.  (Suggestions for an exact wording are welcome.)

2. Move the FILE section to the end.  This will free up some screen space for an expanded "AUTHORITATIVE REFERENCE" section.  (Yes, I think the section title "MODULE DOCS" can be improved, but my mind is not set on any particular alternative.)

3. Do not include __special__ names in the DATA section.  At the very least, exclude __author__, __version__, and other special names that cause generation of document sections:

DATA
    __author__ = 'Ka-Ping Yee <ping at lfw.org>'
    __credits__ = 'Guido van Rossum, for an excellent programming l...erla...
    __date__ = '26 February 2001'
    __version__ = '$Revision: 78210 $'

VERSION
    78210

DATE
    26 February 2001
..

----------
assignee: belopolsky
components: Documentation, Library (Lib)
messages: 121365
nosy: belopolsky
priority: normal
severity: normal
status: open
title: pydoc3 links to 2.x library reference
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov 17 20:14:13 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 17 Nov 2010 19:14:13 +0000
Subject: [New-bugs-announce] [issue10447] zipfile: IOError for long
	directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

When extracting a zip file containing deep hierarchy files, `extractall` throws IOError on Windows - perhaps due to limitation in Windows max path length. Ideally it should be throwing an instance of zipfile.ZipError - so that application can handle it reliably. An IOError can mean a wide range of errors, so it is pointless to catch IOError and ignore it.

To reproduce, run extractall over http://pypi.python.org/packages/source/c/collective.generic.skel/collective.generic.skel-0.1.0.zip using Python 2.6.6 or Python 2.7

> python -c "import zipfile
; f=zipfile.ZipFile('collective.generic.skel-0.1.0.zip'); f.extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\zipfile.py", line 923, in extractall
    self.extract(zipinfo, path, pwd)
  File "C:\Python27\lib\zipfile.py", line 911, in extract
    return self._extract_member(member, path, pwd)
  File "C:\Python27\lib\zipfile.py", line 955, in _extract_member
    target = file(targetpath, "wb")
IOError: [Errno 2] No such file or directory: 'C:\\Documents and Settings\\apy\\
My Documents\\Downloads\\collective.generic.skel-0.1.0\\src\\collective\\generic
\\skel\\skin\\tmpl\\+namespace++ndot++nested_namespace+.+project_name+\\src\\+na
mespace+\\+nested_namespace+\\+project_name+\\profiles\\default\\+namespace++ndo
t++nested_namespace+.+project_name+_various.txt_tmpl'

----------
components: Library (Lib), Windows
messages: 121376
nosy: srid
priority: normal
severity: normal
status: open
title: zipfile: IOError for long directory paths on Windows
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Nov 17 20:23:07 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Wed, 17 Nov 2010 19:23:07 +0000
Subject: [New-bugs-announce] [issue10448] Add Mako template benchmark to
	Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

The Benchmark Suite currently contains two template benchmarks (Django and Spitfire) for Python 2.x, but none that support 3.x.

The attached patch adds a benchmark using Mako (http://www.makotemplates.org/), a popular, pure-Python, performance-oriented template system that supports both 2.x and 3.x via 2to3 conversion.

Mako is added to the "py3k" benchmark group and a new group called "template" with all three template benchmarks is added (that will only work on 2.x since it uses Django and Spitfire).

I added the Mako benchmark and lib to the lists in the README file and also updated the descriptions of the pickle benchmarks there since I had missed that before. Also fixed a path in there that was referring to perf.py as unladen-benchmarks/perf.py.

----------
assignee: collinwinter
components: Benchmarks
files: mako.patch
keywords: patch
messages: 121378
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Add Mako template benchmark to Python Benchmark Suite
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19628/mako.patch

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

From report at bugs.python.org  Thu Nov 18 00:41:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 23:41:52 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMTA0NDldIOKAnG9zLmVudmly?=
 =?utf-8?q?on_was_modified_by_test=5Fhttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Bug title is a warning I get when running test_httpservers under regrtest with 3.1.

----------
components: Tests
messages: 121393
nosy: eric.araujo, orsenthil
priority: low
severity: normal
stage: needs patch
status: open
title: ?os.environ was modified by test_httpservers?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Thu Nov 18 03:51:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:51:15 +0000
Subject: [New-bugs-announce] [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Misc/NEWS is supposed to be in reST, but there are at present markup errors.  Not sure if 3.1 and 2.7 should be fixed too.

----------
keywords: easy
messages: 121428
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix markup in Misc/NEWS
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 18 08:18:17 2010
From: report at bugs.python.org (Evgeny Kapun)
Date: Thu, 18 Nov 2010 07:18:17 +0000
Subject: [New-bugs-announce] [issue10451] memoryview can be used to write
	into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

This code crashes Python:

import io, mmap
io.BytesIO(b' ').readinto(memoryview(mmap.mmap(-1, 1, prot=mmap.PROT_READ)))

----------
components: Interpreter Core
messages: 121446
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: memoryview can be used to write into readonly buffer
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Nov 18 13:30:12 2010
From: report at bugs.python.org (Raphael Mankin)
Date: Thu, 18 Nov 2010 12:30:12 +0000
Subject: [New-bugs-announce] [issue10452] Unhelpful diagnostic 'cannot find
	the path specified'
In-Reply-To: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>
Message-ID: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>


New submission from Raphael Mankin <raph at mankin.org.uk>:

Something somewhere in the library issues the diagnostic 'The system cannot find the path specified' with no indication of what path it was looking for nor where the error was detected.

The relevant routine needs modification to print at least the path and preferably also a back-trace.

----------
components: Library (Lib)
messages: 121453
nosy: raph at mankin.org.uk
priority: normal
severity: normal
status: open
title: Unhelpful diagnostic 'cannot find the path specified'
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov 18 17:07:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:07:07 +0000
Subject: [New-bugs-announce] [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

It would be useful if ?python -m compileall -h? was possible.  Right now it fails with ?option -h not recognized? and prints its help text, which is a bit silly :)

Bug week-end candidate!

----------
assignee: eric.araujo
components: Library (Lib)
keywords: easy
messages: 121467
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -h/--help option to compileall
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 18 17:11:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:11:31 +0000
Subject: [New-bugs-announce] [issue10454] Clarify compileall options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

This is the help text of compileall:

 usage: python compileall.py [-l] [-f] [-q] [-d destdir] [-x regexp] [-i list] [directory|file ...]
 -l: don't recurse down
 -f: force rebuild even if timestamps are up-to-date
 -q: quiet operation
 -d destdir: purported directory name for error messages
    if no directory arguments, -l sys.path is assumed
 -x regexp: skip files matching the regular expression regexp
    the regexp is searched for in the full path of the file
 -i list: expand list with its content (file and directory names)
 -b: Produce legacy byte-compile file paths

1) I do not understand the help of -d and -i.  Experimenting with the script, reading the code and eventually looking at the file history would certainly clear that.

2) The short usage line at the top also lacks mention of ?-b?.

3) (minor) I want to rephrase -x, -d and -b.

Bug week-end candidate!

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 121469
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify compileall options
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Nov 18 20:41:37 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 18 Nov 2010 19:41:37 +0000
Subject: [New-bugs-announce] [issue10455] typo in urllib.request
	documentation
In-Reply-To: <1290109297.93.0.111882063571.issue10455@psf.upfronthosting.co.za>
Message-ID: <1290109297.93.0.111882063571.issue10455@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

Typo in Doc/library/urllib.request.rst, under the "urllib.response" module description: "and" -> "an"

----------
assignee: docs at python
components: Documentation
files: urllib.request_typo.diff
keywords: patch
messages: 121487
nosy: docs at python, jfinkels
priority: normal
severity: normal
status: open
title: typo in urllib.request documentation
versions: Python 3.2
Added file: http://bugs.python.org/file19634/urllib.request_typo.diff

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

From report at bugs.python.org  Thu Nov 18 21:16:51 2010
From: report at bugs.python.org (Terry Herron)
Date: Thu, 18 Nov 2010 20:16:51 +0000
Subject: [New-bugs-announce] [issue10456] unittest.main(verbosity=2) broke
	in python31, worked when I had python27
In-Reply-To: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>
Message-ID: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>


New submission from Terry Herron <terry.herron at sas.com>:

The unittest.py module no longer accepts verbosity=2 when calling main.  This worked in Python27.  Example...

     unittest.main(verbosity=2)
     

## THE FIX IN unittest.py##
CHANGE FROM:
1547   def __init__(self, module='__main__', defaultTest=None,
1548           argv=None, testRunner=TextTestRunner,
1549           testLoader=defaultTestLoader, exit=True):

1560       self.verbosity = 1

CHANGE TO:
1547   def __init__(self, module='__main__', defaultTest=None,
1548           argv=None, testRunner=TextTestRunner,
1549           testLoader=defaultTestLoader, exit=True, verbosity=1):

1560       self.verbosity = verbosity

----------
messages: 121492
nosy: teherr
priority: normal
severity: normal
status: open
title: unittest.main(verbosity=2) broke in python31, worked when I had python27
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Nov 19 14:53:37 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Fri, 19 Nov 2010 13:53:37 +0000
Subject: [New-bugs-announce] [issue10457] "Related help topics" shown
	outside pager
In-Reply-To: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>
Message-ID: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>


New submission from Cherniavsky Beni <cben at users.sf.net>:

help('NAMESPACES') or any other long help is shows in a pager.  That's great.  It's a bit surprising however that the text shown in the pager doesn't include the "Related help topics: ..." line, which is shown when you leave the pager.

There is practical benefit to see the related topics after you exited the pager - that's when you have the chance to follow these other topics.  But I think it should be duplicated inside the pager as well.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 121514
nosy: cben, docs at python
priority: normal
severity: normal
status: open
title: "Related help topics" shown outside pager
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 19 15:33:10 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 19 Nov 2010 14:33:10 +0000
Subject: [New-bugs-announce] [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Could Python 2.7 get a dummy re.ASCII = re.A flag,
for source code compatibility with 3.2?

----------
components: Regular Expressions
messages: 121520
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2.7 += re.ASCII
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 19 15:36:27 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 19 Nov 2010 14:36:27 +0000
Subject: [New-bugs-announce] [issue10459] missing character names in
	unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

I just noticed an ommision of come character names in unicodedata module.
These are some CJK - Ideographs:

? (0x9fbc) - ? (0x9fcb)
 (CJK Unified Ideographs [19968-40959] [0x4e00-0x9fff])

? (0x2a700) - ? (0x2b734)
(CJK Unified Ideographs Extension C [173824-177983] [0x2a700-0x2b73f])

? (0x2b740) - ? (0x2b81d)
 (CJK Unified Ideographs Extension D [177984-178207] [0x2b740-0x2b81f])

The names are probably to be generated - e.g. CJK UNIFIED IDEOGRAPH-2A700 ... etc.

(Tested with the recompiled unicodedata - using unicode 6.0; with the py 27 - builtin module (unidata_version: '5.2.0') only the first two ranges are relevant (as CJK Unified Ideographs Extension D is an adition of Unicode 6)

(Also there are the unprintable ASCII controls, surrogates and private use areas, where the missing names are probably ok.)


I tested with the following rather clumsy code:

# # # # # # # # # # # # # # # 
# wide_unichr = custom unichr emulating unicode ranges beyond FFFF on narrow python build
codepoints_missing_char_names = [[-2,-2],] # dummy
for i in xrange(0x10FFFF+1):
    if unicodedata.category(wide_unichr(i))[:1] != 'C' and unicodedata.name(wide_unichr(i), u"??noname??") == u"??noname??":
        if codepoints_missing_char_names[-1][1] == i-1:
            codepoints_missing_char_names[-1][1] = i
        else:
            codepoints_missing_char_names.append([i, i])

for first, last in codepoints_missing_char_names[1:]:
    print u"%s (%s) - %s (%s)" % (wide_unichr(first), hex(first), wide_unichr(last), hex(last),)
# # # # # # # # # # # # # # # # # # # # # # # # # # 

Unfortunately, I can't provide a fix, as unicodedata involves C code, where my knowledge is near zero.

vbr

----------
messages: 121521
nosy: vbr
priority: normal
severity: normal
status: open
title: missing character names in unicodedata (CJK...)

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

From report at bugs.python.org  Fri Nov 19 15:52:51 2010
From: report at bugs.python.org (Mick Beaver)
Date: Fri, 19 Nov 2010 14:52:51 +0000
Subject: [New-bugs-announce] [issue10460] Misc/indent.pro does not reflect
	PEP 7
In-Reply-To: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>
Message-ID: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>


New submission from Mick Beaver <myheartinamerica at gmail.com>:

Hello,

I noticed that the indent.pro in Misc seems very different from PEP 7. Would it be possible to have one that produces C code that meets the PEP 7 style guidelines?

As always, thanks for all of the hard work for Python!

-Mick

----------
components: Demos and Tools
messages: 121526
nosy: Mick.Beaver
priority: normal
severity: normal
status: open
title: Misc/indent.pro does not reflect PEP 7
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov 19 17:05:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:05:04 +0000
Subject: [New-bugs-announce] [issue10461] Use with statement throughout the
	docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The docs contain numerous examples that would trigger resource warnings under 3.2 (for example ?open(...).read()?).  They should be changed to use (and thus promote) the with statement.

Not adding the ?easy? keyword, since grepping for those things is not easy.

Not sure we?ll backport that to 3.1 and 2.7.

----------
assignee: docs at python
components: Documentation
messages: 121545
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Use with statement throughout the docs
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 19 18:32:01 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Nowak?=)
Date: Fri, 19 Nov 2010 17:32:01 +0000
Subject: [New-bugs-announce] [issue10462] Handler.close is not called in
	subclass while	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>


New submission from ?ukasz Nowak <email at lnowak.com>:

Attached file produces output in MyHandler.close on python2.6.6, which is expected.

But on python 2.7 and 2.7.1rc1 it produces nothing, so my handler's close method is not called.

----------
components: Library (Lib)
files: checker.py
messages: 121554
nosy: Shufla
priority: normal
severity: normal
status: open
title: Handler.close is not called in subclass while Logger.removeHandler is called
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19639/checker.py

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

From report at bugs.python.org  Fri Nov 19 22:31:56 2010
From: report at bugs.python.org (Daniel Seither)
Date: Fri, 19 Nov 2010 21:31:56 +0000
Subject: [New-bugs-announce] [issue10463] Wrong return value for
	xml.etree.ElementTree.parse()
In-Reply-To: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>
Message-ID: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>


New submission from Daniel Seither <post at tiwoc.de>:

Cite from http://docs.python.org/library/xml.etree.elementtree.html
> xml.etree.ElementTree.parse(source, parser=None)
>
> Parses an XML section into an element tree. source is a filename or
> file object containing XML data. parser is an optional parser
> instance. If not given, the standard XMLParser parser is used.
> Returns an ElementTree instance.

The last sentence should be "Returns an Element instance."

I verified this error for the Python versions as listed in this issue. In 2.5, the information was imprecise but correct.

----------
assignee: docs at python
components: Documentation
messages: 121571
nosy: docs at python, tiwoc
priority: normal
severity: normal
status: open
title: Wrong return value for xml.etree.ElementTree.parse()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov 20 10:28:40 2010
From: report at bugs.python.org (the_isz)
Date: Sat, 20 Nov 2010 09:28:40 +0000
Subject: [New-bugs-announce] [issue10464] netrc module not parsing passwords
	containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>


New submission from the_isz <the_isz at gmx.de>:

The netrc module stops parsing passwords at # characters, which can be part of
passwords.

Tested with Python 2.7 and 3.1.

----------
components: Extension Modules
messages: 121598
nosy: the_isz
priority: normal
severity: normal
status: open
title: netrc module not parsing passwords containing #s.
type: behavior
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Sat Nov 20 12:05:44 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 11:05:44 +0000
Subject: [New-bugs-announce] [issue10465] gzip module calls getattr
	incorrectly
In-Reply-To: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>
Message-ID: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

gzip._PaddedFile.__getattr__ chains out to getattr, but does so incorrectly (found via running the numpy test suite).

The attached patch fixes this.

----------
files: gzip_getattr.diff
keywords: patch
messages: 121607
nosy: Neil Muller
priority: normal
severity: normal
status: open
title: gzip module calls getattr incorrectly
Added file: http://bugs.python.org/file19652/gzip_getattr.diff

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

From report at bugs.python.org  Sat Nov 20 12:36:07 2010
From: report at bugs.python.org (Sibylle Koczian)
Date: Sat, 20 Nov 2010 11:36:07 +0000
Subject: [New-bugs-announce] [issue10466] locale.py throws exception on
	Windows / Non-UTF8 system
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>


New submission from Sibylle Koczian <nulla.epistola at web.de>:

Running locale.py as a module on Windows, using the Python command window, produces this output:

C:\Python31\Lib>locale.py
Locale aliasing:

Locale defaults as determined by getdefaultlocale():
------------------------------------------------------------------------
Language:  de_DE
Encoding:  cp1252

Locale settings on startup:
------------------------------------------------------------------------
LC_NUMERIC ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_MONETARY ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_COLLATE ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_CTYPE ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_TIME ...
   Language:  (undefined)
   Encoding:  (undefined)


Locale settings after calling resetlocale():
------------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\Lib\locale.py", line 1798, in <module>
    _print_locale()
  File "C:\Python31\Lib\locale.py", line 1761, in _print_locale
    resetlocale()
  File "C:\Python31\Lib\locale.py", line 537, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting

Tried with 2.7 on Windows XP, 32bit, 3.1.2 and 3.2a4 on Windows 7, 64bit. System character set in all cases cp1252 as usual for a German windows installation.

With 2.6, 2.6.5, 3.1.2 on Linux with UTF-8 system character set: no exception, expected output.

----------
components: Library (Lib)
messages: 121616
nosy: skoczian
priority: normal
severity: normal
status: open
title: locale.py throws exception on Windows / Non-UTF8 system
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov 20 12:53:26 2010
From: report at bugs.python.org (Sebastian Hagen)
Date: Sat, 20 Nov 2010 11:53:26 +0000
Subject: [New-bugs-announce] [issue10467] io.BytesIO.readinto() segfaults
	when used on BytesIO	object seeked beyond end.
In-Reply-To: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>
Message-ID: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>


New submission from Sebastian Hagen <sh_pybugs at memespace.net>:

io.BytesIO().readinto() does not correctly handle the case of being called on a BytesIO object that has been seeked past the end of its data. It consequently ends up reading into unallocated memory, and (typically?) segfaulting if used in this manner. I've confirmed that this bug exists in the same fashion in 2.6, 2.7, 3.0, 3.1 and 3.2; the following demonstration code works on all of these.

Demonstration:
>>> import io; b = io.BytesIO(b'bytes'); b.seek(42); b.readinto(bytearray(1))
42
Segmentation fault

I'm attaching a simple patch against r32a3:85355 that fixes this problem.

----------
components: IO
files: bio_readinto_1.patch
keywords: patch
messages: 121618
nosy: sh
priority: normal
severity: normal
status: open
title: io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end.
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19656/bio_readinto_1.patch

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

From report at bugs.python.org  Sat Nov 20 14:47:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 13:47:42 +0000
Subject: [New-bugs-announce] [issue10468] Document UnicodeError access
	functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

There are a couple of functions for accessing UnicodeError subclass properties that are needed e.g. in codec error handlers.  They should be documented in exceptions.rst.

----------
assignee: docs at python
components: Documentation
messages: 121641
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Document UnicodeError access functions

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

From report at bugs.python.org  Sat Nov 20 15:24:42 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 14:24:42 +0000
Subject: [New-bugs-announce] [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>


New submission from Daniel Albeseder <kotan at gmx.at>:

Using WinXP I compiled python 3.2 from the current sources using Visual C++ 2010 Express.

Running

rt -v test_socket

resulted in the attached output.

The tests testSmallReadNonBlocking and testWriteNonBlocking have errors, and an assertion fails for test_connect and test_create_connections.

----------
components: Library (Lib)
files: test_socket.log
messages: 121651
nosy: Kotan
priority: normal
severity: normal
status: open
title: test_socket fails
versions: Python 3.2
Added file: http://bugs.python.org/file19670/test_socket.log

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

From report at bugs.python.org  Sat Nov 20 18:55:40 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 17:55:40 +0000
Subject: [New-bugs-announce] [issue10470] python -m unittest ought to
	default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

"python -m unittest" does nothing useful (runs 0 tests). It would be good to have it default to discovery, which removes the useless behaviour *and* makes the default invocation for test discovery shorter.

----------
assignee: michael.foord
components: Library (Lib)
messages: 121698
nosy: michael.foord
priority: normal
severity: normal
status: open
title: python -m unittest ought to default to discovery
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 20 20:56:46 2010
From: report at bugs.python.org (Dan L)
Date: Sat, 20 Nov 2010 19:56:46 +0000
Subject: [New-bugs-announce] [issue10471] include documentation in python
	docs and under python -h	for other commandline options
In-Reply-To: <1290283006.28.0.157512175607.issue10471@psf.upfronthosting.co.za>
Message-ID: <1290283006.28.0.157512175607.issue10471@psf.upfronthosting.co.za>


New submission from Dan L <choralreef at naver.com>:

there are options such as 'python -tt -bb' that are undocumented at http://docs.python.org/using/cmdline and that don't show up when you type python -h.   ( Doubling t and b turns tabs or bytes warnings into errors.
) I don't know if they show up or not when you type 'man python', but for windows devs, it'd be best if it were included in the '-h' text excerpt in addition to being in the online docs.  It could also be nice to have an example for the W arg option, e.g. for Wd.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 121746
nosy: docs at python, jdan
priority: normal
severity: normal
status: open
title: include documentation in python docs and under python -h for other commandline options
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov 20 21:47:34 2010
From: report at bugs.python.org (Daniel Harper)
Date: Sat, 20 Nov 2010 20:47:34 +0000
Subject: [New-bugs-announce] [issue10472] Strange tab key behaviour in
	interactive python 2.7 OSX	10.6.2
In-Reply-To: <1290286054.61.0.644814416061.issue10472@psf.upfronthosting.co.za>
Message-ID: <1290286054.61.0.644814416061.issue10472@psf.upfronthosting.co.za>


New submission from Daniel Harper <djharperuk at gmail.com>:

Hi there. 

I recently downloaded the python 2.7 installer from the python website and installed it on my Mac. 

When I run python2.7 in interactive mode, the tab key doesn't seem to behave as how it did in 2.6.

For example


>> def helloWorld(name):                                                                    
... ./                                                                                    File "<stdin>", line 2   
    ./                                                                                    
    ^                                                                                       
IndentationError: expected an indented block     

When you hit tab it seems to think I want to browse the contents of the current directory I'm in, rather than placing a tab character so I can quickly use python in interactive mode to prototype stuff.

I'd imagine it's something to do with GNU readline, but I'm pretty sure I have this installed

----------
assignee: ronaldoussoren
components: Macintosh
messages: 121766
nosy: Daniel.Harper, ronaldoussoren
priority: normal
severity: normal
status: open
title: Strange tab key behaviour in interactive python 2.7 OSX 10.6.2
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 20 21:54:16 2010
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Nov 2010 20:54:16 +0000
Subject: [New-bugs-announce] [issue10473] Strange behavior for socket.timeout
In-Reply-To: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>
Message-ID: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

While investigating issue7322, I wrote a test case to demonstrate the issue.  I made a mistake and called settimeout() on the wrong socket, but the result appears to demonstrate a different bug.  When I run the attached test-issue7322.py on my OSX-10.6.5 machine, using...

Python 3.2a4+ (py3k:86538, Nov 19 2010, 20:52:31) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin

I get the output below.  The bug is that readline() is returning, even though I never wrote a newline on the other side of the connection.  If I comment out the settimeout() call, it hangs in the readline() call, as expected.

While I admit it makes no sense to call settimeout() on the listening socket, doing so certainly should not cause this behavior.

Note: I also tried this on Ubuntu linux (with python built from the same 3.2a4+ sources).  I cannot reproduce the problem there.


issue7322$ ./test-issue7322.py 
F/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
  result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed <socket.socket object, fd=4, family=2, type=1, proto=0>
  result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/socket.py:324: ResourceWarning: unclosed <socket.socket object, fd=5, family=2, type=1, proto=0>
  self._sock = None

======================================================================
FAIL: test_foo (__main__.Test_Issue7322)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-issue7322.py", line 22, in test_foo
    self.fail("readline() returned '%s'" % line)
AssertionError: readline() returned 'hello'

----------------------------------------------------------------------
Ran 1 test in 0.026s

FAILED (failures=1)
[49547 refs]

----------
components: Library (Lib)
files: test-issue7322.py
messages: 121769
nosy: roysmith
priority: normal
severity: normal
status: open
title: Strange behavior for socket.timeout
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19710/test-issue7322.py

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

From report at bugs.python.org  Sat Nov 20 23:27:00 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 22:27:00 +0000
Subject: [New-bugs-announce] [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

>>> a = range(5)
>>> a.count(5)
False
>>> a.count(2)
True

I believe this is related to the issue9213 that introduced count and index method on the range object. According to the documentation accompanying that fix it should return an integer.

----------
components: Interpreter Core
messages: 121799
nosy: SilentGhost
priority: normal
severity: normal
status: open
title: range.count returns boolean
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 00:59:40 2010
From: report at bugs.python.org (Nicolas Joly)
Date: Sat, 20 Nov 2010 23:59:40 +0000
Subject: [New-bugs-announce] [issue10475] hardcoded compilers for
	LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>


New submission from Nicolas Joly <njoly at pasteur.fr>:

The configure script do hardcode compilers for LDSHARED/LDCXXSHARED on NetBSD, which should be avoided.

[...]
checking for gcc... gcc
checking whether gcc accepts -g... yes
[...]
checking SO... .so
checking LDSHARED... cc -shared 
checking CCSHARED... -fPIC
[...]

----------
components: Build
files: python-cc.diff
keywords: patch
messages: 121817
nosy: njoly
priority: normal
severity: normal
status: open
title: hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
versions: Python 2.7
Added file: http://bugs.python.org/file19719/python-cc.diff

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

From report at bugs.python.org  Sun Nov 21 01:42:45 2010
From: report at bugs.python.org (Julian)
Date: Sun, 21 Nov 2010 00:42:45 +0000
Subject: [New-bugs-announce] [issue10476] __iter__ on a byte file object
	using a method to return	an iterator
In-Reply-To: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>
Message-ID: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

Iterating over a byte file object using __iter__ is rather useless, and a bit confusing perhaps.

It'd be nice to propose two things:

1. Having __iter__ raise an exception if the file was opened with the "b" flag.

2. Adding a new by_bytes() method to file objects, which would return an iterator that yielded the next byte in the file, introducing the ability to write a similar `for byte in byte_file_obj.by_bytes()` that is currently possible when iterating by line over non-byte files.

It's quite easy to do (2) currently, obviously, but perhaps it's worthy of consideration for inclusion.

----------
components: IO
messages: 121820
nosy: Julian
priority: normal
severity: normal
status: open
title: __iter__ on a byte file object using a method to return an iterator
type: feature request
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Nov 21 03:45:57 2010
From: report at bugs.python.org (Drakonnen)
Date: Sun, 21 Nov 2010 02:45:57 +0000
Subject: [New-bugs-announce] [issue10477] AttributeError: 'NoneType' object
	has no attribute	'name' (bonenode.name)
In-Reply-To: <1290307557.36.0.502184693824.issue10477@psf.upfronthosting.co.za>
Message-ID: <1290307557.36.0.502184693824.issue10477@psf.upfronthosting.co.za>


New submission from Drakonnen <drakonnen at yahoo.com>:

Trying to import a .nif into Blender, for Oblivion mod work, I get the following error:

Blender NIF Scripts 2.5.5 (running on Blender 249, PyFFI 2.1.6)
pyffi.toaster:INFO:--- fix_mergeskeletonroots ---
pyffi.toaster:INFO:  ~~~ NiNode [Scene Root] ~~~
pyffi.toaster:INFO:--- fix_sendgeometriestobindposition ---
pyffi.toaster:INFO:  ~~~ NiNode [Scene Root] ~~~
pyffi.toaster:INFO:    sending geometries to bind position
Traceback (most recent call last):
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\bpymo
dules\nif_common.py", line 1227, in gui_button_event
    self.gui_exit()
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\bpymo
dules\nif_common.py", line 1579, in gui_exit
    self.callback(**self.config)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 3750, in config_callback
    importer = NifImport(**config)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 274, in __init__
    self.import_root(root)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 309, in import_root
    pyffi.spells.nif.fix.SpellSendGeometriesToBindPosition(data=data).recurse()
  File "C:\Python26\lib\site-packages\pyffi\spells\__init__.py", line 289, in re
curse
    self.recurse(child)
  File "C:\Python26\lib\site-packages\pyffi\spells\__init__.py", line 298, in re
curse
    if self.branchentry(branch):
  File "C:\Python26\lib\site-packages\pyffi\spells\nif\__init__.py", line 135, i
n branchentry
    self.skelrootentry(branch)
  File "C:\Python26\lib\site-packages\pyffi\spells\nif\fix.py", line 380, in ske
lrootentry
    branch.send_geometries_to_bind_position()
  File "C:\Python26\lib\site-packages\pyffi\formats\nif\__init__.py", line 5106,
 in send_geometries_to_bind_position
    if bonenode.name in bone_bind_transform:
AttributeError: 'NoneType' object has no attribute 'name'

----------
components: Windows
messages: 121840
nosy: Drakonnen
priority: normal
severity: normal
status: open
title: AttributeError: 'NoneType' object has no attribute 'name'  (bonenode.name)
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sun Nov 21 05:07:52 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 21 Nov 2010 04:07:52 +0000
Subject: [New-bugs-announce] [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

The following program is misbehaving with python3.2

 import signal, time

 def sighandler( arg1, arg2): print("got sigint");    assert 0

 signal.signal( signal.SIGINT, sighandler)

 for i in range(1000000):
    print(i)

I'd expect Ctrl-C to terminate the program with AssertionError and that's indeed what happens under python2.7.

But with python3.2a, I get "Assertion Error" 1 out ~10 times. The other 9 times, the program locks up (goes to sleep? ps shows process status as "S"). After the program locks up, it does not respond to subsequent "Ctrl-C" presses.

This is on 64-bit Ubuntu 8.04.

----------
components: Interpreter Core
messages: 121860
nosy: isandler
priority: normal
severity: normal
status: open
title: Ctrl-C locks up the interpreter
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 06:37:17 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:37:17 +0000
Subject: [New-bugs-announce] [issue10479] cgitb.py should assume a binary
	stream for output
In-Reply-To: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>
Message-ID: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

The CGI interface is a binary stream, because it is pumped directly to/from the HTTP protocol, which is a binary stream.

Hence, cgitb.py should produce binary output.  Presently, it produces text output.

When one sets stdout to a binary stream, and then cgitb intercepts an error, cgitb fails.

Demonstration of problem:

import sys
import traceback
sys.stdout = open("sob", "wb")  # WSGI sez data should be binary, so stdout should be binary???
import cgitb
sys.stdout.write(b"out")
fhb = open("fhb", "wb")
cgitb.enable()
fhb.write("abcdef")  # try writing non-binary to binary file.  Expect an error, of course.

----------
components: Unicode
messages: 121865
nosy: v+python
priority: normal
severity: normal
status: open
title: cgitb.py should assume a binary stream for output
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 06:43:09 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:43:09 +0000
Subject: [New-bugs-announce] [issue10480] cgi.py should document the need
	for binary stdin/stdout
In-Reply-To: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>
Message-ID: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

CGI is a bytestream protocol.  Python assumes a text mode encoding for stdin and stdout, this is inappropriate for the CGI interface.

CGI should provide an API to "do the right thing" to make stdin and stout binary mode interfaces (including mscvrt setting to binary on Windows).  Failing that, it should document the need to do so in CGI applications.

Failing that, it should be documented somewhere, CGI seems the most appropriate place to me.

----------
components: Library (Lib)
messages: 121868
nosy: v+python
priority: normal
severity: normal
status: open
title: cgi.py should document the need for binary stdin/stdout
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 06:57:04 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:57:04 +0000
Subject: [New-bugs-announce] [issue10481] subprocess PIPEs are byte streams
In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za>
Message-ID: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

While http://bugs.python.org/issue2683 did clarify the fact that the .communicate API takes a byte stream as input, it is easy to miss the implication.  Because Python programs start up with stdin as a text stream, it might be good to point out that some action may need to be taken to be sure that the receiving program expects a byte stream, or that the byte stream supplied should be in an encoding that the receiving program is expecting and can decode appropriately.

No mention is presently made in the documentation for .communicate that its output is also a byte stream, and if text will correspond to whatever encoding is used by the sending program.

----------
assignee: docs at python
components: Documentation
messages: 121869
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: subprocess PIPEs are byte streams
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 07:16:02 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 06:16:02 +0000
Subject: [New-bugs-announce] [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

.communicate is a nice API for programs that produce little output, and can be buffered.  While that may cover a wide range of uses, it doesn't cover launching CGI programs, such as is done in http.server.  Now there are nice warnings about that issue in the http.server documentation.

However, while .communicate has the building blocks to provide more general solutions, it doesn't expose them to the user, nor does it separate them into building blocks, rather it is a monolith inside ._communicate.

For example, it would be nice to have an API that would "capture a stream using a thread" which could be used for either stdout or stdin, and is what ._communicate does under the covers for both of them.

It would also be nice to have an API that would "pump a bytestream to .stdin as a background thread.  ._communicate doesn't provide that one, but uses the foreground thread for that.  And, it requires that it be fully buffered.  It would be most useful for http.server if this API could connect a file handle and an optional maximum read count to .stdin, yet do it in a background thread.

That would leave the foreground thread able to process stdout.  It is correct (but not what http.server presently does, but I'll be entering that enhancement request soon) for http.server to read the first line from the CGI program, transform it, add a few more headers, and send that to the browser, and then hook up .stdout to the browser (shutil.copyfileobj can be used for the rest of the stream).  However, there is no deadlock free way of achieving this sort of solution, capturing the stderr to be logged, not needing to buffer a potentially large file upload, and transforming the stdout, with the facilities currently provided by subprocess.  Breaking apart some of the existing building blocks, and adding an additional one for .stdin processing would allow a real http.server implementation, as well as being more general for other complex uses.

You see, for http.server, the stdin

----------
components: Library (Lib)
messages: 121871
nosy: v+python
priority: normal
severity: normal
status: open
title: subprocess and deadlock avoidance
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 08:26:30 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:26:30 +0000
Subject: [New-bugs-announce] [issue10483] http.server - what is executable
	on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

The def executable for CGIHTTPRequestHandler is simply wrong on Windows.  The Unix executable bits do not apply.

Yet it is not clear what to use instead.  One could check the extension against PATHEXT, perhaps, but Windows doesn't limit itself to that except when not finding the exactly specified executable name.  Or one could require and borrow the unix #! convention.  As an experiment, since I'm mostly dealing the script files, I tried out a hack that implements two #! lines, the first for Unix and the second for Windows, and only consider something executable if the second line exists.  This fails miserably for .exe files, of course.

Another possibility would be to see if there is an association for the extension, but that rule would permit a Word document to be "executable" because there is a way to open it using MS Word.

Another possibility would be to declare a list of extensions in the server source, like the list of directories from which CGIs are found.

Another possibility would be to simply assume that anything found in the CGI directory is executable.

Another possibility is to require the .cgi extension only to be executable, but then it is hard to know how to run it.

Another possibility is to require two "extensions"... the "real" one for Windows, and then .cgi just before it.  So to make a program executable, it would be renamed from file.ext to file.cgi.ext

But the current technique is clearly insufficient.

----------
components: Library (Lib)
messages: 121875
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server - what is executable on Windows
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 08:31:57 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:31:57 +0000
Subject: [New-bugs-announce] [issue10484] http.server.is_cgi fails to handle
	CGI URLs containing	PATH_INFO
In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>
Message-ID: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

is_cgi doesn't properly handle PATH_INFO parts of the path.  The Python2.x CGIHTTPServer.py had this right, but the introduction and use of _url_collapse_path_split broke it.

_url_collapse_path_split splits the URL into a two parts, the second part is guaranteed to be a single path component, and the first part is the rest.  However, URLs such as

/cgi-bin/foo.exe/this/is/PATH_INFO/parameters

can and do want to exist, but the code in is_cgi will never properly detect that /cgi-bin/foo.exe is the appropriate executable, and the rest should be PATH_INFO.

This used to work correctly in the precedecessor CGIHTTPServer.py code in Python 2.6, so is a regression.

----------
components: Library (Lib)
messages: 121876
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 08:38:14 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:38:14 +0000
Subject: [New-bugs-announce] [issue10485] http.server fails when query
	string contains addition	'?' characters
In-Reply-To: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>
Message-ID: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

http.server on Python 3 and CGIHTTPServer on Python 2 both contain the same code with the same bug.  In run_cgi, rest.rfind('?') is used to separate the path from the query string.  However, it should be rest.find('?') as the query string starts with '?' but may also contain '?'.  It is required that '?' not be used in URL path part without escaping.

Apache, for example, separates the following URL:

/testing?foo=bar?&baz=3

into path part /testing  and query string part  foo=bar?&baz=3 but http.server does not.

----------
components: Library (Lib)
messages: 121877
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server fails when query string contains addition '?' characters
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 21 08:41:35 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:41:35 +0000
Subject: [New-bugs-announce] [issue10486] http.server doesn't set all CGI
	environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

HTTP_HOST HTTP_PORT REQUEST_URI are variables that my CGI scripts use, but which are not available from http.server or CGIHTTPServer (until I added them).

There may be more standard variables that are not set, I didn't attempt to enumerate the whole list.

----------
components: Library (Lib)
messages: 121878
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server doesn't set all CGI environment variables
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 21 08:50:43 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:50:43 +0000
Subject: [New-bugs-announce] [issue10487] http.server - doesn't process
	Status: header from CGI	scripts
In-Reply-To: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>
Message-ID: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

While it is documented that http.server (and Python 2's CGIHTTPServer) do not process the status header, and limit the usefulness of CGI scripts as a result, that doesn't make it less of a bug, just a documented bug.  But I guess that it might have to be called a feature request; I'll not argue if someone switches this to feature request, but I consider it a bug.

See related issue 10482 for subprocess to provide better features for avoiding deadlock situations.  There seems to be no general way using subprocess to avoid possible deadlock situations.  However, since CGI doesn't really use stderr much, and only for logging, which the scripts can do themselves (the cgi.py module even provides for such), and because CGIs generally slurp stdin before creating stdout, it is possible to tweak sidestep use of subprocess.communicate, drop the stdout PIPE, and sequence the code to process stdin and then stdout, and not generally deadlock (some CGI scripts that don't above the stdin before stdout rule, might deadlock if called with POST and large inputs, but those are few).

By doing this, one can then add code to handle Status: headers, and avoid buffering large files on output (and on input).  The tradeoff is losing the stderr log; when that is hooked up, some error cases can trigger deadlocks by writing to stderr -- hence the subprocess issue mentioned above.

----------
components: Library (Lib)
messages: 121881
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server - doesn't process Status: header from CGI scripts
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 21 13:25:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:25:48 +0000
Subject: [New-bugs-announce] [issue10488] Improve documentation for 'float'
	built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The docs for 'float' are outdated, and also not entirely written in English. :-)

Here's a patch.

----------
assignee: docs at python
components: Documentation
files: float_builtin_doc.patch
keywords: patch
messages: 121910
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Improve documentation for 'float' built-in.
versions: Python 3.2
Added file: http://bugs.python.org/file19739/float_builtin_doc.patch

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

From report at bugs.python.org  Sun Nov 21 13:30:54 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 12:30:54 +0000
Subject: [New-bugs-announce] [issue10489] configparser: remove broken
	`__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

I want to sum up all strange things about the behaviour of `__name__`, a special key present in every section of a parser instance.

1. There is a special `__name__` key in every section.
2. Except for the DEFAULTSECT.
3. `__name__` key is set for every section read from a file.
4. and not when adding by `add_section()`.
5. if `__name__` does exist, it's not visible in `parser.options('section')`
6. but it is visible here: `parser.has_option('section', '__name__') == True`
7. and can be obtained by `parser.get('section', '__name__')`
8. and can be changed by `parser.set('section', '__name__', 'ANY VALUE')`
9. and can be removed by `parser.remove_option('section', '__name__')`
10. even if the value is changed by `parser.set()`, it won't be written back to a file with `parser.write()`

All this looks like a feature that was not particularly complete and well defined when it was first created. Or possibly, it became rotten with time and now nobody is using it anyway. That way or the other, I couldn't come up with a valid use case for `__name__` with the current implementation. It doesn't serve any internal purpose and the *only* way you can actually get it is to `parser.get('section', '__name__')` which returns 'section' anyway. About as useless as it gets. Of course, one can go and take the internal parser._sections data structure of the parser but that's evil.

I want simply remove all mentions of a special `__name__` key in configparser.py. Backwards compatibility is not a concern here because in this case we have a concept that is so broken that you can't actually use it.

----------
assignee: lukasz.langa
components: Library (Lib)
keywords: easy, needs review
messages: 121912
nosy: lukasz.langa
priority: normal
severity: normal
status: open
title: configparser: remove broken `__name__` support
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 21 15:10:24 2010
From: report at bugs.python.org (And Clover)
Date: Sun, 21 Nov 2010 14:10:24 +0000
Subject: [New-bugs-announce] [issue10490] mimetypes read_windows_registry
	fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

The `enum_types` function in `MimeTypes.read_windows_registry` tries to `.encode` the results of `EnumKey`, assuming it to be a Unicode string.

However, `_winreg.EnumKey` in Python 2.x actually returns a byte string (straight from the ANSI version of the registry interface). Consequently, if there is a MIME type registered with a non-ASCII character in its name (invalid, but not unheard of), initialising `MimeTypes` will raise a `UnicodeDecodeError`. This is not caught (it is only expecting a `UnicodeEncodeError`), so it bombs out whatever module indirectly caused `mimetypes.init()` to be called.

This attempt to `.encode` the `ctype` should simply be removed.

----------
components: Library (Lib)
files: mimetypes-patch2-2.7.patch
keywords: patch
messages: 121929
nosy: aclover
priority: normal
severity: normal
status: open
title: mimetypes read_windows_registry fails for non-ASCII keys
versions: Python 2.7
Added file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch

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

From report at bugs.python.org  Sun Nov 21 17:00:58 2010
From: report at bugs.python.org (Gynvael Coldwind)
Date: Sun, 21 Nov 2010 16:00:58 +0000
Subject: [New-bugs-announce] [issue10491] Insecure Windows python directory
	permissions
In-Reply-To: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>
Message-ID: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>


New submission from Gynvael Coldwind <gynvael at gmail.com>:

Hi,

Installers I've tested:
Python 3.1.2 (signed Sunday, March 21, 2010 12:49:44 AM)
Python 2.7 (signed Sunday, July 04, 2010 7:23:45 AM)

It seems that Python's Windows installer doesn't correctly set permissions of Python's directories, allowing any user on the system to create a file inside these directories.

Using DLL Spoofing method (aka DLL Hijaking or Binary Planting) an unprivileged user can create an arbitrary DLL file (e.g. named python31.dll imported by python.exe) inside that directory, which will get loaded and it's code will get executed when some other user launches any python or the interpreter itself (i.e. this may lead to elevation of privileges).
This has been tested and proved to work.

Easiest way to check:
1. Install Python on Windows (with NTFS partition)
2. Create a user without any administrative permissions
3. Run a command shell in the context of that user
4. Type: echo.>c:\python31\python31.dll (the name of the directory and DLL file may be different)
5. Run c:\python31\python.exe or any python script from any user
You should get the following message:

---------------------------
python.exe - Bad Image
---------------------------
c:\python31\python31.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. 
---------------------------

This proves that the created DLL file was (tried to be) loaded into the context of the process. 


Main directories ACLs:
C:\Users\test>cacls c:\python31
c:\Python31 NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F
            BUILTIN\Administrators:(OI)(CI)(ID)F
            BUILTIN\Users:(OI)(CI)(ID)R
            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_APPEND_DATA

            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_WRITE_DATA

            CREATOR OWNER:(OI)(CI)(IO)(ID)F


C:\Users\test>cacls c:\python27
c:\Python27 NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F
            BUILTIN\Administrators:(OI)(CI)(ID)F
            BUILTIN\Users:(OI)(CI)(ID)R
            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_APPEND_DATA

            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_WRITE_DATA

            CREATOR OWNER:(OI)(CI)(IO)(ID)F

These directories SHOULD NOT allow Users to FILE_APPEND_DATA or FILE_WRITE_DATA.

Suggested fix:
The installer should make sure the FILE_APPEND_DATA and FILE_WRITE_DATA rights are not present in any directories ACLs.

Attached: List of directories found to be insecure (i.e. everyone can create a file there).

----------
components: Installation, Windows
files: Python_dir_list.txt
messages: 121947
nosy: Gynvael.Coldwind
priority: normal
severity: normal
status: open
title: Insecure Windows python directory permissions
type: security
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19751/Python_dir_list.txt

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

From report at bugs.python.org  Sun Nov 21 18:24:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 17:24:03 +0000
Subject: [New-bugs-announce] [issue10492] test_doctest fails with
	iso-8859-15 locale
In-Reply-To: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>
Message-ID: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>


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

$ LANG=ISO-8859-15 ./python -m test.regrtest test_doctest
[1/1] test_doctest
**********************************************************************
File "/home/antoine/py3k/__svn__/Lib/test/test_doctest.py", line 1676, in test.test_doctest.test_debug
Failed example:
    try: doctest.debug_src(s)
    finally: sys.stdin = real_stdin
Expected:
    > <string>(1)<module>()
    (Pdb) next
    12
    --Return--
    > <string>(1)<module>()->None
    (Pdb) print(x)
    12
    (Pdb) continue
Got:
    > /home/antoine/py3k/__svn__/Lib/encodings/iso8859_15.py(15)decode()
    -> return codecs.charmap_decode(input,errors,decoding_table)
    (Pdb) next
    --Return--
    > /home/antoine/py3k/__svn__/Lib/encodings/iso8859_15.py(15)decode()->('<string>', 8)
    -> return codecs.charmap_decode(input,errors,decoding_table)
    (Pdb) print(x)
    *** NameError: name 'x' is not defined
    (Pdb) continue
    12
**********************************************************************
1 items had failures:
   1 of   4 in test.test_doctest.test_debug
***Test Failed*** 1 failures.
test test_doctest failed -- 1 of 429 doctests failed
1 test failed:
    test_doctest


Also visible on the following buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/builds/934/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 121954
nosy: haypo, loewis, pitrou, tim_one
priority: normal
severity: normal
stage: needs patch
status: open
title: test_doctest fails with iso-8859-15 locale
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 21 22:05:28 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 21 Nov 2010 21:05:28 +0000
Subject: [New-bugs-announce] [issue10493] test_strptime failures under
	OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Python 3.1 head is reporting failures in test_strptime under OpenIndiana 147. For example http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/3/steps/test/logs/stdio


Python 2.7 and 3.2 heads are working fine.

----------
components: Extension Modules
messages: 121991
nosy: jcea
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_strptime failures under OpenIndiana
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov 22 01:09:58 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:09:58 +0000
Subject: [New-bugs-announce] [issue10494] Demo/comparisons/regextest.py
	needs some usage	information.
In-Reply-To: <1290384598.34.0.211944890611.issue10494@psf.upfronthosting.co.za>
Message-ID: <1290384598.34.0.211944890611.issue10494@psf.upfronthosting.co.za>


New submission from Ramiro Batista da Luz <ramiroluz at gmail.com>:

When someone run Demo/comparisons/regextest.py without arguments it waits for lines to be inserted in the command line silently, until the EOF, or Ctrl-D in Linux, is entered.

If the user read the file, editing or using cat Demo/comparisons/regextest.py he have to understand the code to figure out how to use it.

My suggestion is to add an usage message.

----------
components: Demos and Tools
messages: 122032
nosy: ramiroluz
priority: normal
severity: normal
status: open
title: Demo/comparisons/regextest.py needs some usage information.
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 22 01:38:32 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:38:32 +0000
Subject: [New-bugs-announce] [issue10495] Demo/comparisons/sortingtest.py
	needs some usage	information.
In-Reply-To: <1290386312.84.0.302753892173.issue10495@psf.upfronthosting.co.za>
Message-ID: <1290386312.84.0.302753892173.issue10495@psf.upfronthosting.co.za>


New submission from Ramiro Batista da Luz <ramiroluz at gmail.com>:

When someone run Demo/comparisons/regextest.py without arguments it waits for lines to be inserted in the command line silently, until the EOF, or Ctrl+D in Linux, is entered.

If the user read the file, editing or using cat Demo/comparisons/sortingtest.py he have to understand the code to figure out how to use it.

My suggestion is to add an usage message, plus the if __name__ == '__main__':.

----------
components: Demos and Tools
messages: 122048
nosy: ramiroluz
priority: normal
severity: normal
status: open
title: Demo/comparisons/sortingtest.py needs some usage information.
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 22 01:59:51 2010
From: report at bugs.python.org (Brian Bi)
Date: Mon, 22 Nov 2010 00:59:51 +0000
Subject: [New-bugs-announce] [issue10496] "import site failed" when Python
	can't find home	directory
In-Reply-To: <1290387591.59.0.788816465526.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290387591.59.0.788816465526.issue10496@psf.upfronthosting.co.za>


New submission from Brian Bi <bbi5291 at gmail.com>:

This bug is Linux-specific.

When Python cannot find the home directory of the user invoking it, it prints "'import site' failed; use -v for traceback".

This occurs only when both of these conditions are met:
1. /etc/passwd contains no entry for the current real UID
2. the HOME environment variable does not exist

To duplicate this bug, compile and run the attached program as root.
(Note that this will fail if 12345 is a legitimate user on your system, or if Python is not at /usr/bin/python.)

----------
components: None
files: bug.c
messages: 122051
nosy: bbi5291
priority: normal
severity: normal
status: open
title: "import site failed" when Python can't find home directory
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19760/bug.c

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

From report at bugs.python.org  Mon Nov 22 03:31:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:31:26 +0000
Subject: [New-bugs-announce] [issue10497] Incorrect use of gettext in
	argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found two calls to gettext that are incorrect.  See attached patch.

----------
components: Library (Lib)
files: gettext-argparse.diff
keywords: patch
messages: 122068
nosy: bethard, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Incorrect use of gettext in argparse
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19766/gettext-argparse.diff

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

From report at bugs.python.org  Mon Nov 22 03:35:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:35:06 +0000
Subject: [New-bugs-announce] [issue10498]
	calendar.LocaleHTMLCalendar.formatyearpage() results
	in	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>


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

See issue 10466 for background, but in short LocaleHTMLCalendar uses getdefaultlocale if no locale is specified, and on windows this results in a locale that setlocale will not accept.  The fix is presumably to use setlocale(LC_DATE, '') instead of getdefaultelocale.

----------
keywords: easy
messages: 122070
nosy: r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: calendar.LocaleHTMLCalendar.formatyearpage() results in traceback with 'unsupported locale setting' on Windows
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov 22 04:16:33 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 03:16:33 +0000
Subject: [New-bugs-announce] [issue10499] Modular interpolation in
	configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

SUMMARY
=======

This is a refactoring of configparser raised from discussions on #6517 and #9876. It solves both issues and makes the code quite elegant. Best part is, it's fully backwards compatible [1].

In the patch I basically did:
a) move the interpolation functionality out of the parsers
b) deprecate RCP and CP in favor of SCP
c) refactor the resulting code to get rid of duplicates

This means that actually despite the generalization and introduction of deprecation warnings, configparser lost 22 lines in the process. The implementation is complete and unit tested.


WHAT'S LEFT TO DO
=================

1. Obviously the new `interpolation` __init__ argument needs docs. This includes the docstrings on *Interpolation classes that describe how the algorithms work.

2. `ExtendedInterpolation` class implementing the buildout syntax, that would satisfy the request from #9876.

3. Once we have more interpolation implementations new test cases will be added to test_cfgparser.py.

Will do all three when I have any opinions on the current direction.


REVIEW HINTS
============

I need some thumbs up or advice on the design decisions made.

1. `interpolation` now takes a class, __init__ instantiates an object on its own. Do tell if taking an object upfront would be a better approach.

2. *Interpolation classes have methods which take the parser as an argument. Do tell if making it an object attribute would be a better approach.

All other points of interest during a review naturally apply here too.



[1] Assuming _names are private and can be moved around when needed.

----------
assignee: lukasz.langa
components: Library (Lib)
files: configparser_interpolation.diff
keywords: needs review, patch
messages: 122078
nosy: eric.araujo, fdrake, georg.brandl, lukasz.langa, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Modular interpolation in configparser
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19767/configparser_interpolation.diff

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

From report at bugs.python.org  Mon Nov 22 10:16:36 2010
From: report at bugs.python.org (Vil)
Date: Mon, 22 Nov 2010 09:16:36 +0000
Subject: [New-bugs-announce] [issue10500] Palevo.DZ worm msix86 installer
	3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>


New submission from Vil <vilignoble at gmail.com>:

scan on msi installer x86 win 3.x python gives Win32/Palevo.DZ worm and erases.

----------
messages: 122101
nosy: VilIgnoble
priority: normal
severity: normal
status: open
title: Palevo.DZ worm msix86 installer 3.x installer
type: security
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 22 11:01:43 2010
From: report at bugs.python.org (Martin)
Date: Mon, 22 Nov 2010 10:01:43 +0000
Subject: [New-bugs-announce] [issue10501] make_buildinfo regression with
	unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

My build got broken by the change for issue 9981 in revision 86137. The problem is it adds $(IntDir) to various places in the vcproj file, including the command line arguments to make_buildinfo, and my svn checkout is under a dir with a space in.

Ideally it could just use a relative path, but just making sure it's quoted works too.

----------
components: Build
files: issue9981_regression.patch
keywords: patch
messages: 122104
nosy: gz, krisvale
priority: normal
severity: normal
status: open
title: make_buildinfo regression with unquoted path
versions: Python 3.2
Added file: http://bugs.python.org/file19769/issue9981_regression.patch

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

From report at bugs.python.org  Mon Nov 22 12:22:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Nov 2010 11:22:58 +0000
Subject: [New-bugs-announce] [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Add the unittestgui test runner, built with Tk, to the Tools directory.

It would be good to have this script included in the bin/ directory of the Mac installer as well.

The unittestgui runner can be found at:

    https://bitbucket.org/markroddy/unittestgui

The code is a modification of the original unittestgui by Steve Purcell and updated for test discovery by Mark Roddy. I have asked Mark if he is willing to help maintain the code and asked him to complete a contributor agreement.

----------
assignee: michael.foord
components: Library (Lib)
messages: 122110
nosy: michael.foord, ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: Add unittestguirunner to Tools/
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 22 14:01:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Nov 2010 13:01:11 +0000
Subject: [New-bugs-announce] [issue10503] os.getuid() documentation should
	be clear on what kind	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://docs.python.org/library/os.html#os.getuid
os.getuid() documentation just states:

> Return the current process?s user id.

It is not clear, however, whether "user id" refers to real, effective or saved user id.

As per:
http://linux.about.com/library/cmd/blcmdl2_getuid.htm
...it should refer to _real_ user id.

----------
assignee: docs at python
components: Documentation
messages: 122117
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: os.getuid() documentation should be clear on what kind of uid it is referring
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov 22 14:20:20 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 22 Nov 2010 13:20:20 +0000
Subject: [New-bugs-announce] [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>


New submission from Johann Hanne <python at jf.hanne.name>:

There are a number of mingw compile issues which are easily fixed
* some "_MSC_VER" #if's should be "MS_WINDOWS" instead
* for cross-compiling, windows.h should be all-lowercase
* mingw has a strcasecmp, so private implementations must not use that name

----------
components: Build
files: Python-2.7.diff
keywords: patch
messages: 122122
nosy: jonny
priority: normal
severity: normal
status: open
title: Trivial mingw compile fixes
versions: Python 2.7
Added file: http://bugs.python.org/file19770/Python-2.7.diff

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

From report at bugs.python.org  Mon Nov 22 15:41:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Nov 2010 14:41:01 +0000
Subject: [New-bugs-announce] [issue10505] test_compileall: failure on Windows
In-Reply-To: <1290436861.2.0.949671079169.issue10505@psf.upfronthosting.co.za>
Message-ID: <1290436861.2.0.949671079169.issue10505@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On Windows, test_compileall fails due to #10197:

======================================================================
FAIL: test_quiet (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_compileall.py", line 227, in test_quiet
    self.assertGreater(len(noise), len(quiet))
AssertionError: 89 not greater than 89


The patch uses subprocess.check_output() instead. Technically, now
byte strings are compared instead of strings, but that should not matter
for the outcome.

Does the patch look ok?

----------
components: Tests
files: test_compileall.patch
keywords: buildbot, patch
messages: 122129
nosy: brian.curtin, r.david.murray, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_compileall: failure on Windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19771/test_compileall.patch

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

From report at bugs.python.org  Mon Nov 22 16:15:23 2010
From: report at bugs.python.org (Tarsis Azevedo)
Date: Mon, 22 Nov 2010 15:15:23 +0000
Subject: [New-bugs-announce] [issue10506] argparse execute system exit in
	python prompt
In-Reply-To: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>
Message-ID: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>


New submission from Tarsis Azevedo <tarsis.azevedo at gmail.com>:

Hi all, when I use argparse in python prompt, and raise a exception, as the code below:

    >>> import argparse
    >>> parser = argparse.ArgumentParser()
    >>> parser.add_argument('-i' type=int)
    >>> parser.parse_args(['-i', 'a'])

the prompt is closed.

This behavior this in error function (Lib/argparse.py:2325)
I think in python prompt this behavior it's wrong.

it's right?!

----------
components: Library (Lib)
messages: 122134
nosy: Tarsis.Azevedo
priority: normal
severity: normal
status: open
title: argparse execute system exit in python prompt
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 22 17:29:31 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Nov 2010 16:29:31 +0000
Subject: [New-bugs-announce] [issue10507] Check well-formedness of reST
	markup within "make	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Misc/NEWS needs to be valid reST.

Issue 10450 identified an issue where it wasn't.

"make patchcheck" potentially could check the markup of that file, and, potentially all the other places in the source tree that are supposed to be valid reST (all of the .rst files in the source tree, especially those below Doc).

I don't know what the best way of doing this is, without pulling in a lot of dependencies.  (Perhaps we could look for rst2html on $PATH, and use it if it's present?).

----------
components: Demos and Tools
messages: 122142
nosy: dmalcolm
priority: normal
severity: normal
stage: needs patch
status: open
title: Check well-formedness of reST markup within "make patchcheck"
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/issue10507>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:21:32 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Nov 2010 18:21:32 +0000
Subject: [New-bugs-announce] [issue10508] compiler warnings about formatting
	pid_t as an int
In-Reply-To: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>
Message-ID: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

In r85679 Greorg committed a trivial patch to avoid a compiler warning.

I request this (single line fix) to be backported to 2.7.

My argument is that 2.7 is going to be live for quite long, the fix is trivial, it is already in use in Py3k branch, and we would have a perfect clean buildbot report.

For instance: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%202.7/builds/17/steps/compile/logs/warnings%20%281%29

I mark this as a release blocker to raise attention of the maintainer, since we are in release candidate already.

----------
assignee: georg.brandl
components: Extension Modules
keywords: easy
messages: 122152
nosy: georg.brandl, jcea
priority: release blocker
severity: normal
stage: commit review
status: open
title: compiler warnings about formatting pid_t as an int
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 22 19:37:12 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 22 Nov 2010 18:37:12 +0000
Subject: [New-bugs-announce] [issue10509] PyTokenizer_FindEncoding can lead
	to a segfault if bad	characters are found
In-Reply-To: <1290451032.87.0.502665724256.issue10509@psf.upfronthosting.co.za>
Message-ID: <1290451032.87.0.502665724256.issue10509@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

If a non-ascii character is found and there isn't an encoding cookie, a SyntaxError is raised (in `decoding_fgets`) that includes the path of the file (using ``tok->filename``), but that path is never set. You can easily reproduce the crash by calling `imp.find_module("badsyntax")`, where "badsyntax" is a Python file containing a non-ascii character (see e.g. the attached unit test), as `find_module` uses `PyTokenizer_FindEncoding`. Note that Python 3.1 uses `snprintf()` for formatting the error message and some implementations of `snprintf()` explicitly check for null pointers, hence it might not crash.

One possible fix is to set ``tok->filename`` to something like "<unknown>". Attached is a patch which does that and adds an unit test for imp.

----------
components: Interpreter Core
messages: 122153
nosy: Trundle
priority: normal
severity: normal
status: open
title: PyTokenizer_FindEncoding can lead to a segfault if bad characters are found
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov 23 06:11:54 2010
From: report at bugs.python.org (Brian Jones)
Date: Tue, 23 Nov 2010 05:11:54 +0000
Subject: [New-bugs-announce] [issue10510] distutils.command.upload/register
	HTTP message headers:	bad line termination
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In trying to write a PyPI service, I of course need to support the registration and upload features of setup.py, which uses distutils for those actions. One thing making this a bit more difficult than need be is the fact that distutils.command.register and distutils.command.upload both use bare line feeds as a line terminator in the HTTP message headers. While there are probably tolerant servers out there, I think this behavior should be considered a bug in light of the HTTP spec, which reads: 

"The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR."

The second sentence can be interpreted in multiple ways that either agree with or contradict the first sentence, but the first sentence is at least perfectly clear, and I'd like to see "\r\n" added to the beginning of (specifically in this case) the Content-Disposition headers assembled by distutils.command.upload and distutils.command.register.  

The change involves taking identical lines in each file that currently look like this: 


           title = '\nContent-Disposition: form-data; name="%s"' % key

...and making them look like this: 


           title = '\r\nContent-Disposition: form-data; name="%s"' % key

The result is that servers which do not support a lax adherence to the protocol will still be able to support users of distutils in Python 2.6, 2.7, and 3.1 (and maybe others).

----------
messages: 122192
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: distutils.command.upload/register HTTP message headers: bad line termination
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Nov 23 09:10:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 08:10:11 +0000
Subject: [New-bugs-announce] [issue10511] heapq docs clarification
In-Reply-To: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>
Message-ID: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

On the python-docs mailing list, a user suggested to rewrite the first paragraph of the heapq docs like this.  Are you okay with this change, Raymond?


Heaps are trees for which every parent node has a value less than or equal to
any of its children.  This implementation uses arrays for which ``heap[k] <=
heap[2*k+1]`` and ``heap[k] <= heap[2*k+2]`` for all *k*, counting elements from
zero.  For the sake of comparison, non-existing elements are considered to be
infinite.  The interesting property of a heap is that its smallest element is
always the root, ``heap[0]``.

----------
assignee: rhettinger
messages: 122203
nosy: georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: heapq docs clarification

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

From report at bugs.python.org  Tue Nov 23 11:02:16 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Nov 2010 10:02:16 +0000
Subject: [New-bugs-announce] [issue10512] regrtest ResourceWarning -
	unclosed socket
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

When running "make test" on Python3, test_socket reports a number of ResourceWarnings due to unclosed sockets.  Attached is a patch that changes the relevant tests so that they close all the created sockets.

test_multiprocessing and test_xmlrpc have a similar problem; I will upload patches for these shortly.

----------
components: Tests
files: test_socket-resourcewarning-fix.diff
keywords: patch
messages: 122209
nosy: nvawda
priority: normal
severity: normal
status: open
title: regrtest ResourceWarning - unclosed socket
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19783/test_socket-resourcewarning-fix.diff

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

From report at bugs.python.org  Tue Nov 23 13:35:34 2010
From: report at bugs.python.org (Anders Blomdell)
Date: Tue, 23 Nov 2010 12:35:34 +0000
Subject: [New-bugs-announce] [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>


New submission from Anders Blomdell <anders.blomdell at control.lth.se>:

With version 2.7 (and 2.7.1rc1), the following sequence (see attached test):
   
   c =  cursor.execute(' select k from t where k == ?;', (1,))
   conn.commit()
   r = c.fetchone()

Traceback (most recent call last):
  File "/bugs/sqlite_bug.py", line 22, in <module>
    c =  cursor.execute(' select k from t where k == ?;', (2,))
sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.

The program works with 2.6.2

----------
components: Extension Modules
files: sqlite_bug.py
messages: 122213
nosy: anders.blomdell at control.lth.se
priority: normal
severity: normal
status: open
title: sqlite3.InterfaceError after commit
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file19784/sqlite_bug.py

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

From report at bugs.python.org  Tue Nov 23 14:38:41 2010
From: report at bugs.python.org (Keith Meyer)
Date: Tue, 23 Nov 2010 13:38:41 +0000
Subject: [New-bugs-announce] [issue10514] configure does not create accurate
	Makefile
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>


New submission from Keith Meyer <meyer.keith at gmail.com>:

When running configure on AIX 5.3 using:

OPT=-O2 LDFLAGS=-s ./configure --with-gcc="xlc_r -q64" --with-cxx-main="xlC_r -q64" --disable-ipv6 AR="ar -X64"

The Makefile still contains g++ as the CXX compiler to be used.

----------
components: Build
messages: 122214
nosy: daelious
priority: normal
severity: normal
status: open
title: configure does not create accurate Makefile
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 23 18:55:42 2010
From: report at bugs.python.org (Martin Budaj)
Date: Tue, 23 Nov 2010 17:55:42 +0000
Subject: [New-bugs-announce] [issue10515] csv sniffer does not recognize
	quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>


New submission from Martin Budaj <m.budaj at gmail.com>:

The method Sniffer._guess_quote_and_delimiter() in the module csv.py contains a bug in a regexp which checks for quotes around the last item of the line (example: a,b,"c,d"\n).

the pattern
'(?P<delim>>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)'
used in the regex should be changed to
'(?P<delim>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)'

file csv.py: line 212 in python 2.6, line 216 in 2.7, line 207 in 3.1

----------
components: Library (Lib)
messages: 122227
nosy: Martin.Budaj
priority: normal
severity: normal
status: open
title: csv sniffer does not recognize quotes at the end of line
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Nov 24 00:37:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 23:37:48 +0000
Subject: [New-bugs-announce] [issue10516] Add list.clear()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Add list.clear() method with obvious semantics.

Pro:
1. parallel to set/dict/defaultdict/deque.clear(),
   usable in generic mutable collection function;
2. makes it easier to switch between list and other collection class;
3. current alternatives are not as obvious;
4. some people seem to expect it.

Anti:
1. unneeded; del l[:] or l[:]=[] do same already.

Guido: (python-ideas list, 'Set Syntax' thread, today)
"FWIW I'm fine with adding list.clear() to 3.3."

----------
components: Interpreter Core
messages: 122251
nosy: terry.reedy
priority: normal
severity: normal
stage: unit test needed
status: open
title: Add list.clear()
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 24 01:24:19 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 24 Nov 2010 00:24:19 +0000
Subject: [New-bugs-announce] [issue10517] test_concurrent_futures crashes
	with "Fatal Python	error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

py3k built from trunk on Centos 5.5 freezes during regrtest on test_concurrent_futures with "Fatal Python error: Invalid thread state for this thread".

A set of hopefully useful diagnostic logs attached as patch.

----------
assignee: bquinlan
components: Extension Modules
files: concurrent-futures-freeze.tar.bz2
messages: 122254
nosy: bquinlan, lukasz.langa
priority: critical
severity: normal
status: open
title: test_concurrent_futures crashes with "Fatal Python error: Invalid thread state for this thread"
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19792/concurrent-futures-freeze.tar.bz2

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

From report at bugs.python.org  Wed Nov 24 14:05:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 13:05:25 +0000
Subject: [New-bugs-announce] [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>


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

It was just resting. Here is a patch to wake it up for 3.2 (or 3.3 pending moratorium interpretation).

As for the py3k warning in 2.x (and the 2to3 fixer), it's not obvious what we should do: callable() clearly doesn't exist in 3.0 and 3.1.

----------
assignee: georg.brandl
components: Interpreter Core
files: callable.patch
keywords: patch
messages: 122273
nosy: benjamin.peterson, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Bring back callable()
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19795/callable.patch

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

From report at bugs.python.org  Wed Nov 24 14:21:52 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 24 Nov 2010 13:21:52 +0000
Subject: [New-bugs-announce] [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Probably a typo in setobject.c.

The patch attached here does not really change anything but fixes the typo, leading to slightly clearer code and avoiding one level of recursion.  All tests still pass.

----------
components: Interpreter Core
files: diff1
messages: 122274
nosy: arigo
priority: normal
severity: normal
status: open
title: setobject.c no-op typo
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19796/diff1

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

From report at bugs.python.org  Wed Nov 24 15:00:02 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Nov 2010 14:00:02 +0000
Subject: [New-bugs-announce] [issue10520] Build with --enable-shared fails
Message-ID: <1290607202.61.0.672349288392.issue10520@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: skrah
priority: normal
severity: normal
status: open
title: Build with --enable-shared fails

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

From report at bugs.python.org  Wed Nov 24 16:25:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Nov 2010 15:25:25 +0000
Subject: [New-bugs-announce] [issue10521] str methods don't accept non-BMP
	fillchar on a narrow	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> 'xyz'.center(20, '\U00100140')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: The fill character must be exactly one character long

str.ljust and str.rjust are similarly affected.

----------
components: Interpreter Core
messages: 122280
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: str methods don't accept non-BMP fillchar on a narrow Unicode build
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov 24 16:31:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 15:31:07 +0000
Subject: [New-bugs-announce] [issue10522] test_telnet exception
In-Reply-To: <1290612667.85.0.353730083287.issue10522@psf.upfronthosting.co.za>
Message-ID: <1290612667.85.0.353730083287.issue10522@psf.upfronthosting.co.za>


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

This has just occurred on the Solaris buildbot:

test_telnetlib
Exception in thread Thread-452:
Traceback (most recent call last):
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/threading.py", line 483, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/test/test_telnetlib.py", line 41, in server
    conn.close()
UnboundLocalError: local variable 'conn' referenced before assignment

----------
components: Tests
messages: 122281
nosy: jackdied, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_telnet exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 24 22:47:47 2010
From: report at bugs.python.org (Michal Pomorski)
Date: Wed, 24 Nov 2010 21:47:47 +0000
Subject: [New-bugs-announce] [issue10523] argparse has problem parsing
	option files containing	empty rows
In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>
Message-ID: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>


New submission from Michal Pomorski <misieck at gmail.com>:

When using the argument file option, i.e  @file_with_arguments the following problems arise:

1. argparse crashes when the file contains an empty line (even if it is the last line) - arg_string[0] is done when arg_string is empty. 
    This is caused by the use of splitlines() instead of strip().split() in the function _read_args_from_files(self, arg_strings)

2. options separated by spaces in one row are passed as a single long option, meaning each option has to be on its own line.
    This is caused by the new function 
   def convert_arg_line_to_args(self, arg_line):
        return [arg_line]
   which should be 
        return arg_line.split()


Both problems are caused by a modification in
    def _read_args_from_files(self, arg_strings)
The version from argparse 1.0.1 worked well and was correct, it should be sufficient to reverse the changes done from 1.0.1 to 1.1.

Here is the old implementation:

    def _read_args_from_files(self, arg_strings):
        # expand arguments referencing files
        new_arg_strings = []
        for arg_string in arg_strings:

            # for regular arguments, just add them back into the list
            if arg_string[0] not in self.fromfile_prefix_chars:
                new_arg_strings.append(arg_string)

            # replace arguments referencing files with the file content
            else:
                try:
                    args_file = open(arg_string[1:])
                    try:
                        arg_strings = args_file.read().strip().split()
                        arg_strings = self._read_args_from_files(arg_strings)
                        
                        new_arg_strings.extend(arg_strings)
                    finally:
                        args_file.close()
                except IOError:
                    err = _sys.exc_info()[1]
                    self.error(str(err))

        # return the modified argument list
        return new_arg_strings

----------
components: Library (Lib)
messages: 122314
nosy: Michal.Pomorski
priority: normal
severity: normal
status: open
title: argparse has problem parsing option files containing empty rows
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 24 23:00:29 2010
From: report at bugs.python.org (=?utf-8?b?T251ciBLw7zDp8O8aw==?=)
Date: Wed, 24 Nov 2010 22:00:29 +0000
Subject: [New-bugs-announce] [issue10524] Patch to add Pardus to supported
	dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>


New submission from Onur K???k <onur at pardus.org.tr>:

Attached patch adds Pardus to supported dists in platform. Diff is against current release27-maint, but it applies to release31-maint and py3k too.

----------
components: Library (Lib)
files: pardus_platform_release27-maint.patch
keywords: patch
messages: 122315
nosy: zaburt
priority: normal
severity: normal
status: open
title: Patch to add Pardus to supported dists in platform
Added file: http://bugs.python.org/file19801/pardus_platform_release27-maint.patch

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

From report at bugs.python.org  Thu Nov 25 06:44:21 2010
From: report at bugs.python.org (Dafydd Crosby)
Date: Thu, 25 Nov 2010 05:44:21 +0000
Subject: [New-bugs-announce] [issue10525] Added mouse and colour support to
	Game of Life curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>


New submission from Dafydd Crosby <dtcrsby at gmail.com>:

I was just going through the source of the curses demo Game of Life (life.py), and saw that the TODO had mouse support and colour.

I created a patch that adds those two wishlist items. Given that mouse support and the use of curses.flash() are missing from the demo programs, I think it's a bit of an upgrade ;-)

----------
components: Demos and Tools
files: mouse_and_colour.diff
keywords: patch
messages: 122332
nosy: Dafydd.Crosby
priority: normal
severity: normal
status: open
title: Added mouse and colour support to Game of Life curses demo
type: behavior
Added file: http://bugs.python.org/file19808/mouse_and_colour.diff

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

From orsenthil at gmail.com  Thu Nov 25 07:11:19 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 25 Nov 2010 14:11:19 +0800
Subject: [New-bugs-announce] [issue10525] Added mouse and colour support
 to Game of Life curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
References: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
	<1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <20101125061119.GB1239@rubuntu>

On Thu, Nov 25, 2010 at 05:44:21AM +0000, Dafydd Crosby wrote:
> I created a patch that adds those two wishlist items. Given that
> mouse support and the use of curses.flash() are missing from the
> demo programs, I think it's a bit of an upgrade ;-)
> 

Pretty cool. Do you think, the '*' themselves should be colored or
randomly colored? ( No, I have not seen a Game of 'Random-Colored' life )

-- 

From report at bugs.python.org  Thu Nov 25 11:45:42 2010
From: report at bugs.python.org (Petter Remen)
Date: Thu, 25 Nov 2010 10:45:42 +0000
Subject: [New-bugs-announce] [issue10526] Minor typo in What's New in Python
	2.7
In-Reply-To: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>
Message-ID: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>


New submission from Petter Remen <petter.remen at gmail.com>:

There's a word missing in section "PEP 372: Adding an Ordered Dictionary to collections"

The ConfigParser module uses them by default, meaning that
configuration files can now read, modified, and then written [...]
                        ~~~~~~~~

should be "now be read".

----------
assignee: docs at python
components: Documentation
messages: 122347
nosy: Petter.Remen, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in What's New in Python 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 25 12:15:13 2010
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Thu, 25 Nov 2010 11:15:13 +0000
Subject: [New-bugs-announce] [issue10527] multiprocessing.Pipe problem:
	"handle out of range in	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>


New submission from Gergely K?lm?n <kalman.gergely at duodecad.hu>:

Hello,

I have a code that uses multiprocessing.Pipe to communicate with subprocesses. Spawning 500 subprocesses this way works like a charm, but when spawning about 600 of them the pipe ends raise the exception: "handle out of range in select()". I realized that this is because of the FD_SETSIZE limit. To address the situation I quickly hacked together a patch that uses poll() instead of select(), which solves the problem for me. I don't know the reason why select() was chosen for this task (maybe because of windows) but wouldn't it be better to use polling where possible?

I've attached the tester. Beware, running it may use up all memory in your system, so be careful!

Gergely Kalman

----------
components: Library (Lib)
files: tester.py
messages: 122349
nosy: synapse
priority: normal
severity: normal
status: open
title: multiprocessing.Pipe problem: "handle out of range in select()"
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19813/tester.py

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

From report at bugs.python.org  Thu Nov 25 13:25:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:25:39 +0000
Subject: [New-bugs-announce] [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When you run xgettext other argparse.py, you get this warning:
?'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments.  Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments.?

I don?t know if people already rely on strings from argparse, but for safety I think we should change them only in 3.2, if Steven agrees.

(I have to check other stdlib modules.)

----------
components: Library (Lib)
messages: 122357
nosy: belopolsky, bethard, eric.araujo
priority: normal
severity: normal
status: open
title: argparse uses %s in gettext calls
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 13:28:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:28:09 +0000
Subject: [New-bugs-announce] [issue10529] Write argparse i18n howto
In-Reply-To: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>
Message-ID: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

argparse helpfully makes its messages with gettext.gettext.  The docs should explain how to benefit from that in one?s program.

----------
assignee: docs at python
components: Documentation
messages: 122358
nosy: bethard, docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Write argparse i18n howto
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 16:16:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 15:16:55 +0000
Subject: [New-bugs-announce] [issue10530] distutils2 should allow the
	installing of python files	with invalid syntax
In-Reply-To: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>
Message-ID: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

As discussed with tarek. It shouldn't be up to distutils2 to decide whether or not a Python file that has been included in the package should be installed or not if it is included in the set of files the developer has *asked* to be installed.

Possible use cases include deliberately broken modules for testing or an ast-transformer import hook that works with otherwise-invalid syntax files. (e.g. transforming the with statement to work on Python 2.4)

Allowing for the install of invalid syntax files will require ignoring SyntaxErrors during bytecode compile phase. A --strict option could be provided to allow these to remain an error.

----------
assignee: tarek
components: Distutils2
messages: 122372
nosy: eric.araujo, michael.foord, tarek
priority: normal
severity: normal
status: open
title: distutils2 should allow the installing of python files with invalid syntax

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

From report at bugs.python.org  Thu Nov 25 17:36:14 2010
From: report at bugs.python.org (Yingjie)
Date: Thu, 25 Nov 2010 16:36:14 +0000
Subject: [New-bugs-announce] [issue10531] write tilted text in turtle
In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>
Message-ID: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>


New submission from Yingjie <lanyjie at yahoo.com>:

First of all, I'd like to express my deep gratidute to the author of this module, it is such a fun module to work with and to teach python as a first programming language.

Secondly, I would like to request a feature if it is not too hard to achieve. Currently, you can only write texts horizontally, no matter what is the current orientation of the turtle pen. I wonder if it is possible to write text in any direction when we control the heading of the turtle? For example, the following code would write a vertically oriented text:

>>> setheading(90) #turtle facing up
>>> write("vertical text!")

Thanks a lot!

Yingjie

----------
components: Library (Lib)
messages: 122379
nosy: lanyjie
priority: normal
severity: normal
status: open
title: write tilted text in turtle
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 17:39:15 2010
From: report at bugs.python.org (Yingjie)
Date: Thu, 25 Nov 2010 16:39:15 +0000
Subject: [New-bugs-announce] [issue10532] A bug related to matching the
	empty string
In-Reply-To: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>
Message-ID: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>


New submission from Yingjie <lanyjie at yahoo.com>:

Here are some puzzling results I have got (I am using Python 3, I suppose similar results for python 2).

When I do the following, I got an exception:
>>> re.findall('(d*)*', 'adb')
>>> re.findall('((d)*)*', 'adb')

When I do this, I am fine but the result is wrong:
>>> re.findall('((.d.)*)*', 'adb')
[('', 'adb'), ('', '')]

Why is it wrong?

The first mactch of groups:
('', 'adb')
indicates the outer group ((.d.)*) captured
the empty string, while the inner group (.d.)
captured 'adb', so the outer group must have
captured the empty string at the end of the
provided string 'adb'.

Once we have matched the final empty string '',
there should be no more matches, but we got
another match ('', '')!!!

So, findall matched the empty string in
the end of the string twice!!!

Isn't this a bug?

Yingjie

----------
components: Regular Expressions
messages: 122380
nosy: lanyjie
priority: normal
severity: normal
status: open
title: A bug related to matching the empty string
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 18:00:49 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 25 Nov 2010 17:00:49 +0000
Subject: [New-bugs-announce] [issue10533] defaultdict constructor with a
	concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Currently the constructor in defaultdict only accepts factories. It would be very handy to allow for concrete values as well. It's implementable either by checking if the argument is callable or by a new keyword argument.

----------
assignee: lukasz.langa
components: Library (Lib)
keywords: easy
messages: 122382
nosy: holdenweb, lukasz.langa, michael.foord
priority: low
severity: normal
status: open
title: defaultdict constructor with a concrete value
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 21:20:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 25 Nov 2010 20:20:58 +0000
Subject: [New-bugs-announce] [issue10534] difflib.SequenceMatcher: expose
	junk sets, deprecate undocumented isb... functions.
In-Reply-To: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>
Message-ID: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Expose and document the junk and popular sets as attributes of the SequenceMatcher object.

self.junk = junk
self.popular = popular

Deprecate the then unneeded and undocumented isbjunk and isbpopular functions, currently defined as
    self.isbjunk = junk.__contains__
    self.isbpopular = popular.__contains__
(and slightly modify the matcher function that localizes and uses one of the above).

Question, (how) do we  document deprecation/removal of undocumented function?

In discussions that included Tim Peters, the idea of exposing the tuning parameters of the heuristic was discussed. Now that the heuristic can be turned off, I think this is YAGNI until someone specifically requests it.

----------
assignee: terry.reedy
messages: 122400
nosy: eli.bendersky, hodgestar, terry.reedy
priority: normal
severity: normal
stage: unit test needed
status: open
title: difflib.SequenceMatcher: expose junk sets, deprecate undocumented isb... functions.
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 25 23:08:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 22:08:36 +0000
Subject: [New-bugs-announce] [issue10535] Enable warnings by default in
	unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Warnings should be on by default in unittest so that developers can see them while running the tests even if they are silenced by default in Python.

The plan is to add a "warnings" argument to TestProgram and the default TextTestRunner:
  * if the argument is passed always use it as a filter (e.g. default, ignore, all, ...) for warnings;
  * if the argument is not passed and sys.warnoptions is not [] (i.e. python has been called with "-W something") don't do anything (i.e. use the warnings specified by -W);
  * if the argument is not passed and sys.warnoptions is [], use 'default' (i.e. show warnings).

In order to prevent floods of warnings when the deprecated assertEquals, assert_, etc. are used (see #9424), a new type of warning could be created (e.g. _UnittestDeprecationWarning) and filtered so that these warnings are printed only once.

----------
assignee: ezio.melotti
messages: 122411
nosy: brett.cannon, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable warnings by default in unittest
type: feature request

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

From report at bugs.python.org  Fri Nov 26 01:22:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 00:22:04 +0000
Subject: [New-bugs-announce] [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

A patch made for #2504 revealed a bug in gettext.rst, and I?ve found a number of other things to change in the file.  This is the first patch of a series of two or three.

Barry, as the original author of the module and doc, I?d like your opinion on points 3, a, and b particularly.

Patch is also uploaded to Rietveld for greater convenience: http://codereview.appspot.com/3333042/ (upload.py rocks)

Summary:

1) Markup: Use modern class/method directives combo (yay DRY).  Mark up variable parts in :file: constructs (e.g. :file:`{domain}.mo` will cause the HTML output to use var to indicate replaceable text).  Also change some ``gettext`` to :program:`gettext` for consistency.

2) Fix a typo in lngettext doc (originally included in patch by Franz Glasner for #2504).

3) I had started to remove information about private attributes (_info, _charset), advertising public getter methods instead.  Then I read the description of NullTranslations and realized the information was needed for subclasses.  I?ve reverted my removals, but I still think the private attributes should be listed in a specific section for people writing subclasses and not in the rest of the text.  If you?re okay, I?ll make a second patch.

4) Assorted wording changes, missing periods and hyphens, and other very small touch-ups: Turned a broken bare link into a working link with nice text; used the with statement in an example (we all love the with statement!); used two spaces after periods throughout (hello Fred Drake).

Final note: lines have not been rewrapped, for diff clarity.  When I commit part or all of this patch, I?ll make another commit to rewrap.


Not addressed:
a) The current docs is currently POSIX-specific.

b) The docs take great care to explain that Unicode strings will be returned in different places, but this should not be so accented in 3.x docs IMO.  I would just put a note somewhere near the top that all strings are str and remove the redundant sentences.  Following that line of thought, I could group all l*gettext variants at the end of the list of methods, explaining that regular usage should just be happy with str objects and that l*gettext are available if people really want bytes.

c) The file uses ?built-in namespace? and ?builtins namespace?, sometimes in neighbor paragraphs.  :mod:`builtins` is not used, even in explanations of the install function/method.  I don?t know if I should change that.

d) Some capitalization patterns look strange to me: I have seen ?I18N? and ?L10N? in upper case nowhere else.  Similarly, lower-case ?id? looks stranger than ?ID?.  The latter is used for example in official GNU gettext docs.  Am I going into foolish consistency territory or not?


Thanks in advance for reviews and opinions.

----------
assignee: eric.araujo
components: Documentation
files: gettext-docs-1.diff
keywords: needs review, patch
messages: 122420
nosy: barry, docs at python, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Enhancements to gettext docs
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19819/gettext-docs-1.diff

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

From report at bugs.python.org  Fri Nov 26 06:41:07 2010
From: report at bugs.python.org (Richard)
Date: Fri, 26 Nov 2010 05:41:07 +0000
Subject: [New-bugs-announce] [issue10537] IDLE crashes when you paste
	something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>


New submission from Richard <vanchagreen at gmail.com>:

Whenever I paste anything into the IDLE shell, the program freezes, and then crashes.

I'm using Python 2.7.1rcl with a Version 10.6.4 Mac OSX

----------
components: IDLE
messages: 122441
nosy: 5ragar5
priority: normal
severity: normal
status: open
title: IDLE crashes when you paste something.
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 26 09:07:33 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 26 Nov 2010 08:07:33 +0000
Subject: [New-bugs-announce] [issue10538] PyArg_ParseTuple("s*") does not
	always incref object
In-Reply-To: <1290758853.31.0.608837110631.issue10538@psf.upfronthosting.co.za>
Message-ID: <1290758853.31.0.608837110631.issue10538@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The new "s*" code for PyArg_ParseTuple is used to fill a Py_buffer object from the arguments.  This object must be relased using PyBuffer_Release() after use.

However, if the object in the tuple does not support the new buffer interface, the old buffer interface is queried and the Py_buffer object is manually filled in.  For this case, the source object is _not_ increfed and buffer.obj remains set to 0.

This causes different semantics in the function for objects that are passed in:  If the Py_buffer interface is supported directly, then it is safe for the function to store this and release this at a later time.  If it isn't supported, then no extra reference to the object is got and the function cannot safely keep the Py_buffer object around.

The Fix is as follows:  Change line 1402 of getargs.c from:
PyBuffer_FillInfo(view, NULL, buf, count, 1, 0);
to
PyBuffer_FillInfo(view, arg, buf, count, 1, 0);

----------
messages: 122445
nosy: krisvale
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple("s*") does not always incref object
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Nov 26 16:34:05 2010
From: report at bugs.python.org (Jamie Murray)
Date: Fri, 26 Nov 2010 15:34:05 +0000
Subject: [New-bugs-announce] [issue10539] Regular expression not checking
	'range' element on 1st	char in string.
In-Reply-To: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>
Message-ID: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>


New submission from Jamie Murray <txrxfx at gmail.com>:

The first char in a word is omitted from being checked against the 'range' element of the 1st part of this expression. 

The second char is properly checked to see if it's in range 

# Desired safe string to expect
goodString = "f42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

# Test string to return False if it's not within reg ex range.
# but still returns a false positive even though the g at the start is outside of a-f range.
badString = "g42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

# 2nd test string which does return a false result correctly.
otherBadString = "fg2e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

See attached file for example.

"Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on
win32"

----------
components: Regular Expressions
files: RegExPyBug.py
messages: 122461
nosy: TxRxFx
priority: normal
severity: normal
status: open
title: Regular expression not checking 'range' element on 1st char in string.
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file19823/RegExPyBug.py

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

From report at bugs.python.org  Fri Nov 26 17:00:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Nov 2010 16:00:35 +0000
Subject: [New-bugs-announce] [issue10540] test_shutil fails on Windows after
	r86733
In-Reply-To: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>
Message-ID: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

My build slave shows a test failure at test_dont_copy_file_onto_link_to_itself. This happens because the implementation of _samefile in Lib/shutil.py (line 70) doesn't work for Windows hard links.

Patch on the way.

----------
assignee: brian.curtin
components: Library (Lib), Windows
messages: 122462
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil fails on Windows after r86733
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov 26 17:02:14 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 26 Nov 2010 16:02:14 +0000
Subject: [New-bugs-announce] [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

Running regrtest.py with coverage option seems to be broken for the py3k branch at the moment. Run the following commands on the shell:

wget http://svn.python.org/snapshots/python3k.tar.bz2
tar xjf python3k.tar.bz2
cd python
./configure --enable-unicode=ucs4 --with-pydebug
make coverage
./python.exe Lib/test/regrtest.py -T -N test_urllib

This gives the following output:

[1/1] test_urllib
Not printing coverage data for 'Lib/test/regrtest.py': [Errno 2] No such file or directory: 'Lib/test/regrtest.py'
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1502, in <module>
    main()
  File "Lib/test/regrtest.py", line 698, in main
    r.write_results(show_missing=True, summary=True, coverdir=coverdir)
  File "/Users/walter/x/pybug/python/Lib/trace.py", line 331, in write_results
    with open(filename, 'rb') as fp:
IOError: [Errno 2] No such file or directory: 'Lib/test/regrtest.py'
[123146 refs]

I'm testing on Mac OS X 10.6.5.

Attached is the complete log of the shell session.

This bug might be related to issue 10329, as the failing line was introduced in r86303.

----------
assignee: haypo
components: Tests
files: build.log
messages: 122463
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: regrtest.py -T broken
Added file: http://bugs.python.org/file19824/build.log

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

From report at bugs.python.org  Fri Nov 26 17:16:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Nov 2010 16:16:07 +0000
Subject: [New-bugs-announce] [issue10542] Py_UNICODE_NEXT and other macros
	for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As discussed in issue 10521 and the sprawling "len(chr(i)) = 2?" thread [1] on python-dev, many functions in python library behave differently on narrow and wide builds.  While there are unavoidable differences such as the length of strings with non-BMP characters, many functions can work around these differences.  For example, the ord() function already produces integers over 0xFFFF when given a surrogate pair as a string of length two on a narrow build.  Other functions such as str.isalpha(), are not yet aware of surrogates.  See also issue9200.

A consensus is developing that non-BMP characters support on narrow builds is here to stay and that naive functions should be fixed.  Unfortunately, working with surrogates in python code is tricky because unicode C-API does not provide much support and existing examples of surrogate processing look like this:

-        while (u != uend && w != wend) {
-            if (0xD800 <= u[0] && u[0] <= 0xDBFF
-                && 0xDC00 <= u[1] && u[1] <= 0xDFFF)
-            {
-                *w = (((u[0] & 0x3FF) << 10) | (u[1] & 0x3FF)) + 0x10000;
-                u += 2;
-            }
-            else {
-                *w = *u;
-                u++;
-            }
-            w++;
-        }

The attached patch introduces a Py_UNICODE_NEXT() macro that allows replacing the code above with two lines:

+        while (u != uend && w != wend)
+            *w++ = Py_UNICODE_NEXT(u, uend);

The patch also introduces a set of macros for manipulating the surrogates, but I have not started replacing more instances of verbose surrogate processing because I would like to first look for higher level abstractions such as Py_UNICODE_NEXT().  For example, there are many instances that can benefit from Py_UNICODE_PUT_NEXT(ptr, ch) macro that would put a UCS4 character ch into Py_UNICODE buffer pointed by ptr and advance ptr by 1 or 2 units as necessary.


[1] http://mail.python.org/pipermail/python-dev/2010-November/105908.html

----------
assignee: belopolsky
components: Extension Modules, Interpreter Core, Unicode
files: unicode-next.diff
keywords: patch
messages: 122464
nosy: Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Py_UNICODE_NEXT and other macros for surrogates
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19825/unicode-next.diff

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

From report at bugs.python.org  Fri Nov 26 17:58:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 26 Nov 2010 16:58:58 +0000
Subject: [New-bugs-announce] [issue10543] Test discovery (unittest) does not
	work with jython
In-Reply-To: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>
Message-ID: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

This is because jython creates bytecode files with names like "tests/testwith$py.class". unittest test discovery splits the extension off __file__ to compare module.__file__ to the expected path.

----------
messages: 122467
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Test discovery (unittest) does not work with jython

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

From report at bugs.python.org  Fri Nov 26 20:21:19 2010
From: report at bugs.python.org (Inyeol Lee)
Date: Fri, 26 Nov 2010 19:21:19 +0000
Subject: [New-bugs-announce] [issue10544] yield expression inside generator
	expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>


New submission from Inyeol Lee <inyeol.lee at gmail.com>:

Simple coroutine with for loop works:

>>> def pack_a():
        while True:
            L = []
            for i in range(2):
                L.append((yield))
            print(L)

>>> pa = pack_a()
>>> next(pa)
>>> pa.send(1)
>>> pa.send(2)
[1, 2]
>>>

If using list comprehension (generator expression), it fails:

>>> def pack_b():
        while True:
            L = [(yield) for i in range(2)]
            print(L)

>>> pb = pack_b()
<endless loop here>


I understand what's going on here - generator expression is converted to nested function and there's no way to either stop the execution inside nested function (since it's not started yet!) or send() a value to its yield expression. Still I think this behavior is a bug and needs fixed.

- best fix would make it behave the same as for loop.
- if it's not fixable, yield expression inside genexp should not be allowed.

----------
components: Interpreter Core
messages: 122475
nosy: Inyeol.Lee
priority: normal
severity: normal
status: open
title: yield expression inside generator expression does nothing
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Fri Nov 26 21:50:32 2010
From: report at bugs.python.org (rurpy the second)
Date: Fri, 26 Nov 2010 20:50:32 +0000
Subject: [New-bugs-announce] [issue10545] remove or rewrite "Using Backslash
	to Continue	Statements" anti-idiom
In-Reply-To: <1290804632.88.0.494003444216.issue10545@psf.upfronthosting.co.za>
Message-ID: <1290804632.88.0.494003444216.issue10545@psf.upfronthosting.co.za>


New submission from rurpy the second <rurpy at yahoo.com>:

The Python HOWTOs->Idioms and Anti-Idioms has a section
"Using Backslash to Continue Statements".

It says that line continuation is "dangerous" and gives two reasons.

1. Hard to see a space after the backslash.

This is not "dangerous" as it cause an impossible-to-miss syntax 
error (as pointed out in the following sentence.)

2. It can cause other "subtle" errors. 

It gives a code example purporting to demonstrate this but without
saying what the input data to the code is or what the resulting
problem is.  I spent a while trying to figure it out unsuccessfully.

In  
http://www.mail-archive.com/python-list at python.org/msg249344.html
a number of c.l.p regulars did not figure it out either.

I also note related bug http://bugs.python.org/issue7391 that points
out that avoinding backslashed continuations with parens is not 
always possible.

So I suggest...

1. If the the given example actually illustrates a real problem,
document clearly what it is.  This is a reference manual, not a
quiz book.

2. If not, then remove that argument.  Now the only reason for
not using backslashes is that a hard-to-see space after the
backslash will cause a syntax error.  That is neither dangerous
or a strong reason not to do it.  An unstated reason is that 
PEP-8 recommends against it but its recommendation is not absolute
and is based only on aethtetics.  With no real arguments against
using it other than style, it should not be documented as an anti-idiom, recommendations against it should remain only in
PEP-8 with other such style guidelines, and this section should 
be removed from the Anti-Idioms chapter.

----------
assignee: docs at python
components: Documentation
messages: 122477
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: remove or rewrite "Using Backslash to Continue Statements" anti-idiom

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

From report at bugs.python.org  Fri Nov 26 22:08:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Nov 2010 21:08:32 +0000
Subject: [New-bugs-announce] [issue10546] UTF-16-LE and UTF-16-BE support
	non-BMP characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python3 doc tells that UTF-16-LE and UTF-16-BE only support BMP characters. What? I think that it is wrong.

It was maybe wrong with Python2 and narrow build (unichr() only supports BMP characters), but it is no more true in Python3.

----------
assignee: docs at python
components: Documentation
files: utf_16_bmp.patch
keywords: patch
messages: 122479
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: UTF-16-LE and UTF-16-BE support non-BMP characters
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19830/utf_16_bmp.patch

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

From report at bugs.python.org  Sat Nov 27 14:47:51 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 13:47:51 +0000
Subject: [New-bugs-announce] [issue10547] FreeBSD: wrong value for LDSHARED
	in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On FreeBSD, the config variable LDSHARED contains the literal '${LDFLAGS}',
causing this failure in test_distutils:


'test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... gcc: ': No such file or directory
ERROR


The patch fixes the issue and all tests pass.


Benjamin, are you ok with the change for 2.7? I'm not sure why autoreconf
generated a bit of extra noise; I used version 2.65. Also, OpenBSD and
NetBSD should be affected as well.

----------
components: Build
files: freebsd_ldshared.patch
keywords: needs review, patch
messages: 122525
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: FreeBSD: wrong value for LDSHARED in sysconfig
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19836/freebsd_ldshared.patch

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

From report at bugs.python.org  Sat Nov 27 16:16:38 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Nov 2010 15:16:38 +0000
Subject: [New-bugs-announce] [issue10548] Error in setUp not reported as
	expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Reported by Konrad Delong.

class MyTest(unittest.TestCase):
    def setUp(self):
        raise Exception
    @unittest.expectedFailure
    def testSomething(self):
        assert False, "test method failed"




This code will report error, not expected failure.

----------
assignee: michael.foord
components: Library (Lib)
messages: 122530
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Error in setUp not reported as expectedFailure (unittest)
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Nov 27 17:37:52 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 27 Nov 2010 16:37:52 +0000
Subject: [New-bugs-announce] [issue10549] help(cls1) breaks when cls1 has
	staticmethod(cls2)	attribute
In-Reply-To: <1290875872.01.0.0960712603698.issue10549@psf.upfronthosting.co.za>
Message-ID: <1290875872.01.0.0960712603698.issue10549@psf.upfronthosting.co.za>


New submission from Milko Krachounov <python at milko.3mhz.net>:

If I make a class B, and add staticmethod(A) as an attribute when B is another class, help(B) breaks. The issue appears with Python 2.6.6, trunk, 3.1.3c1, and py3k SVN.

Python 2.7 (trunk:86836, Nov 27 2010, 18:23:07) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
...     pass
... 
>>> class B(object):
...     attr = staticmethod(A)
... 
>>> help(B)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/milko/?????/Python/trunk/Lib/site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1720, in __call__
    self.help(request)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1767, in help
    else: doc(request, 'Help on %s:')
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1508, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1503, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 327, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1216, in docclass
    lambda t: t[1] == 'static method')
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1162, in spill
    name, mod, object))
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 327, in document
    if inspect.isclass(object): return self.docclass(*args)
TypeError: docclass() takes at most 4 arguments (5 given)

Python 3.2a4+ (py3k:86836, Nov 27 2010, 18:35:01) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     pass
... 
>>> class B:
...     attr = staticmethod(A)
... 
>>> help(B)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/milko/?????/Python/py3k/Lib/site.py", line 447, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1713, in __call__
    self.help(request)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1760, in help
    else: doc(request, 'Help on %s:')
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1504, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1499, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 319, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1214, in docclass
    lambda t: t[1] == 'static method')
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1159, in spill
    name, mod, object))
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 319, in document
    if inspect.isclass(object): return self.docclass(*args)
TypeError: docclass() takes at most 4 positional arguments (5 given)

----------
components: Library (Lib)
messages: 122535
nosy: milko.krachounov
priority: normal
severity: normal
status: open
title: help(cls1) breaks when cls1 has staticmethod(cls2) attribute
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Nov 27 19:40:27 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 18:40:27 +0000
Subject: [New-bugs-announce] [issue10550] Windows: leak in
	test_concurrent_futures
In-Reply-To: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>
Message-ID: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

C:\Users\stefan\svn\py3k_64>PCbuild\amd64\python_d.exe Lib\test\regrtest.py -R : test_concurrent_futures
[1/1] test_concurrent_futures
beginning 9 repetitions
123456789
.........
test_concurrent_futures leaked [6912, 6912, 6912, 6912] references, sum=27648
1 test failed:
    test_concurrent_futures
[195615 refs]

----------
components: Extension Modules
messages: 122539
nosy: skrah
priority: normal
severity: normal
status: open
title: Windows: leak in test_concurrent_futures
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 27 20:15:26 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Sat, 27 Nov 2010 19:15:26 +0000
Subject: [New-bugs-announce] [issue10551] mimetypes reading from registry in
	windows completely	broken
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>


New submission from Kovid Goyal <kovid at kovidgoyal.net>:

Hi,

I am the primary developer of calibre (http:/calibre-ebook.com) and yesterday I released an upgrade of calibre based on python 2.7. Here is a small sampling of all the diverse errors that my users experienced, related to reading mimetypes from the registry:

1. Permission denied if running from non privileged account
Traceback (most recent call last):
File "site.py", line 103, in main
File "site.py", line 84, in run_entry_point
File "site-packages\calibre\__init__.py", line 31, in <module>
File "mimetypes.py", line 344, in add_type
File "mimetypes.py", line 355, in init
File "mimetypes.py", line 261, in read_windows_registry
WindowsError: [Error 5] Acceso denegado (Access not allowed)

The fix for this is to trap WindowsError and ignore it in mimetypes.py

2. Mishandling of encoding of registry entries

Traceback (most recent call last):      
  File "site.py", line 103, in main     
  File "site.py", line 84, in run_entry_point
  File "site-packages\calibre\__init__.py", line 31, in <module>                                                
  File "mimetypes.py", line 344, in add_type                                                                
  File "mimetypes.py", line 355, in init                                                                    
  File "mimetypes.py", line 260, in read_windows_registry                                                   
  File "mimetypes.py", line 250, in enum_types                                                              
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 0: invalid continuation byte

The fix for this is to change

except UnicodeEncodeError

to

except ValueError

3. python -c "import mimetypes; print mimetypes.guess_type('img.jpg')"
('image/pjpeg', None)

Where the output should have been

(image/jpeg', None)

The fix for this is to load the registry entries before the default entris defined in mimetypes.py


Of course, IMHO, the best possible fix is to simply remove the reading of mimetypes from the registry. But that is up to whoever maintains this module. 

Duplicate (less comprehensive) tickets ont his isuue in your traceker already are: 9291, 10490, 104314

If the maintainer of this module is unable to fix these issues, let me know and I will submit a patch, either removing _winreg or fixing the issues individually.

----------
components: Library (Lib)
messages: 122542
nosy: kovid
priority: normal
severity: normal
status: open
title: mimetypes reading from registry in windows completely broken
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 27 21:29:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 20:29:13 +0000
Subject: [New-bugs-announce] [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ ../../python.exe gencodec.py MAPPINGS/VENDORS/MISC/ build/
converting APL-ISO-IR-68.TXT to build/apl_iso_ir_68.py and build/apl_iso_ir_68.mapping
converting ATARIST.TXT to build/atarist.py and build/atarist.mapping
converting CP1006.TXT to build/cp1006.py and build/cp1006.mapping
converting CP424.TXT to build/cp424.py and build/cp424.mapping
Traceback (most recent call last):
  File "gencodec.py", line 421, in <module>
    convertdir(*sys.argv[1:])
  File "gencodec.py", line 391, in convertdir
    pymap(mappathname, map, dirprefix + codefile,name,comments)
  File "gencodec.py", line 355, in pymap
    code = codegen(name,map,encodingname,comments)
  File "gencodec.py", line 268, in codegen
    precisions=(4, 2))
  File "gencodec.py", line 152, in python_mapdef_code
    mappings = sorted(map.items())
TypeError: unorderable types: NoneType() < int()

It does appear to have been updated for 3.x:

$ python2.7 gencodec.py MAPPINGS/VENDORS/MISC/ build/
Traceback (most recent call last):
  File "gencodec.py", line 35, in <module>
    UNI_UNDEFINED = chr(0xFFFE)
ValueError: chr() arg not in range(256)

----------
components: Demos and Tools
messages: 122549
nosy: belopolsky, lemburg
priority: normal
severity: normal
status: open
title: Tools/unicode/gencodec.py error
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 27 21:38:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Nov 2010 20:38:50 +0000
Subject: [New-bugs-announce] [issue10553] Add optimize argument to builtin
	compile() and	byte-compilation modules
In-Reply-To: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>
Message-ID: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This patch adds an "optimize" parameter to compile(), as discussed in <http://mail.python.org/pipermail/python-ideas/2010-November/008784.html>.

I also needed to introduce two new C APIs.  Better naming suggestions are welcome.

----------
components: Library (Lib)
files: compile-optimize.diff
keywords: patch
messages: 122552
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add optimize argument to builtin compile() and byte-compilation modules
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19840/compile-optimize.diff

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

From report at bugs.python.org  Sat Nov 27 21:47:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 20:47:40 +0000
Subject: [New-bugs-announce] [issue10554] Context managerment support for
	subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I propose that __enter__ and __exit__ be added to subprocess.Popen.  __enter__ returns self, __exit__ closes open file descriptors.

__exit__ could also do the same checks that __del__ does (and which I don?t entirely understand.

See also os.popen (os._wrap_close).

----------
components: Library (Lib)
keywords: easy
messages: 122554
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Context managerment support for subprocess.Popen
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sat Nov 27 22:42:03 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Sat, 27 Nov 2010 21:42:03 +0000
Subject: [New-bugs-announce] [issue10555] Fatal Python error: Interpreter
	not initialized (version	mismatch?)
In-Reply-To: <1290894123.11.0.895090468889.issue10555@psf.upfronthosting.co.za>
Message-ID: <1290894123.11.0.895090468889.issue10555@psf.upfronthosting.co.za>


New submission from Anurag Chourasia <anurag.chourasia at gmail.com>:

Python extensions build on AIX 5.3 with GCC 4.2 fails.

The configure command was as follows

./configure --enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses" LDFLAGS="-L. -L/usr/local/lib"

The error during the make step was as follows

running build
running build_ext
ldd: /lib/libreadline.a: File is an archive.
building dbm using ndbm
INFO: Can't locate Tcl/Tk libs and/or headers
building '_struct' extension
creating build
creating build/temp.aix-5.3-2.7
creating build/temp.aix-5.3-2.7/u01
creating build/temp.aix-5.3-2.7/u01/home
creating build/temp.aix-5.3-2.7/u01/home/apli
creating build/temp.aix-5.3-2.7/u01/home/apli/wm
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/freeware/include -I/opt/freeware/include/readline -I/opt/freeware/include/ncurses -I/usr/local/include -I/u01/home/apli/wm/GDD/Python-2.7/Include -I/u01/home/apli/wm/GDD/Python-2.7 -c /u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.c -o build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.o
creating build/lib.aix-5.3-2.7
./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp -L. -L/usr/local/lib build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.o -L. -L/usr/local/lib -lpython2.7 -o build/lib.aix-5.3-2.7/_struct.so
Fatal Python error: Interpreter not initialized (version mismatch?)
make: 1254-059 The signal code from the last command is 6.


The file build/lib.aix-5.3-2.7/_struct.so is present after this error. 

The error seems to be in importing the module that was just built. Here is the error message from the python executable that was built.

root [zibal]% pwd
/u01/home/apli/wm/GDD/Python-2.7
root [zibal]% which python
./python
root [zibal]% python
Python 2.7 (r27:82500, Nov 27 2010, 18:33:21)
[GCC 4.2.4] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
Fatal Python error: Interpreter not initialized (version mismatch?)
IOT/Abort trap(coredump)

This is also an error in Version 2.6.6

I don't have any other conflicting python library that might cause this.

----------
components: Build
messages: 122561
nosy: Anurag.Chourasia
priority: normal
severity: normal
status: open
title: Fatal Python error: Interpreter not initialized (version mismatch?)
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 28 00:21:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 23:21:08 +0000
Subject: [New-bugs-announce] [issue10556] test_zipimport_support mucks up
	with modules
In-Reply-To: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>
Message-ID: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>


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

This test failure is due to test_zipimport_support loading and unloading modules, which leads to them being reloaded. Then the ssl.CertificateError which is checked for by assertRaises isn't the same as the one raised by the module under test (I have printed the type names and ids below):

$ ./python -E -bb -m test.regrtest test_http_cookies test_zipimport_support test_httplib
[1/3] test_http_cookies
[2/3] test_zipimport_support
[3/3] test_httplib
<class 'ssl.CertificateError'> 49243264
<class 'ssl.CertificateError'> 51134640
test test_httplib failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_httplib.py", line 481, in test_local_bad_hostname
    h.request('GET', '/')
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 950, in request
    self._send_request(method, url, body, headers)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 988, in _send_request
    self.endheaders(body)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 946, in endheaders
    self._send_output(message_body)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 791, in _send_output
    self.send(msg)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 737, in send
    self.connect()
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 1096, in connect
    ssl.match_hostname(self.sock.getpeercert(), self.host)
  File "/home/antoine/py3k/__svn__/Lib/ssl.py", line 142, in match_hostname
    % (hostname, dnsnames[0]))
ssl.CertificateError: hostname 'localhost' doesn't match 'fakehostname'


(witnessed in http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/527/steps/test/logs/stdio )

----------
components: Tests
messages: 122590
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_zipimport_support mucks up with modules
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 28 04:22:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 03:22:26 +0000
Subject: [New-bugs-announce] [issue10557] Malformed error message from
	float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> float('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ?

>>> float('42?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError

With the attached patch, float-error.diff


>>> float('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): ?
>>> float('42?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): 42?

Note that the proposed patch also has an effect of disallowing non-ascii digits in float() constructor.

Before the patch:

>>> float('????.??')
1234.56

After the patch:

>>> float('????.??')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ????.??

I am not sure, whether support for non-ascii digits in float() constructor is worth maintaining.  (Anyone knows whether Arabic numbers are written right to left or left to right?  What is the proper decimal point character?)

Also, I don't think users expect UnicodeEncodeError from float() or int().

Before the patch:

>>> float('\uffff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\uffff' in position 0: invalid decimal Unicode string


After the patch:

>>> float('\uffff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ?

----------
components: Interpreter Core
files: float-error.diff
keywords: patch
messages: 122612
nosy: belopolsky, ezio.melotti, haypo, mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: Malformed error message from float()
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19848/float-error.diff

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

From report at bugs.python.org  Sun Nov 28 04:24:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Nov 2010 03:24:57 +0000
Subject: [New-bugs-announce] [issue10558] non-standard processing of several
	configure options	ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[From Issue10268]

The configure to Makefile option processing for a few options is non-standard.  For example, --enable-loadable-sqlite-extensions=no is treated the same as --enable-loadable-sqlite-extensions or --enable-loadable-sqlite-extensions=yes, contrary to standard Autoconf behavior. Reportedly, this behavior also occurs with --with-system-expat=no and --with-system-ffi=no options.

----------
components: Build
messages: 122613
nosy: Arfrever, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: non-standard processing of several configure options ignores "=no"
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 28 06:48:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:48:20 +0000
Subject: [New-bugs-announce] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

>From the docs@ mailing list:

?Tutorial 2.1.1: name 'sys' is not defined

When the student tells python to evaluate sys.argv[0] as described, she gets the following error: name 'sys' is not defined?

Imports have not been introduced yet, so I propose this simple change:

-left in ``sys.argv`` for  the command or module to handle.
+left in ``sys.argv`` for  the command or module to handle.  You need to
+execute ``import sys`` before you can reference ``sys.argv``.

I?m not committing directly because I?d like feedback: Is the wording okay for the beginning of the tutorial?

----------
assignee: eric.araujo
components: Documentation
keywords: needs review, patch
messages: 122635
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: NameError in tutorial/interpreter
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 28 12:17:57 2010
From: report at bugs.python.org (Carlo Bramini)
Date: Sun, 28 Nov 2010 11:17:57 +0000
Subject: [New-bugs-announce] [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>


New submission from Carlo Bramini <carlo.bramix at libero.it>:

Hello,
I was able to compile latest python sources with MSVC5, by importing and fixing a bit the project workspaces of MSVC6.
During this action I received some messages, so I gave a look to the sources and I would like to suggest the following fixes:

1) in posixmodule.c, I had a warning of constant out of range for secs_between_epochs.
The problem has been solved by applying "i64" suffix as suggested in MSDN for doing correct declaration of 64 bits constants.
While doing this fix, I took this chance for adding support for all currently supported platforms: MSVC, GCC and Watcom.

2) in posixmodule.c, I fixed a bit check_gfax() function:
- Function declaration has been fixed with 'void' in its parameter section (fixes a warning).
- I removed the variable 'checked' and I placed instead the handle to kernel32 module.
- I removed the L-value assignment: all other source codes in Python are already corrected in that manner, this is the last one that needs to be fixed.

3) in posixmodule.c, there is a bug in function Py_GetFileAttributesExW(): it tests for 'gfaxa' but later it uses 'gfaxw'.

4) in dl_nt.c, I fixed function prototypes with "void" (solves a warning).

5) in dl_nt.c, in function _LoadActCtxPointers(), I do not see a good reason for using widechar version of GetModuleHandle, since it just need to retrieve the instance of kernel32.

6) in dynload_win.c, I fixed _Py_ActivateActCtx prototype declaration (solves a warning).

7) in dynload_win.c, I suggest to rename local strcasecmp() to something less dangerous to prototype conflicts.

8) in dynload_win.c, in function _PyImport_GetDynLoadFunc() the first 'cookie' variable is not used, so its declaration has been removed.

I hope you will find this useful.

Sincerely,

Carlo Bramini.

----------
components: Windows
files: python.txt
messages: 122651
nosy: Carlo_Bramini
priority: normal
severity: normal
status: open
title: Fixes for Windows sources
Added file: http://bugs.python.org/file19853/python.txt

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

From report at bugs.python.org  Sun Nov 28 12:38:56 2010
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 28 Nov 2010 11:38:56 +0000
Subject: [New-bugs-announce] [issue10561] The pdb command 'clear bpnumber'
	may delete more than	one breakpoint
In-Reply-To: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>
Message-ID: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Description:
------------
1. When deleting a single breakpoint, all the breakpoints located on
   the line of this breakpoint are also deleted. See the test case
   below.

2. The pdb 'clear' command documentation does not mention that all the
   breakpoints on a line can be deleted with the command:

        clear filename:lineno

See the proposed bdb patch and documentation patch below.


Test case:
----------
#####   File foobar.py   #####
def main():
    pass

if __name__ == '__main__':
    main()
#####   Test case   #####
xavier$ /usr/local/bin/python2.7
Python 2.7 (r27:82500, Jul 13 2010, 21:30:27)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb, foobar
>>> pdb.run('foobar.main()')
> <string>(1)<module>()
(Pdb) break foobar.main
Breakpoint 1 at /home/xavier/tmp/foobar.py:1
(Pdb) break foobar.main
Breakpoint 2 at /home/xavier/tmp/foobar.py:1
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xavier/tmp/foobar.py:1
2   breakpoint   keep yes   at /home/xavier/tmp/foobar.py:1
(Pdb) clear 1
Deleted breakpoint 1
(Pdb) break
(Pdb)
#########################


Patch:
------
Index: Doc/library/pdb.rst
===================================================================
--- Doc/library/pdb.rst	(revision 86836)
+++ Doc/library/pdb.rst	(working copy)
@@ -239,7 +239,8 @@
    Temporary breakpoint, which is removed automatically when it is first hit.  The
    arguments are the same as break.
 
-cl(ear) [*bpnumber* [*bpnumber ...*]]
+cl(ear) [*filename:lineno* | *bpnumber* [*bpnumber ...*]]
+   With a *filename:lineno* argument, clear all the breakpoints at this line.
    With a space separated list of breakpoint numbers, clear those breakpoints.
    Without argument, clear all breaks (but first ask confirmation).
 
Index: Lib/bdb.py
===================================================================
--- Lib/bdb.py	(revision 86836)
+++ Lib/bdb.py	(working copy)
@@ -250,6 +250,12 @@
             list.append(lineno)
         bp = Breakpoint(filename, lineno, temporary, cond, funcname)
 
+    def prune_breaks(self, filename, lineno):
+        if (filename, lineno) not in Breakpoint.bplist:
+            self.breaks[filename].remove(lineno)
+        if not self.breaks[filename]:
+            del self.breaks[filename]
+
     def clear_break(self, filename, lineno):
         filename = self.canonic(filename)
         if not filename in self.breaks:
@@ -261,10 +267,7 @@
         # pair, then remove the breaks entry
         for bp in Breakpoint.bplist[filename, lineno][:]:
             bp.deleteMe()
-        if (filename, lineno) not in Breakpoint.bplist:
-            self.breaks[filename].remove(lineno)
-        if not self.breaks[filename]:
-            del self.breaks[filename]
+        self.prune_breaks(filename, lineno)
 
     def clear_bpbynumber(self, arg):
         try:
@@ -277,7 +280,8 @@
             return 'Breakpoint number (%d) out of range' % number
         if not bp:
             return 'Breakpoint (%d) already deleted' % number
-        self.clear_break(bp.file, bp.line)
+        bp.deleteMe()
+        self.prune_breaks(bp.file, bp.line)
 
     def clear_all_file_breaks(self, filename):
         filename = self.canonic(filename)
===================================================================

----------
components: Library (Lib)
messages: 122652
nosy: xdegaye
priority: normal
severity: normal
status: open
title: The pdb command 'clear bpnumber' may delete more than one breakpoint
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 28 16:19:18 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 28 Nov 2010 15:19:18 +0000
Subject: [New-bugs-announce] [issue10562] Change 'j' for imaginary unit into
	an 'i'
In-Reply-To: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>
Message-ID: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

In Python, the letter 'j' denotes the imaginary unit. It would be great if we would follow mathematics in this regard and let the imaginary unit be denoted with an 'i'.

----------
components: Interpreter Core
messages: 122662
nosy: Retro
priority: normal
severity: normal
status: open
title: Change 'j' for imaginary unit into an 'i'
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Nov 28 16:47:20 2010
From: report at bugs.python.org (Gerrit Holl)
Date: Sun, 28 Nov 2010 15:47:20 +0000
Subject: [New-bugs-announce] [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>


New submission from Gerrit Holl <topjaklont at gmail.com>:

When the time passed to time.ctime is large, it adds a newline:

>>> import time
>>> time.ctime(2<<36)
'Wed Apr  8 17:04:32 6325'
>>> time.ctime(2<<37)
'Wed Jul 14 08:09:04 10680\n'

----------
components: Library (Lib)
messages: 122665
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: Spurious newline in time.ctime
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Nov 28 16:50:36 2010
From: report at bugs.python.org (Tom Quaile)
Date: Sun, 28 Nov 2010 15:50:36 +0000
Subject: [New-bugs-announce] [issue10564] maths float error
In-Reply-To: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>
Message-ID: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>


New submission from Tom Quaile <tom.quaile at gmail.com>:

Using IDLE 3.2a4
Apologies in advance for probably wasting your time. If I'm wrong, just ignore me. I'm very new to Python. Is this a bug, my processor or me? I'm sending this in as I see it's an alpha release.

If the user supplies 100 as the answer, I would have expected a result of 115 for a 15% tip. I get 114.999999999.

----------
files: tip.py
messages: 122667
nosy: ipcctv
priority: normal
severity: normal
status: open
title: maths float error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19856/tip.py

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

From report at bugs.python.org  Sun Nov 28 16:58:27 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 28 Nov 2010 15:58:27 +0000
Subject: [New-bugs-announce] [issue10565] isinstance(x,
	collections.Iterator) can return True, when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

If the type of x defines __next__, but not __iter__, isinstance(x, collections.Iterator) returns True, but in fact x isn't iterable.

>>> class X:
...     def __next__(self):
...             raise StopIteration()
...
>>> x = X()
>>> isinstance(x, collections.Iterator)
True
>>> issubclass(X, collections.Iterator)
True
>>> list(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'X' object is not iterable

The reason for this is that collections.Iterator.__subclasshook__ checks for a __next__ method, and if finds one, returns True. (The class provides an __iter__ mixin method, so this doesn't cause problems for classes inheriting collections.Iterator.)

A possible solution could be in collections.Iterator.__subclasshook__ checking for both required methods.

----------
components: Library (Lib)
messages: 122668
nosy: durban, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: isinstance(x, collections.Iterator) can return True, when x isn't iterable
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Nov 28 17:42:23 2010
From: report at bugs.python.org (Mark Florisson)
Date: Sun, 28 Nov 2010 16:42:23 +0000
Subject: [New-bugs-announce] [issue10566] gdb debugging support additions
	(Tools/gdb/libpython.py)
In-Reply-To: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>
Message-ID: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

Attached is a patch that adds a few features to the Python debugging support for gdb:

- listing of globals
- python breakpoints
- python stepping/stepping over/finishing of frames/running/continuing
- python code execution in the most recent Python frame (relative to the selected frame)

Unit tests are included in Lib/test/test_gdb.py. It should be compatible with both python 3 and python 2 (this is important because libpython.py is also part of the Cython debugger branch, see https://github.com/markflorisson88/cython/blob/master/Cython/Debugger/libpython.py ). Python 2 tests are in that Cython branch.

It would be great if libpython.py could be installed as an actual Python  module instead of a tool, where 'python-gdb.py' would be the actual tool that imports libpython.py. This may remove the need in the future to duplicate files in the Python source distribution and in future versions of Cython. Another good thing about that is that if users don't have python-gdb.py installed properly, or would like to use functionality without having loaded the interpreter in gdb (i.e. 'file python'), they can just do 'python import libpython' in gdb to load the Python support.

I can't assign this issue, but Dave Malcolm (dmalcolm) asked me to assign the issue to him, so I kindly request someone with these capabilities to assign this issue accordingly.

----------
components: Demos and Tools
files: libpython_patch.diff
keywords: patch
messages: 122681
nosy: eggy
priority: normal
severity: normal
status: open
title: gdb debugging support additions (Tools/gdb/libpython.py)
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19857/libpython_patch.diff

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

From report at bugs.python.org  Sun Nov 28 18:51:47 2010
From: report at bugs.python.org (pbnan)
Date: Sun, 28 Nov 2010 17:51:47 +0000
Subject: [New-bugs-announce] [issue10567] Unicode space character \u200b
	unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>


New submission from pbnan <piotr at banaszkiewicz.org>:

Python:
Python 2.7 (r27:82500, Oct 20 2010, 03:21:03) 
[GCC 4.5.1] on linux2

Code:
>>> c = u'\u200b'
>>> c.isspace()
False

In both 2.6, 3.1 it works.

http://www.cs.tut.fi/~jkorpela/chars/spaces.html

----------
components: Unicode
messages: 122690
nosy: pbnan
priority: normal
severity: normal
status: open
title: Unicode space character \u200b unrecognised a space
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 28 21:18:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:18:46 +0000
Subject: [New-bugs-announce] [issue10568] Python and the Unicode Character
	Database
In-Reply-To: <AANLkTinsUM3Vw4+UPDuiKJntFiLhtNSSHzhKVF9K9bHi@mail.gmail.com>
Message-ID: <AANLkTinsUM3Vw4+UPDuiKJntFiLhtNSSHzhKVF9K9bHi@mail.gmail.com>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2]  For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release), we will gain two
additional characters that Python can use in identifiers. [3]

With Python 3.1:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? = 1
      ^
SyntaxError: invalid character in identifier

but with Python 3.2a4:

1

Of course, the likelihood is low that this change will affect any
user, but the change in str.isspace() reported in [1] is likely to
cause some trouble:

[u'A', u'B']

[u'A\u200bB']

While we have little choice but to follow UCD in defining
str.isidentifier(), I think Python can promise users more stability in
what it treats as space or as a digit in its builtins.   For example,
I don't think that supporting

1234.56

is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.

[1] http://bugs.python.org/issue10567
[2] http://bugs.python.org/issue10557
[3] http://www.unicode.org/versions/Unicode6.0.0/#Database_Changes

----------
messages: 122718
nosy: Alexander.Belopolsky
priority: normal
severity: normal
status: open
title: Python and the Unicode Character Database

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

From report at bugs.python.org  Sun Nov 28 22:47:59 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 28 Nov 2010 21:47:59 +0000
Subject: [New-bugs-announce] [issue10569] abc: `issubclass([],
	my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

>>> import abc
>>> class A(object, metaclass=abc.ABCMeta):
...     pass
>>> issubclass([], A)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    issubclass([], A)
  File "c:\Python32\lib\abc.py", line 137, in __subclasscheck__
    if subclass in cls._abc_cache:
  File "c:\Python32\lib\_weakrefset.py", line 69, in __contains__
    return ref(item) in self.data
TypeError: cannot create weak reference to 'list' object

I should be able to check whether an object is a subclass of something without confirming it's a type first. I think this call should just return False.

----------
components: Library (Lib)
messages: 122736
nosy: cool-RR
priority: normal
severity: normal
status: open
title: abc: `issubclass([], my_abstract_type)` raises exception
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 29 00:38:55 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 28 Nov 2010 23:38:55 +0000
Subject: [New-bugs-announce] [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

$ python3 --version
Python 3.1.3

$ python3 setup.py bdist upload --sign
[snip]
Traceback (most recent call last):
  File "setup.py", line 71, in <module>
    cmdclass = dict(build_py=build_py)
  File "/usr/local/lib/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 155, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface


Without --sign it works just fine.

----------
components: Library (Lib)
messages: 122746
nosy: jwilk
priority: normal
severity: normal
status: open
title: curses.tigetstr() returns bytes, but curses.tparm() expects a string
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov 29 00:38:59 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 28 Nov 2010 23:38:59 +0000
Subject: [New-bugs-announce] [issue10571] "setup.py upload --sign" broken:
	TypeError: 'str' does	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

$ python3 --version
Python 3.1.3

$ python3 setup.py bdist upload --sign
[snip]
Traceback (most recent call last):
  File "setup.py", line 71, in <module>
    cmdclass = dict(build_py=build_py)
  File "/usr/local/lib/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 155, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface


Without --sign it works just fine.

----------
assignee: tarek
components: Distutils
messages: 122747
nosy: eric.araujo, jwilk, tarek
priority: normal
severity: normal
status: open
title: "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov 29 01:52:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 00:52:59 +0000
Subject: [New-bugs-announce] [issue10572] Move unittest test package to
	Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Having tests in Lib/test instead of inside the package makes it easier to grep the unittest package without grepping the tests. The Windows installer has an "install without tests" option which is easier to honour if the tests aren't in the package.

However, currently all packages that have test *packages* have the tests in the package rather than inside Lib/test. (There are no test packages inside Lib/test.)

Examples: email, distutils, ctypes, importlib, json, lib2to3, sqlite3

I also maintain an external port of unittest from Python 3. This is unittest2-py3k. Moving the tests would make it *slightly* harder to keep this in sync. I'm moving to maintaining this port as a set of patches rather than a separate branch. These patches can be applied automatically to unittest from py3k head. unittest2-py3k will be built automatically by a script, so it isn't a big deal.

----------
assignee: michael.foord
keywords: easy
messages: 122751
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Move unittest test package to Lib/test
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 29 01:55:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 00:55:59 +0000
Subject: [New-bugs-announce] [issue10573] Consistency in unittest assert
	methods: order of actual, expected
In-Reply-To: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>
Message-ID: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

The unittest documentation, argument names and implementation need to be consistent about the order of (actual, expected) for TestCase.assert methods that take two arguments. 

This is particularly relevant for the methods that produce 'diffed' output on failure - as the order determines whether mismatched items are missing from the expected or additional to the expected.

The documentation, signatures and implementation of all two argument asserts need to be checked to ensure they are the same and implemented correctly.

Personally I prefer (actual, expected).

----------
assignee: michael.foord
components: Documentation, Library (Lib)
messages: 122752
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Consistency in unittest assert methods: order of actual, expected
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov 29 05:59:02 2010
From: report at bugs.python.org (Roy H. Han)
Date: Mon, 29 Nov 2010 04:59:02 +0000
Subject: [New-bugs-announce] [issue10574] email.header.decode_header fails
	if the string contains	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>


New submission from Roy H. Han <starsareblueandfaraway at gmail.com>:

email.header.decode_header fails for the following message subject:
::

    email.header.decode_header('=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?=')


If the directives are removed and the padding problems are fixed, the subject parses correctly.
::

    email.header.decode_header('=?UTF-8?B?%s==?=' % '=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?='.replace('=?UTF-8?B?', '').replace('?', '').replace('=', ''))

----------
components: Library (Lib)
messages: 122772
nosy: starsareblueandfaraway
priority: normal
severity: normal
status: open
title: email.header.decode_header fails if the string contains multiple directives
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From orsenthil at gmail.com  Mon Nov 29 09:57:31 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 29 Nov 2010 16:57:31 +0800
Subject: [New-bugs-announce] [issue10559] NameError in
 tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
References: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
	<1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <20101129085731.GE2023@rubuntu>

On Sun, Nov 28, 2010 at 05:48:20AM +0000, ?ric Araujo wrote:
> I?m not committing directly because I?d like feedback: Is the
> wording okay for the beginning of the tutorial?

It seems fine and useful. Please go ahead.

From report at bugs.python.org  Mon Nov 29 12:10:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 11:10:56 +0000
Subject: [New-bugs-announce] [issue10575] makeunicodedata.py does not
	support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

The script only patches numeric data into the table (field 8), but does not update the digit field (field 7).

As a result, ideographs used for Chinese digits are not recognized as digits and not evaluated by int(), long() and float():

    http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture

>>> unicode('?', 'utf-8')
u'\u4e09'

>>> int(unicode('?', 'utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character u'\u4e09' in position 0: invalid decimal Unicode string
> <stdin>(1)<module>()

>>> import unicodedata
>>> unicodedata.digit(unicode('?', 'utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a digit

The code point refers to the digit 3.

----------
components: Unicode
messages: 122786
nosy: lemburg
priority: normal
severity: normal
status: open
title: makeunicodedata.py does not support Unihan digit data
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 29 13:33:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 29 Nov 2010 12:33:10 +0000
Subject: [New-bugs-announce] [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

As discussed here: http://mail.python.org/pipermail/python-ideas/2010-November/008813.html:

Adding the ability to register callbacks to be invoked before and after garbage collection runs.  This can be used to gather run-time statistics such as timing information and frequency of garbage collection runs, and to perform application-specific cleanup of uncollecatable objects from gc.garbage.

The first patch is the code as currently in use in our codebase at CCP (ported from 2.7).  There is only one callback registered and the callback signature is perhaps a bit lame.  Also, no error checking.  But it is shown here for reference and as a basis for discussion.

----------
components: Interpreter Core
files: gccallback1.patch
keywords: patch
messages: 122795
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add a progress callback to gcmodule
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19869/gccallback1.patch

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

From report at bugs.python.org  Mon Nov 29 14:59:59 2010
From: report at bugs.python.org (xhresko)
Date: Mon, 29 Nov 2010 13:59:59 +0000
Subject: [New-bugs-announce] [issue10577] (Fancy) URL opener stucks whet try
	to open page
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>


New submission from xhresko <juraj.hresko at gmail.com>:

(Fancy) URL opener stucks whet try to open page, which is automaticaly forwarded. I tried url "http://www.ihned.cz", which stuck while "http://ihned.cz" is ok. This type of behavior is different from one in the Python 2.7, which works ok. 

///// CODE
opener = urllib.FancyURLopener({})
f = opener.open("http://www.ihned.cz/")
/////

----------
components: Library (Lib)
messages: 122799
nosy: xhresko
priority: normal
severity: normal
status: open
title: (Fancy) URL opener stucks whet try to open page
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov 29 15:09:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 14:09:33 +0000
Subject: [New-bugs-announce] [issue10578] Add mock PyPI server to test
	distutils
In-Reply-To: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>
Message-ID: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In distutils2, we have a mock PyPI server to test index-related behavior, but in distutils we fix such things without automated tests.  I would like to add the mock server to distutils.

----------
assignee: tarek
components: Distutils, Tests
messages: 122801
nosy: eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add mock PyPI server to test distutils
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov 29 17:18:37 2010
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 29 Nov 2010 16:18:37 +0000
Subject: [New-bugs-announce] [issue10579] Is ``o[key]`` equivalent to
	PyMapping_HasKeyString?
In-Reply-To: <1291047517.36.0.54391686166.issue10579@psf.upfronthosting.co.za>
Message-ID: <1291047517.36.0.54391686166.issue10579@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/mapping.html#PyMapping_HasKeyString
and
http://docs.python.org/c-api/mapping.html#PyMapping_HasKey
says:
> This is equivalent to ``o[key]``

I think it should be ``key in o``.

----------
assignee: docs at python
components: Documentation
messages: 122824
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Is ``o[key]`` equivalent to PyMapping_HasKeyString?
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov 29 18:51:55 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 29 Nov 2010 17:51:55 +0000
Subject: [New-bugs-announce] [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

The installer of Python should have consistent sentences, the ones in bold.

There's one sentence that needs fixing. The sentence "Completing the Python x.x.x Installer" should be "Complete the Python x.x.x Installer", because other sentences are in the form of "Install xxx" and "Customize xxx" (they are not written as "Installing xxx" and "Customizing xxx"). Please fix this.

----------
components: Installation
messages: 122832
nosy: Retro
priority: normal
severity: normal
status: open
title: Installer sentence in bold
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Nov 29 18:55:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 17:55:58 +0000
Subject: [New-bugs-announce] [issue10581] Review and document string format
	accepted in numeric	data type constructors
In-Reply-To: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>
Message-ID: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am opening a new report to continue work on the issues raised in #10557 that are either feature requests or documentation bugs.

The rest is my reply to the relevant portions of Marc's comment at msg122785.

On Mon, Nov 29, 2010 at 4:41 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
..
> Alexander Belopolsky wrote:
>>
>> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>>
>> After a bit of svn archeology, it does appear that Arabic-Indic
>> digits' support was deliberate at least in the sense that the
>> feature was tested for when the code was first committed. See r15000.
>
> As I mentioned on python-dev (http://mail.python.org/pipermail/python-dev/2010-November/106077.html)
> this support was added intentionally.
>
>> The test migrated from file to file over the last 10 years, but it
>> is still present in test_float.py:
>>
>> ? ? ? ? self.assertEqual(float(b" ?\u0663.\u0661\u0664 ?".decode('raw-unicode-escape')), 3.14)
>>
>> (It should probably be now rewritten using a string literal.)
>>
..
>> For the future, I note that starting with Unicode 6.0.0,
>> the Unicode Consortium promises that
>>
>> """
>> Characters with the property value Numeric_Type=de (Decimal) only
>> occur in contiguous ranges of 10 characters, with ascending numeric
>> values from 0 to 9 (Numeric_Value=0..9).
>> """
>>
>> This makes it very easy to check a numeric string does not contain
>> a mix of digits from different scripts.
>
> I'm not sure why you'd want to check for such ranges.
>

In order to disallow a mix of say Arabic-Indic and Bengali digits.  Such combinations cannot be defended as possibly valid numbers in any script.

>> I still believe that proper API should require explicit choice of
>> language or locale before allowing digits other than 0-9 just as
>> int() would not accept hexadecimal digits without explicit choice of
>> base >= 16. ?But this would be a subject of a feature request.
>
> Since when do we require a locale or language to be specified when
> using Unicode ?
>

This is a valid question.  I may be in minority, but I find it convenient to use int(), float() etc. for data validation.  If my program gets a CSV file with Arabic-Indic digits, I want to fire the guy who prepared it before it causes real issues. :-)  I may be too strict, but I don't think anyone would want to see columns with a mix of Bengali and Devanagari numerals.

On the other hand there is certain convenience in promiscuous parsers, but this is not an expectation that I have from int() and friends.  int('0xFF') requires me to specify base even though 0xFF is a perfectly valid notation.

There are pros and cons in any approach.  Let's figure out what is better before we fix the documentation.

> The codecs, Unicode methods and other Unicode support features
> happily work with all kinds of languages, mixed or not, without any
> such specification.

In my view int() and friends are only marginally related to Unicode and Unicode methods design is not directly relevant to their behavior.  If we were designing str.todigits(), by all means, I would argue that it must be consistent with str.isdigit().  For numeric data, however, I think we should follow the logic that rejected int('0xFF').

This is my opinion.  We can consider allowing int('0xFF') as well.  Let's discuss.

----------
assignee: belopolsky
components: Documentation, Interpreter Core
messages: 122834
nosy: belopolsky, eric.smith, ezio.melotti, haypo, lemburg, mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Review and document string format accepted in numeric data type constructors
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 29 19:46:32 2010
From: report at bugs.python.org (Marc Horowitz)
Date: Mon, 29 Nov 2010 18:46:32 +0000
Subject: [New-bugs-announce] [issue10582] PyErr_PrintEx exits silently when
	passed SystemExit	exception
In-Reply-To: <1291056392.92.0.0604779345933.issue10582@psf.upfronthosting.co.za>
Message-ID: <1291056392.92.0.0604779345933.issue10582@psf.upfronthosting.co.za>


New submission from Marc Horowitz <mhorowitz at gmail.com>:

I discovered this bug working with panda3d.  I've attached a short
python script which demonstrates the problem.  After installing
panda3d, run the script, and then hit q in the window which appears.
You'll see that none of the cleanup code after the 'run()' main loop
runs.

The underlying cause is in how panda3d uses the C API.  It's got code
like this (in src/pipeline/thread.cxx):

    // Call the user's function.
    result = PyObject_Call(function, args, NULL);
    if (result == (PyObject *)NULL && PyErr_Occurred()) {
      // We got an exception.  Move the exception from the current
      // thread into the main thread, so it can be handled there.
      PyObject *exc, *val, *tb;
      PyErr_Fetch(&exc, &val, &tb);

      thread_cat.error()
        << "Exception occurred within " << *this << "\n";

      // Temporarily restore the exception state so we can print a
      // callback on-the-spot.
      Py_XINCREF(exc);
      Py_XINCREF(val);
      Py_XINCREF(tb);
      PyErr_Restore(exc, val, tb);
      PyErr_Print();

      ...

If the code being called (generally a panda3d task function or event
handler) calls sys.exit, the PyErr_Print() never returns.  This is
surprising, as the the documentation never mentions that a function
with an innocuous name like "Print" might never return.  

However, I don't think this is a panda3d bug; I think that the
function as documented is the way it should behave.  Otherwise, the
vast majority of calls to this method will need to look like

    if (!PyErr_ExceptionMatches(PyExc_SystemExit)) {
      PyErr_PrintEx(1);
    }

which seems like a poor abstraction.

Another unexpected side effect is when python is used with the -i
flag.  Because of the way this alters the normal exit behavior, the
code runs the way I'd expect, and the cleanup code in the test
application *does* run.  It seems rather strange to me that cleanup
code should run or not run based on the -i flag.

I believe the fix for all this is that PyErr_PrintEx be changed to
behave as documented, *not* call handle_system_exit() when passed
SystemExit, and instead in the places where the interpreter main loop
is run, followed by PyErr_PrintEx(), that SystemExit is special cased
in those specific locations as needed.

----------
components: Interpreter Core
files: exit_test.py
messages: 122846
nosy: Marc.Horowitz
priority: normal
severity: normal
status: open
title: PyErr_PrintEx exits silently when passed SystemExit exception
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19875/exit_test.py

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

From report at bugs.python.org  Mon Nov 29 20:48:28 2010
From: report at bugs.python.org (flashk)
Date: Mon, 29 Nov 2010 19:48:28 +0000
Subject: [New-bugs-announce] [issue10583] Encoding issue with chm help in
	2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

I just updated to Python 2.7.1 and noticed a small issue with the chm help file.

The search results tab displays incorrect characters for various topic titles. It seems to be an encoding issue.

For example, searching for 'json' yields the following results:

 - 18.2 json ??? JSON encoder and decoder
 - What???s New in Python 2.6

I noticed this issue on Windows XP 32-bit and Windows 7 64-bit.

This issue does not exist with the 2.7 chm file.

----------
assignee: docs at python
components: Documentation, Windows
messages: 122857
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Encoding issue with chm help in 2.7.1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 30 00:08:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 23:08:05 +0000
Subject: [New-bugs-announce] [issue10584] Bad links in doc of zipfile.open
In-Reply-To: <1291072085.42.0.419401053582.issue10584@psf.upfronthosting.co.za>
Message-ID: <1291072085.42.0.419401053582.issue10584@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

There is this note in the doc of zipfile.open:

?The file-like object [ZipExtFile, internal class] is read-only and provides the following methods: read(), readline(), readlines(), __iter__(), __next__().?

The :meth: construct gives interesting results here: link to zipfile.ZipFile.read (wrong), link to readline module (what?), no link, link to object.__iter__ (not bad), no link.

----------
assignee: docs at python
components: Documentation
messages: 122871
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Bad links in doc of zipfile.open
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov 30 00:27:21 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 29 Nov 2010 23:27:21 +0000
Subject: [New-bugs-announce] [issue10585] 2.6 maintenance branch erroneously
	uses	unittest.TestCase.assertListEqual (added in 2.7)
In-Reply-To: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>
Message-ID: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

2.6.6 has an erronenous use of a unittest method that was added in 2.7, but it's only seen when running as root.  More specificially, with this guard:
    if posix.getuid() == 0 and hasattr(posix, 'getgroups') and sys.platform != 'darwin':

[david at surprise 2.6-clean]$ sudo ./python -m test.test_posix
   (snip)
======================================================================
ERROR: test_setgroups (__main__.PosixGroupsTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/test/test_posix.py", line 356, in test_setgroups
    self.assertListEqual(groups, posix.getgroups())
AttributeError: 'PosixGroupsTester' object has no attribute 'assertListEqual'

----------------------------------------------------------------------
Ran 29 tests in 0.020s

FAILED (errors=1)

Seems to have come from r83126.  Fix would seem to be to replace the assertListEqual with AssertEqual.  Am attaching a patch.

----------
components: Tests
files: 2.6-fix-test_setgroups.patch
keywords: easy, patch
messages: 122872
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: 2.6 maintenance branch erroneously uses unittest.TestCase.assertListEqual (added in 2.7)
versions: Python 2.6
Added file: http://bugs.python.org/file19877/2.6-fix-test_setgroups.patch

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

From report at bugs.python.org  Tue Nov 30 05:12:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 04:12:09 +0000
Subject: [New-bugs-announce] [issue10586] Enhanced cache access API for
	functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As per private email to Raymond, I would like to move the lru_cache access attributes and methods into a CacheInfo class, exposed as a "cache" attribute with several methods and read-only properties.

Read-only properties: hits, misses, maxsize
Methods: clear(), __len__()

As an implementation detail, cache_misses and cache_hits become nonlocal variables rather than attributes of the wrapper function.

Priority set to high, since the current API will be locked in as soon the first beta goes out.

----------
assignee: rhettinger
files: functools_lru_cache_introspection.diff
keywords: patch
messages: 122879
nosy: georg.brandl, ncoghlan, rhettinger
priority: high
severity: normal
status: open
title: Enhanced cache access API for functools.lru_cache
versions: Python 3.2
Added file: http://bugs.python.org/file19880/functools_lru_cache_introspection.diff

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

From report at bugs.python.org  Tue Nov 30 06:46:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 05:46:46 +0000
Subject: [New-bugs-announce] [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Mon, Nov 29, 2010 at 4:13 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> - How specific should library reference manual be in defining methods
>> affected by UCD such as str.upper()?
>
> It should specify what this actually does in Unicode terminology
> (probably in addition to a layman's rephrase of that)
>

http://mail.python.org/pipermail/python-dev/2010-November/106155.html

Some of the clarifications may actually lead to a conclusion that current behavior is wrong.  For example, Unicode defines Alphabetic property as Lu + Ll + Lt + Lm + Lo + Nl + Other_Alphabetic

http://www.unicode.org/reports/tr44/tr44-6.html#Alphabetic

However, str.isalpha() is defined as just Lu + Ll + Lt + Lm + Lo.  For example,

>>> import unicodedata as ud
>>> ud.category('?')
'Nl'
>>> '?'.isalpha()
False
>>> ud.name('?')
'ROMAN NUMERAL FIVE'

As far a I can tell, the source of Other_Alphabetic property data,
http://unicode.org/Public/UNIDATA/PropList.txt, is not even included in the unicodedata module and neither is SpecialCasing.txt which is necessary for implementing a compliant case mapping algorithm.

----------
assignee: docs at python
components: Documentation
messages: 122885
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Document the meaning of str methods
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 30 10:35:52 2010
From: report at bugs.python.org (Emile Anclin)
Date: Tue, 30 Nov 2010 09:35:52 +0000
Subject: [New-bugs-announce] [issue10588] imp.find_module raises unexpected
	SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>


New submission from Emile Anclin <emile.anclin at logilab.fr>:

Considering following file: 
$ cat pylint/test/input/func_unknown_encoding.py 
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
"""

__revision__ = '????'
$

When we try to find that module, imp.find_module raises SyntaxError:

>>> from imp import find_module
>>> find_module('func_unknown_encoding', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SyntaxError: encoding problem: with BOM

It should be considered as a bug, as stated by  Brett Cannon:

> Considering these semantics changed between Python 2 and 3 w/o a
> discernable benefit (I would consider it a negative as finding a
> module should not be impacted by syntactic correctness; the full act
> of importing should be the only thing that cares about that), I would
> consider it a bug that should be filed.

----------
messages: 122896
nosy: emile.anclin
priority: normal
severity: normal
status: open
title: imp.find_module raises unexpected SyntaxError
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 30 20:05:53 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 19:05:53 +0000
Subject: [New-bugs-announce] [issue10589] I/O ABC docs should specify which
	methods have	implementations
In-Reply-To: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>
Message-ID: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

The I/O ABC documentation has a blanket disclaimer at the top:

    "The abstract base classes also provide default implementations of some methods in order to help implementation of concrete stream classes. For example, BufferedIOBase provides unoptimized implementations of readinto() and readline()."

Which effectively means that to subclass one of them requires digging into Lib/_pyio.py to figure out which methods provide useful implementations.

It would be handy to have a table, similar to the one for the collections ABCs [1], that spells out which methods are provided.

[1]: http://docs.python.org/py3k/library/collections.html#abcs-abstract-base-classes

I hope to have a patch ready sometime within the next week.

----------
assignee: stutzbach
components: Documentation
messages: 122930
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: I/O ABC docs should specify which methods have implementations
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov 30 20:37:41 2010
From: report at bugs.python.org (Thomas Ryan)
Date: Tue, 30 Nov 2010 19:37:41 +0000
Subject: [New-bugs-announce] [issue10590] Parameter type error for
	xml.sax.parseString(string, ...)
In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>
Message-ID: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>


New submission from Thomas Ryan <tom.a.ryan at gmail.com>:

In 3.1.3, 3.1.2, maybe earlier...

xml.sax.parseString(string, handler, error_handler=handler.ErrorHandler())

Source code requires bytes, not a string as implied by function name and by the documentation.

Exception thrown for strings.

Since the name includes "string" the source should probably be fixed.
Or at least update the documentation.

Someday replace/augment parseString() with parseBytes()?

----------
components: XML
messages: 122933
nosy: Thomas.Ryan
priority: normal
severity: normal
status: open
title: Parameter type error for xml.sax.parseString(string, ...)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 30 23:28:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:28:46 +0000
Subject: [New-bugs-announce] [issue10591] test_os failure in refleak runs
In-Reply-To: <1291156126.42.0.381106886748.issue10591@psf.upfronthosting.co.za>
Message-ID: <1291156126.42.0.381106886748.issue10591@psf.upfronthosting.co.za>


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

$ ./python -m test.regrtest -R 3:2 test_os
[1/1] test_os
[35351 refs]
[35351 refs]
[35352 refs]
beginning 5 repetitions
12345
[35351 refs]
[35351 refs]
[35352 refs]
test test_os failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 898, in test_unicode_name
    self._test_link(self.file1, self.file2)
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 879, in _test_link
    os.link(file1, file2)
OSError: [Errno 17] File exists

----------
assignee: brian.curtin
components: Tests
messages: 122945
nosy: brian.curtin, pitrou
priority: normal
severity: normal
status: open
title: test_os failure in refleak runs
type: resource usage
versions: Python 3.2

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