 if the message contains a newline internally
      # otherwise let the html control line breaks
      self.error_message_format=self.error_message_format.replace(oldfmt,'
%(message)s
\n') if '\n' in m else self.error_message_format.replace(oldfmt,'%(message)s\n')
  def do_GET(self):
    try:
      assert(False)
    except:
      m=traceback.format_exc().strip()
      self.content_aware_error_message_format(m)
      self.send_error(500,m)

if __name__=='__main__':
  addr=('',9000)
  http.server.HTTPServer(addr,httphandler).serve_forever()

----------
components: Library (Lib)
messages: 143646
nosy: Paul.Upchurch
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler.send_error and trailing newline
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 22:48:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Sep 2011 20:48:50 +0000
Subject: [New-bugs-announce] [issue12922] StringIO and seek()
Message-ID: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>

New submission from Terry J. Reedy :

First, there is a minor documentation issue.
15.2.3.1. I/O Base Classes
class io.IOBase
seek(offset, whence=SEEK_SET) 
Change the stream position to the given byte offset

Since StringIO seeks by code units that should perhaps say 'byte or code unit offset' or a separate note should be added to the doc entry for StringIO.

>>> txt = StringIO('ab\U00010030')
>>> txt.seek(3)
3
>>> txt.write('x')
1
>>> txt.getvalue()
'ab\ud800x'

The behavior problem is that seeking for StringIO does not work relative to the current position or end.

IOError: Can't do nonzero cur-relative seeks
# Note: this message is wrong for end-relative seeks.

I presume this is inherited from an undocumented restriction on seeking with text streams, because chars *might* be variably sized. However, I do not think it should be. StringIO does not inherit the same reason for the restriction (certainly not on wide builds, and on narrow builds, seeking from the beginning is just as problematical). For StringIO, there is no option of 'opening in binary (byte) mode instead' as there is for disk files. Since a StringIO object is a wrapped array of fixed-size units, seeking from any position is as trivial as it is from the beginning. And again, the current docs imply that it should work.

Note that seeking from the beginning is not limited to the existing content. Instead, skipped areas are filled with nulls.

from io import StringIO
txt = StringIO('0123456789')
txt.seek(15,0) # no problem with absolute seek
txt.write('xxx')
s  = txt.getvalue()
print(ord(s[12]))
# 0

So that is not a reason to limit seeking from other positions either.

----------
components: Library (Lib)
messages: 143649
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: StringIO and seek()
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 01:40:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Sep 2011 23:40:58 +0000
Subject: [New-bugs-announce] [issue12923] test_urllib fails in refleak mode
Message-ID: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>

New submission from Stefan Krah :

Hi,

test_urllib fails in refleak mode:

./python -m test -uall -v -R : test_urllib

======================================================================
FAIL: test_invalid_redirect (test.test_urllib.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/hg/cpython/Lib/test/test_urllib.py", line 235, in test_invalid_redirect
    "http://python.org/")
AssertionError: HTTPError not raised by urlopen

----------------------------------------------------------------------
Ran 58 tests in 0.075s

FAILED (failures=1, skipped=1)
test test_urllib failed
1 test failed:
    test_urllib
[133995 refs]

----------
components: Tests
messages: 143656
nosy: orsenthil, skrah
priority: normal
severity: normal
status: open
title: test_urllib fails in refleak mode
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 07:58:33 2011
From: report at bugs.python.org (Jon Parise)
Date: Wed, 07 Sep 2011 05:58:33 +0000
Subject: [New-bugs-announce] [issue12924] Missing call to quote_plus()
	in	test_urllib.test_default_quoting()
Message-ID: <1315375113.16.0.494762103225.issue12924@psf.upfronthosting.co.za>

New submission from Jon Parise :

test_default_quoting() runs a number of identical tests on both quote() and quote_plus() (which is most cases have equivalent behavior).  However, at the end of the method, there appears to be a missing complementary call to quote_plus() despite there being an assertion call for the quote_plus() case.

----------
components: Tests
files: test_urllib.default_quoting.patch
keywords: patch
messages: 143663
nosy: jon
priority: normal
severity: normal
status: open
title: Missing call to quote_plus() in test_urllib.test_default_quoting()
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23112/test_urllib.default_quoting.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 10:41:04 2011
From: report at bugs.python.org (Sergei Stolyarov)
Date: Wed, 07 Sep 2011 08:41:04 +0000
Subject: [New-bugs-announce] [issue12925] python setup.py upload_docs
	doesn't ask for login and	password
Message-ID: <1315384864.35.0.23347114707.issue12925@psf.upfronthosting.co.za>

New submission from Sergei Stolyarov :

python setup.py upload_docs doesn't ask for login and password instead it prints 

Upload failed (401): You must be identified to edit package information

Works only with valid ~/.pypirc

----------
assignee: tarek
components: Distutils
messages: 143666
nosy: cancel, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: python setup.py upload_docs doesn't ask for login and password
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 12:04:11 2011
From: report at bugs.python.org (Fabio Erculiani)
Date: Wed, 07 Sep 2011 10:04:11 +0000
Subject: [New-bugs-announce] [issue12926] tarfile tarinfo.extract*() broken
	with symlinks
Message-ID: <1315389851.08.0.471880114138.issue12926@psf.upfronthosting.co.za>

New submission from Fabio Erculiani :

TarFile.makelink() is plain broken.
Test file: http://git.sabayon.org/entropy.git/tree/libraries/tests/packages/amarok-2.2.2.90.tbz2

_extract_member calls makelink which does os.symlink() and then falls to the else branch and calls back _extract_member(), which calls makelink() which calls os.symlink() and causes errno 17.

ERROR: test_db_insert_compare_match_mime (__main__.EntropyRepositoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "db.py", line 490, in test_db_insert_compare_match_mime
    data = self.Spm.extract_package_metadata(test_pkg)
  File "../entropy/spm/plugins/interfaces/portage_plugin/__init__.py", line 1038, in extract_package_metadata
    extract_path = pkg_dir, catch_empty = False)
  File "../entropy/tools.py", line 2088, in uncompress_tarball
    tar.extract(tarinfo, encoded_path)
  File "/usr/lib64/python3.2/tarfile.py", line 2174, in extract
    set_attrs=set_attrs)
  File "/usr/lib64/python3.2/tarfile.py", line 2258, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2358, in makelink
    targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2258, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2341, in makelink
    os.symlink(tarinfo.linkname, targetpath)
OSError: [Errno 17] File exists

----------
components: Library (Lib)
messages: 143667
nosy: Fabio.Erculiani
priority: normal
severity: normal
status: open
title: tarfile tarinfo.extract*() broken with symlinks
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 14:45:14 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 12:45:14 +0000
Subject: [New-bugs-announce] [issue12927] test_ctypes: segfault with suncc
Message-ID: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>

New submission from Stefan Krah :

stefan at opensolaris:~/hg/cpython$ ./python -m test -uall -v test_ctypes
== CPython 3.3.0a0 (default:5c8b6e03ebfe, Sep 7 2011, 13:41:08) [C]
==   Solaris-2.11-i86pc-i386-32bit little-endian
==   /export/home/stefan/hg/cpython/build/test_python_28849
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
test_cast (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memmove (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memset (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_string_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_wstring_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_chararray (ctypes.test.test_delattr.TestCase) ... ok
test_simple (ctypes.test.test_delattr.TestCase) ... ok
test_struct (ctypes.test.test_delattr.TestCase) ... ok
test_struct_by_value (ctypes.test.test_win32.Structures) ... ok
test_buffers (ctypes.test.test_unicode.StringTestCase) ... ok
test_func (ctypes.test.test_unicode.StringTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.StringTestCase) ... ok
test_buffers (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_compare (ctypes.test.test_simplesubclasses.Test) ... ok
test_ignore_retval (ctypes.test.test_simplesubclasses.Test) ... Fatal Python error: Segmentation fault

Current thread 0x00000001:
  File "/export/home/stefan/hg/cpython/Lib/ctypes/test/test_simplesubclasses.py", line 24 in test_ignore_retval
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 441 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 493 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/runner.py", line 168 in run
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1293 in _run_suite
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1327 in run_unittest
  File "/export/home/stefan/hg/cpython/Lib/test/test_ctypes.py", line 13 in test_main
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 916 in runtest
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 708 in main
  File "/export/home/stefan/hg/cpython/Lib/test/__main__.py", line 13 in 
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 73 in _run_code
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 160 in _run_module_as_main
Segmentation Fault (core dumped)

----------
components: ctypes
messages: 143670
nosy: skrah
priority: normal
severity: normal
status: open
title: test_ctypes: segfault with suncc
type: crash
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 15:16:26 2011
From: report at bugs.python.org (simon)
Date: Wed, 07 Sep 2011 13:16:26 +0000
Subject: [New-bugs-announce] [issue12928] exec not woking in unittest
Message-ID: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>

New submission from simon :

works in 2.6, fails in 3.2.2

import unittest
class MyTest(unittest.TestCase):
    def test_a(self):
        exec(compile("a = 1", '', 'single'))
        assert a == 1
if __name__ == '__main__':
    unittest.main()

----------
components: Library (Lib)
messages: 143672
nosy: simonsteiner
priority: normal
severity: normal
status: open
title: exec not woking in unittest
type: compile error
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:10:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 14:10:46 +0000
Subject: [New-bugs-announce] [issue12929] faulthandler: void pointer used in
	arithmetic
Message-ID: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>

New submission from Stefan Krah :

Hi, suncc detected pointer arithmetic with a pointer to void:

"./Modules/faulthandler.c", line 910: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 911: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 914: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 916: warning: pointer to void or function used in arithmetic

----------
components: Extension Modules
messages: 143675
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: faulthandler: void pointer used in arithmetic
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:29:37 2011
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 07 Sep 2011 14:29:37 +0000
Subject: [New-bugs-announce] [issue12930] reindent.py inserts spaces in
	multiline literals
Message-ID: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>

New submission from Dima Tisnek :

Given this as input:
#!/usr/bin/python
def x():
  s = """line one
line two
line three"""
  return s

reindent.py changes it to:
#!/usr/bin/python
def x():
    s = """line one
  line two
  line three"""
    return s

Which means that I cannot use reindent.py on any source that includes multiline literals that are not docs.

Btw, it is generally weird that reindented file ends up with 2 spaces before "line two".

----------
components: Demos and Tools
messages: 143679
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: reindent.py inserts spaces in multiline literals
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:30:07 2011
From: report at bugs.python.org (Wolfgang Schnerring)
Date: Wed, 07 Sep 2011 14:30:07 +0000
Subject: [New-bugs-announce] [issue12931] xmlrpclib confuses unicode and
	string
Message-ID: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>

New submission from Wolfgang Schnerring :

This is a similar issue to http://bugs.python.org/issue7093, but more insiduous:

This works:

xmlrpclib.ServerProxy(u'http://localhost:8080').foo(dict(baz=u'b?r'))

While this fails with a UnicodeDecodeError (note the trailing slash in the URI):

xmlrpclib.ServerProxy(u'http://localhost:8080/').foo(dict(baz=u'b?r'))

  File "/usr/local/python2.7/lib/python2.7/httplib.py", line 937, in endheaders
    self._send_output(message_body)
  File "/usr/local/python2.7/lib/python2.7/httplib.py", line 795, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 139: ordinal not in range(128)

So, somewhere in xmlrpclib, confusion happens, since even though the URI is passed in as unicode both times, it is stored as string in the first case (thus compatible with the serialized, utf-8 encoded string of the message body), but in the second case it remains unicode (thus failing, as #7093 tells, which I personally wouldn't have closed wontfix).

----------
components: Library (Lib)
messages: 143680
nosy: wosc
priority: normal
severity: normal
status: open
title: xmlrpclib confuses unicode and string
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:01:36 2011
From: report at bugs.python.org (Kevin Smith)
Date: Wed, 07 Sep 2011 16:01:36 +0000
Subject: [New-bugs-announce] [issue12932] dircmp does not allow non-shallow
	comparisons
Message-ID: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za>

New submission from Kevin Smith :

While filecmp.cmp and filecmp.cmpfiles allow a shallow option to be specified to invoke a more involved comparison of files, filecmp.dircmp does not.  It is limited to shallow-only comparisons.  

This could be solved quite easily by adding a shallow keyword option to dircmp then changing the phase3 method to the following.

    def phase3(self): # Find out differences between common files
        xx = cmpfiles(self.left, self.right, self.common_files, self.shallow)
        self.same_files, self.diff_files, self.funny_files = xx

----------
components: Library (Lib)
messages: 143692
nosy: kesmit
priority: normal
severity: normal
status: open
title: dircmp does not allow non-shallow comparisons
type: feature request
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:06:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 16:06:54 +0000
Subject: [New-bugs-announce] [issue12933] Update or remove claims that
	distutils requires external	programs
Message-ID: <1315411614.16.0.0292960363033.issue12933@psf.upfronthosting.co.za>

New submission from ?ric Araujo :

In the past, distutils could use either the zipfile/tarfile modules or the external programs tar, zip and friends.  This is told in the documentation and checked in the tests.

I suspect that the docs and tests are now outdated.  For example, some tests will be skipped if the tar program is not found, even if the code would have used the tarfile module and run successfully.  I?ll look into this for packaging, but I don?t have the time right now to go over the distutils test and docs for 2.7 and 3.2.

----------
assignee: eric.araujo
components: Distutils, Documentation, Tests
keywords: easy
messages: 143694
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Update or remove claims that distutils requires external programs
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:12:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 16:12:48 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue12934=5D_pysetup_doesn?=
 =?utf-8?q?=E2=80=99t_work_for_the_docutils_project?=
Message-ID: <1315411968.07.0.253348749085.issue12934@psf.upfronthosting.co.za>

New submission from ?ric Araujo :

I tried to run ?pysetup metadata? in a docutils source directory but the program failed, because packaging tries to import docutils and it picks up the 2.x version in the local directory.

The import chain is: pysetup ? packaging.run ? packaging.metadata ? docutils

I could edit sys.path in pysetup, but that would mean that people calling ?python3.y -m packaging.run? would not get the fix.  Another idea would be to catch both ImportError and SyntaxError when packaging.metadata tries to import docutils, but it would be better to find the 3.x version of docutils in site-packages if it exists.

What do you import experts think?

----------
assignee: tarek
components: Distutils2
messages: 143695
nosy: alexis, brett.cannon, eric.araujo, ncoghlan, tarek
priority: normal
severity: normal
status: open
title: pysetup doesn?t work for the docutils project
versions: 3rd party, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:32:24 2011
From: report at bugs.python.org (Karsten Wolf)
Date: Thu, 08 Sep 2011 09:32:24 +0000
Subject: [New-bugs-announce] [issue12935] Typo in findertools.py
Message-ID: <1315474344.82.0.220434823255.issue12935@psf.upfronthosting.co.za>

New submission from Karsten Wolf :

In the current Python-2.7.2.tar.bz2 archive ./Lib/plat-mac/findertools.py in function comment on line 131 the call to FSNewAliasMinimal is misstyped.

current version:
    object_alias = object.FSNewAliasMonimal()

corrected version

    object_alias = object.FSNewAliasMinimal()

----------
assignee: ronaldoussoren
components: Macintosh
messages: 143722
nosy: karstenw, ronaldoussoren
priority: normal
severity: normal
status: open
title: Typo in findertools.py
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:54:47 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 09:54:47 +0000
Subject: [New-bugs-announce] [issue12936] armv5tejl: random segfaults in
	getaddrinfo()
Message-ID: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>

New submission from Stefan Krah :

I'm getting random segfaults in `make buildbottest` on qemu-debian-arm:

Linux-2.6.26-2-versatile-armv5tejl-with-debian-5.0.8 little-endian

The segfaults occurred in test_robotparser and test_nntplib and
couldn't be reproduced when running the tests separately.
qemu-debian-arm is horrendously slow, so I don't think I'll have
time to debug this. I'm submitting the report in case someone has
access to fast ARM hardware.

[ 81/359/3] test_nntplib
Fatal Python error: Segmentation fault

Current thread 0x400225f0:
  File "/home/user/cpython-e91ad9669c08/Lib/socket.py", line 389 in create_connection
  File "/home/user/cpython-e91ad9669c08/Lib/nntplib.py", line 1024 in __init__
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py", line 291 in setUpClass
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 143 in _handleClassSetUp
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 97 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 105 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/runner.py", line 168 in run
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1293 in _run_suite
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1327 in run_unittest
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py", line 1260 in test_main
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 905 in runtest
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 708 in main
  File "/home/user/cpython-e91ad9669c08/Lib/test/__main__.py", line 13 in 
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 73 in _run_code
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 160 in _run_module_as_main
Segmentation fault

----------
components: Extension Modules
messages: 143723
nosy: skrah
priority: normal
severity: normal
stage: test needed
status: open
title: armv5tejl: random segfaults in getaddrinfo()
type: crash
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 19:49:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Sep 2011 17:49:47 +0000
Subject: [New-bugs-announce] [issue12937] Support install options as found
	in distutils
Message-ID: <1315504187.52.0.368275649699.issue12937@psf.upfronthosting.co.za>

New submission from Brett Cannon :

Distutils2/packaging does not support all the flags provided in distutils (e.g., --user, --prefix, etc.). It would be good to provide the same level of install control (or at least support the --user flag).

----------
assignee: tarek
components: Distutils2
messages: 143734
nosy: alexis, brett.cannon, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Support install options as found in distutils
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:00:48 2011
From: report at bugs.python.org (zvin)
Date: Thu, 08 Sep 2011 19:00:48 +0000
Subject: [New-bugs-announce] [issue12938] html.escape does not mention
	single quotes (')
Message-ID: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>

New submission from zvin :

The html.escape docstring says:

"""
Replace special characters "&", "<" and ">" to HTML-safe sequences.
If the optional flag quote is true (the default), the quotation mark
character (") is also translated.
"""

But if you set the optional flag quote to True, this function also escapes single quotes ('). You can see it by comparing _escape_map and _escape_map_full. [http://hg.python.org/cpython/file/cf811943046b/Lib/html/__init__.py]
The docstring needs to be updated.

----------
components: Library (Lib)
messages: 143736
nosy: zvin
priority: normal
severity: normal
status: open
title: html.escape does not mention single quotes (')
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:19:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:19:01 +0000
Subject: [New-bugs-announce] [issue12939] Add new io.FileIO using the native
	Windows API
Message-ID: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>

New submission from STINNER Victor :

On Windows, Python uses the POSIX API (file descriptors), instead of the native API (file handles). Some features cannot be used using the POSIX API, like setting security attributes. It would be nice to have a io.FileIO using Windows file handlers to get access to all Windows features. It would help feature #12105 to implement "O_CLOEXEC" flag using the lpSecurityAttributes argument.

We can maybe try with a prototype written in Python. Using _pyio.RawIOBase, only readinto(), write(), seek() and truncate() have to be implemented. But it is better to implement also close() :-)

----------
components: IO, Unicode
messages: 143741
nosy: amaury.forgeotdarc, haypo, mmarkk
priority: normal
severity: normal
status: open
title: Add new io.FileIO using the native Windows API
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:04:52 2011
From: report at bugs.python.org (Tim Chase)
Date: Fri, 09 Sep 2011 00:04:52 +0000
Subject: [New-bugs-announce] [issue12940] Cmd example using turtle left vs.
	right doc-bug
Message-ID: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>

New submission from Tim Chase :

The Turtle example for the cmd module as documented at

http://docs.python.org/py3k/library/cmd.html#cmd-example

In the left() method, it calls turtle.right() instead of turtle.left().  Easy fix: /def left/+2s/left/right/

Likely exists in most 3.x documentation.

----------
assignee: docs at python
components: Documentation
messages: 143746
nosy: Gumnos, docs at python
priority: normal
severity: normal
status: open
title: Cmd example using turtle left vs. right doc-bug
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:11:01 2011
From: report at bugs.python.org (John Feuerstein)
Date: Fri, 09 Sep 2011 00:11:01 +0000
Subject: [New-bugs-announce] [issue12941] add random.pop()
Message-ID: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>

New submission from John Feuerstein :

This patch against current hg tip (72314:92842e347d98) adds random.pop():

    pop(self, seq) method of Random instance
        Remove and return a random element from a non-empty sequence.

Includes test case.

----------
components: Library (Lib)
files: random_pop.diff
keywords: patch
messages: 143748
nosy: jfeuerstein
priority: normal
severity: normal
status: open
title: add random.pop()
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file23120/random_pop.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 03:28:04 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 09 Sep 2011 01:28:04 +0000
Subject: [New-bugs-announce] [issue12942] Shebang line fixer for 2to3
Message-ID: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>

New submission from Aaron Meurer :

As suggested in this thread in the Python porting list (http://mail.python.org/pipermail/python-porting/2011-September/000231.html), it would be nice if 2to3 had a fixer that translated shebang lines from 

#! /usr/bin/env python

to

#! /usr/bin/env python3

Also relevant here is the draft PEP 394 (http://www.python.org/dev/peps/pep-0394/), which apparently is likely to be accepted.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 143749
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Shebang line fixer for 2to3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 05:11:07 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 09 Sep 2011 03:11:07 +0000
Subject: [New-bugs-announce] [issue12943] tokenize: add python -m tokenize
	support back
Message-ID: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>

New submission from Meador Inge :

In 2.x, 'python -m tokenize' worked great:

[meadori at motherbrain cpython]$ python2.7 -m tokenize test.py
1,0-1,5:        NAME    'print'
1,6-1,21:       STRING  '"Hello, World!"'
1,21-1,22:      NEWLINE '\n'
2,0-2,0:        ENDMARKER       ''

In 3.x, however, the functionality has been removed and replaced with
some hard-wired test code:

[meadori at motherbrain cpython]$ python3 -m tokenize test.py
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3),
line='def parseline(self, line):')
TokenInfo(type=1 (NAME), string='parseline', start=(1, 4), end=(1,
13), line='def parseline(self, line):')
TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14),
line='def parseline(self, line):')
...

The functionality was removed here [1], but with no explanation.  Let's add it back and document the functionality this time around.

[1] http://hg.python.org/cpython/rev/51e24512e305/

----------
components: Library (Lib)
messages: 143752
nosy: meadori
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add python -m tokenize support back
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 08:32:49 2011
From: report at bugs.python.org (Rene Dudfield)
Date: Fri, 09 Sep 2011 06:32:49 +0000
Subject: [New-bugs-announce] [issue12944] setup.py upload to pypi needs to
	work with specified	files
Message-ID: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>

New submission from Rene Dudfield :

We need to specify files to upload to pypi.  Otherwise we have to use the web interface.

'Regarding the "setup.py upload" command, this isn't very helpful because it will not upload a package that was already built - for example, a Windows package built on another host while I am trying to release from a Linux desktop. Since automatic package building across a build farm is the only way I can actually build packages for most platforms, this rules out use of the "upload" command.'

See this post for more details:
http://as.ynchrono.us/2011/09/releasing-python-software-is-tedious.html

----------
assignee: tarek
components: Distutils
messages: 143754
nosy: eric.araujo, illume, tarek
priority: normal
severity: normal
status: open
title: setup.py upload to pypi needs to work with specified files
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 15:54:49 2011
From: report at bugs.python.org (Pavel Boldin)
Date: Fri, 09 Sep 2011 13:54:49 +0000
Subject: [New-bugs-announce] [issue12945] ctypes works incorrectly with
	_swappedbytes_ = 1
Message-ID: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>

New submission from Pavel Boldin :

ctypes seems to work incorrectly with _swappedbytes_ specified.

I.e. it misses some values from buffer:

class X(ctypes.Structure):
    _swappedbytes_ = 1
    _pack_ = 1
    _fields_ = [
        ('a', ctypes.c_ubyte, 4),
        ('b', ctypes.c_ubyte, 4),
        ('c', ctypes.c_ushort, 8),
        ('d', ctypes.c_ushort, 8),
    ]

buf = '\x12\x34\x56\x78'
x = X.from_buffer_copy(buf)

print x.a == 1
print x.b == 2
print x.c == 3
print x.d == 4

This prints
True
True
False
False

Where as four 'True' are expected.

----------
components: ctypes
files: test_ctypes.py
messages: 143761
nosy: Pavel.Boldin
priority: normal
severity: normal
status: open
title: ctypes works incorrectly with _swappedbytes_ = 1
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file23122/test_ctypes.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:19:52 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Sep 2011 16:19:52 +0000
Subject: [New-bugs-announce] [issue12946] PyModule_GetDict() claims it can
	never fail, but it can
Message-ID: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>

New submission from Stefan Behnel :

As is obvious from the code, PyModule_GetDict() can fail if being passed a non-module object, and when the (unlikely) dict creation at the end fails. The documentation of the C-API function should be fixed to reflect that, i.e. it should state that NULL is returned in the case of an error.

PyObject *
PyModule_GetDict(PyObject *m)
{
    PyObject *d;
    if (!PyModule_Check(m)) {
        PyErr_BadInternalCall();
        return NULL;
    }
    d = ((PyModuleObject *)m) -> md_dict;
    if (d == NULL)
        ((PyModuleObject *)m) -> md_dict = d = PyDict_New();
    return d;
}

----------
assignee: docs at python
components: Documentation
messages: 143764
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: PyModule_GetDict() claims it can never fail, but it can
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:22:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:22:34 +0000
Subject: [New-bugs-announce] [issue12947] Examples in library/doctest.html
	lack the flags
Message-ID: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za>

New submission from ?ric Araujo :

The docs for the doctest module contains examples that use doctest flags to control behavior, but the HTML version does not contain the flags, making the examples useless.

I don?t know if this is a bug with the HTML builder or something we can fix in markup.

----------
assignee: docs at python
components: Documentation
messages: 143775
nosy: docs at python, eric.araujo, georg.brandl
priority: normal
severity: normal
status: open
title: Examples in library/doctest.html lack the flags
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:25:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:25:35 +0000
Subject: [New-bugs-announce] [issue12948] multiprocessing test failures can
	hang the buildbots
Message-ID: <1315592735.18.0.0641673256441.issue12948@psf.upfronthosting.co.za>

New submission from Jes?s Cea Avi?n :

Some failures in the multiprocessing testsuite can leave processes around, hanging the buildbots (until the timeout).

I take care of this myself.

----------
assignee: jcea
messages: 143783
nosy: jcea
priority: normal
severity: normal
status: open
title: multiprocessing test failures can hang the buildbots
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:26:29 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Sep 2011 18:26:29 +0000
Subject: [New-bugs-announce] [issue12949] Documentation of PyCode_New()
	lacks kwonlyargcount	argument
Message-ID: <1315592789.75.0.632556595518.issue12949@psf.upfronthosting.co.za>

New submission from Stefan Behnel :

In Py3, PyCode_New() takes a new argument "kwonlyargcount". The signature change is not currently in the Py3 C-API documentation.

http://docs.python.org/dev/c-api/code.html

PyCodeObject *
PyCode_New(int argcount, int kwonlyargcount,
           int nlocals, int stacksize, int flags,
           PyObject *code, PyObject *consts, PyObject *names,
           PyObject *varnames, PyObject *freevars, PyObject *cellvars,
           PyObject *filename, PyObject *name, int firstlineno,
           PyObject *lnotab)

----------
assignee: docs at python
components: Documentation
messages: 143784
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: Documentation of PyCode_New() lacks kwonlyargcount argument
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:55:59 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:55:59 +0000
Subject: [New-bugs-announce] [issue12950] multiprocessing "test_fd_transfer"
	fails under	OpenIndiana
Message-ID: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>

New submission from Jes?s Cea Avi?n :

Buildbots running OpenIndiana 147 show failures in multiprocessing "test_fd_transfer":

"""
======================================================================
ERROR: test_fd_transfer (test.test_multiprocessing.WithProcessesTestConnection)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 1597, in test_fd_transfer
    reduction.send_handle(conn, fd, p.pid)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/multiprocessing/reduction.py", line 80, in send_handle
    _multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file number

======================================================================
ERROR: test_large_fd_transfer (test.test_multiprocessing.WithProcessesTestConnection)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 1626, in test_large_fd_transfer
    reduction.send_handle(conn, newfd, p.pid)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/multiprocessing/reduction.py", line 80, in send_handle
    _multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file number

----------------------------------------------------------------------
"""

Buildbots are running OpenIndiana 147 (this is not the last OI version, could be a OI bug).

This test seem to work correctly under Solaris 10 Update 9.

----------
messages: 143787
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing "test_fd_transfer" fails under OpenIndiana
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:29:04 2011
From: report at bugs.python.org (=?utf-8?b?4KS24KSC4KSk4KSo4KWC?=)
Date: Fri, 09 Sep 2011 19:29:04 +0000
Subject: [New-bugs-announce] [issue12951] List behavior is different
Message-ID: <1315596544.14.0.783397700321.issue12951@psf.upfronthosting.co.za>

New submission from ????? :

URL: http://docs.python.org/library/stdtypes.html

Following example is given.

>>> lists = [[]] * 3
>>> lists
[[], [], []]
>>> lists[0].append(3)
>>> lists
[[3], [3], [3]]

Behavior is as follows.

>>> a = [[]] * 3
>>> a
[[], [], []]
>>> a[0] = 1
>>> a
[1, [], []]
>>> 

Python interpreter details:

$ python
Python 2.7.2 (default, Aug 22 2011, 13:53:27) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

----------
assignee: docs at python
components: Documentation
messages: 143793
nosy: docs at python, ?????
priority: normal
severity: normal
status: open
title: List behavior is different
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:47:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 21:47:01 +0000
Subject: [New-bugs-announce] [issue12952] Solaris/Illumos (OpenIndiana)
	Scheduling policies
Message-ID: <1315604821.27.0.391952177257.issue12952@psf.upfronthosting.co.za>

New submission from Jes?s Cea Avi?n :

Solaris/Illumos (OpenIndiana) have several more Scheduling Policies, specially if the program is running under a Solaris Zone.

OpenIndiana buildbots are running under Zones, and the test is failing because current (under Zones) scheduling policy is not recognized.

I take care of this myself.

----------
assignee: jcea
messages: 143806
nosy: jcea
priority: normal
severity: normal
status: open
title: Solaris/Illumos (OpenIndiana) Scheduling policies
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 00:37:22 2011
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 09 Sep 2011 22:37:22 +0000
Subject: [New-bugs-announce] [issue12953] Function calls missing from
	profiler output
Message-ID: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>

New submission from Hagen F?rstenau :

I noticed that some function calls don't get reported by profile/cProfile. For example, 'len' works fine, but calls to 'range' or functions in 'itertools' don't show up. Is this a known limitation?

I remember that there was a bug in profiling C-functions with keyword arguments (issue5330, fixed), but I don't have the time right now to investigate whether this is related.

----------
components: Library (Lib)
messages: 143813
nosy: hagen
priority: normal
severity: normal
status: open
title: Function calls missing from profiler output
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:26:49 2011
From: report at bugs.python.org (paul j3)
Date: Fri, 09 Sep 2011 23:26:49 +0000
Subject: [New-bugs-announce] [issue12954] Multiprocessing logging under
	Windows
Message-ID: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>

New submission from paul j3 :

The Windows programming guidelines for the multiprocessing module documentation should include a warning that any logging initialization should be protected by the 'if __name__' block.  Otherwise you will get duplicate logging entries for the child processes.  This is because the multiprocessing.forking.prepare() function explicitly calls log_to_stderr(), and may implicitly do so again when it imports the parent module, resulting in duplicate logging handlers.

----------
assignee: docs at python
components: Documentation
messages: 143815
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: Multiprocessing logging under Windows

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 12:30:28 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 10 Sep 2011 10:30:28 +0000
Subject: [New-bugs-announce] [issue12955] urllib2.build_opener().open() is
	not friendly to "with	... as:"
Message-ID: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>

New submission from Valery Khamenya :

The following intuitive construction

with urllib2.build_opener().open() as:
    ...

leads to AttributeError: addinfourl instance has no attribute '__exit__'

http://docs.python.org/library/urllib2.html says almost nothing about concept of closing.

Could it be possible to add a canonical "with ... as:" example for urllib2.build_opener() ?

Thanks,
Valery

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 143836
nosy: Valery.Khamenya, docs at python
priority: normal
severity: normal
status: open
title: urllib2.build_opener().open() is not friendly to "with ... as:"
type: resource usage
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 17:55:14 2011
From: report at bugs.python.org (LMO)
Date: Sat, 10 Sep 2011 15:55:14 +0000
Subject: [New-bugs-announce] [issue12956] 2.7.2 build fails with
	--enable-framework and space in	pathname on OS X 10.7.1
Message-ID: <1315670114.35.0.572946657302.issue12956@psf.upfronthosting.co.za>

Changes by LMO :

----------
components: Build
nosy: rzn8tr
priority: normal
severity: normal
status: open
title: 2.7.2 build fails with --enable-framework and space in pathname on OS X 10.7.1
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 22:24:19 2011
From: report at bugs.python.org (Michael Schurter)
Date: Sat, 10 Sep 2011 20:24:19 +0000
Subject: [New-bugs-announce] [issue12957] mmap.resize changes memory address
	of mmap'd region
Message-ID: <1315686259.57.0.0304440203891.issue12957@psf.upfronthosting.co.za>

New submission from Michael Schurter :

Since mmap.resize uses MREMAP_MAYMOVE on Linux, it would be nice to warn users that pointers into their memory mapped regions will be invalid after resizes. Linux's manpage offers the following explanation:

"If the mapping is relocated, then absolute pointers into the old mapping location become invalid (offsets relative to the starting address of the mapping should be employed)."

Since the only way I know of to use pointers into mmaps from pure Python is to use ctypes..from_buffer(), perhaps clarification would be better in the ctypes docs.

----------
assignee: docs at python
components: Documentation
files: killctypes.py
messages: 143845
nosy: docs at python, schmichael
priority: normal
severity: normal
status: open
title: mmap.resize changes memory address of mmap'd region
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file23126/killctypes.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 07:40:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Sep 2011 05:40:43 +0000
Subject: [New-bugs-announce] [issue12958] test_socket failures on Mac OS X
Message-ID: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>

New submission from Nick Coghlan :

Several of the new socket tests introduced in #6560 are failing on the Mac OS X buildbots. These appear to be due to platform problems rather than anything in the test suite or the new sendmsg/recvmsg code, but it would be good if a developer on Mac OS X could take a closer look at them.

To avoid polluting the buildbot results, the affected tests will be flagged as expected failures when run on Mac OS X (this isn't in the repo yet, but once it is, the tests will be marked with "anticipate_failure" in the test_socket code).

----------
components: Library (Lib)
messages: 143854
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_socket failures on Mac OS X
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 14:34:46 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 11 Sep 2011 12:34:46 +0000
Subject: [New-bugs-announce] [issue12959] Add 'ChainMap' to
	collections.__all__
Message-ID: <1315744486.33.0.835466042574.issue12959@psf.upfronthosting.co.za>

New submission from July Tikhonov :

ChainMap is the only item from collections module, that is described in docs, but is not included in collections.__all__

----------
components: Library (Lib)
files: chainmap_in___all__.diff
keywords: patch
messages: 143862
nosy: july
priority: normal
severity: normal
status: open
title: Add 'ChainMap' to collections.__all__
type: feature request
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23128/chainmap_in___all__.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 15:37:19 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 11 Sep 2011 13:37:19 +0000
Subject: [New-bugs-announce] [issue12960] threading.Condition is not a class
Message-ID: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>

New submission from Nikolaus Rath :

According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class. However, in fact it turns out to be function that constructs a _Condition instance.

I don't know the reason for that, but it seems to me that either Condition should be a class, or the reason for it being a function should be documented so that people who I would like to inherit from Conditionknow if that is not supported, or if they can safely inherit from _Condition instead.

----------
assignee: docs at python
components: Documentation
messages: 143864
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: threading.Condition is not a class
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 22:01:51 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sun, 11 Sep 2011 20:01:51 +0000
Subject: [New-bugs-announce] [issue12961] unlabelled balls in boxes
Message-ID: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>

New submission from Phillip Feldman :

The current set of combinatorial functions in `itertools` does not include unlabelled balls in labeled boxes and unlabelled balls in unlabelled boxes.  If the boxes have no capacity limits (i.e., can store an unlimited number of balls), then the unlabelled balls in labelled boxes can be handled with existing tools.  But, this is a special case.  Various people have developed working Python implementations for the "unlabelled balls in labelled boxes with capacity limits" problem.  I believe that "unlabelled balls in unlabelled boxes with capacity limits" can be handled with a minor variation on the same algorithm.  It would be a great benefit to have this capability in `itertools`.

----------
messages: 143874
nosy: Phillip.M.Feldman, rhettinger
priority: normal
severity: normal
status: open
title: unlabelled balls in boxes
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 09:27:10 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Sep 2011 07:27:10 +0000
Subject: [New-bugs-announce] [issue12962] TitledHelpFormatter and
	IndentedHelpFormatter are not	documented
Message-ID: <1315812430.81.0.82881222836.issue12962@psf.upfronthosting.co.za>

New submission from anatoly techtonik :

In optparse module doc this two classes are referenced, but not documented:

http://docs.python.org/library/optparse.html

----------
components: Library (Lib)
messages: 143888
nosy: techtonik
priority: normal
severity: normal
status: open
title: TitledHelpFormatter and IndentedHelpFormatter are not documented
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:13:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 12:13:46 +0000
Subject: [New-bugs-announce] [issue12963] PyLong_AsSize_t returns (unsigned
	long)-1
Message-ID: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>

New submission from Stefan Krah :

In one of the error branches PyLong_AsSize_t() returns (unsigned long)-1
instead of (size_t)-1.

----------
components: Interpreter Core
files: pylong_as_size_t.diff
keywords: patch
messages: 143896
nosy: mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: PyLong_AsSize_t returns (unsigned long)-1
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23130/pylong_as_size_t.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:41:27 2011
From: report at bugs.python.org (Sinisa Segvic)
Date: Mon, 12 Sep 2011 12:41:27 +0000
Subject: [New-bugs-announce] [issue12964] Two improvements for the locale
	aliasing engine
Message-ID: <1315831287.41.0.402878841254.issue12964@psf.upfronthosting.co.za>

New submission from Sinisa Segvic :

Hi,

There appears to be some space for improvement
regarding the stable implementation
of the Python locale aliasing engine.

Sometimes, one wishes to be able
to override the default system locale.
For instance, it would be nice that a program
supposed to sort people according to national rules
would be able to run correctly even when the system
does not default to the national locale.

Judging from the Python manuals and
provided the desired national locale is installed,
this should be doable in at least the following two ways:

import locale
ianaLanguageSubtag='en'       # the desired national locale
locale.setlocale(locale.LC_ALL,
  (ianaLanguageSubtag, locale.getpreferredencoding())) #(1)
locale.setlocale(locale.LC_ALL,
  locale.normalize(ianaLanguageSubtag))                #(2)

For a quicker reference, this is
the relevant part of the manual:
http://docs.python.org/release/3.2/library/locale.html
'''
locale.setlocale(category, locale=None)
  ...
  If (the locale) is a tuple, it is converted
  to a string using the locale aliasing engine.
  ...
'''

The locale aliasing engine binds
the IANA language subtags to POSIX locales.
Its effects can be directly observed
through locale.normalize:
>>> import locale
>>> locale.normalize('hr')
'hr_HR.ISO8859-2'
>>> locale.normalize('en')
'en_US.ISO8859-1'

My first objection concerns the Windows behaviour
of the calls (1) and (2) above.
Both of the two calls *do not work* since Windows
does not recognize strings such as 'en_US.ISO8859-1'.
Instead, Windows provides their own locale nomenclature:
http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.80%29.aspx
Consequently, the following *works*:

locale.setlocale(locale.LC_ALL, 'English_United States.1252')

IMHO this issue should be fixed, perhaps by providing
an alternate definition of the locale alias dictionary
(locale.locale_alias).

My second objection concerns the behaviour on Linux,
where the call (1) above always works,
while (2) in some cases might not work.
It happens that the call (2)
requests an outdated 8-bit encoding
although UTF8 has obtained a world-wide acceptance.
The call shall result in a locale error
whenever the desired national locale
is present only in the UTF8 variant.

This might be fixed by changing the encodings
in the locale.locale_alias from 8-bit variants to UTF8.
Note however that the problem could be circumvented
by issuing the call (1), so this would be
less important than the Windows fix proposed above.

Source code references:
  .../Python-3.2.2/Lib/locale.py
  locale.locale_alias
  locale.normalize
  locale.setlocale

comp.lang.python discussion:
  http://groups.google.com/group/comp.lang.python/browse_thread/thread/3591d496cf108ad2#

Cheers,

Sinisa

----------
components: Library (Lib), Windows
messages: 143902
nosy: ssegvic
priority: normal
severity: normal
status: open
title: Two improvements for the locale aliasing engine
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:57:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 16:57:50 +0000
Subject: [New-bugs-announce] [issue12965] longobject: documentation
	improvements
Message-ID: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>

New submission from Stefan Krah :

I think the integer objects documentation could be clearer on a
couple of points:

  - Despite being listed under "Concrete Objects Layer", some
    functions implicitly accept anything with an __int__()
    method. Currently only the PyLong_AsLong() documentation
    states this explicitly.

    The patch clearly distinguishes between functions that
    duck type and functions that don't. 

  - The patch replaces "is greater than *_MAX" instances with
    "out of bounds" to include the other error condition
    "is less than *_MIN".

Additionally, the patch fixes comments in longobject.c that
don't state the duck typing behavior.

----------
assignee: docs at python
components: Documentation
files: longobject-doc.diff
keywords: patch
messages: 143922
nosy: docs at python, mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: longobject: documentation improvements
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23133/longobject-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:14:40 2011
From: report at bugs.python.org (Paulie Pena)
Date: Mon, 12 Sep 2011 19:14:40 +0000
Subject: [New-bugs-announce] [issue12966] cookielib.LWPCookieJar breaks on
	cookie values with a	newline
Message-ID: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>

New submission from Paulie Pena :

Even though RFC 6265's cookie-value's cookie-octet definition says that whitespace characters are not allowed (see http://tools.ietf.org/html/rfc6265), there are non-compliant web sites that send cookie values with newlines.  cookielib.LWPCookieJar will save the bad value in a cookie file, but when it tries to load it, it probably is only splitting by newlines, so it crashes on the invalid line.  The easiest thing would probably be to just ignore cookies that have values with a newline.  (Note: I'm using Python 2.5, so this might have been fixed in a later version.)

----------
components: Library (Lib)
messages: 143928
nosy: paulie4
priority: normal
severity: normal
status: open
title: cookielib.LWPCookieJar breaks on cookie values with a newline
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 06:38:10 2011
From: report at bugs.python.org (ben)
Date: Tue, 13 Sep 2011 04:38:10 +0000
Subject: [New-bugs-announce] [issue12967] AttributeError distutils\log.py
Message-ID: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>

New submission from ben :

AttributeErrors on log.py in the distutils directory

import sys
stream = sys.stdout
if stream.errors == 'strict': pass'=> this will raise an AttributeError'

----------
assignee: tarek
components: Distutils
files: log.py
messages: 143949
nosy: Ben.thelen, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: AttributeError distutils\log.py
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file23136/log.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 08:51:35 2011
From: report at bugs.python.org (=?utf-8?b?SmnFmcOtIEt1xI1lcmE=?=)
Date: Tue, 13 Sep 2011 06:51:35 +0000
Subject: [New-bugs-announce] [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
Message-ID: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>

New submission from Ji?? Ku?era :

Invoking the `close' method of `_io.BufferedWriter' instance created by `open(0,"wb")' command cause the Python interpreter crash.

Python interpreter info:
  mode: interactive
  version info: Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500 32 bit (Intel)] on win32

Operanting system info:
  Microsoft Windows XP
  Home Edition
  Version 2002
  Service Pack 3

Commands:
>>> fd = open(0,"wb")
>>> fd.close()

----------
components: Interpreter Core
messages: 143951
nosy: i386x
priority: normal
severity: normal
status: open
title: Command 'open(0,"wb").close()' cause crash of Python interpreter [interactive mode]
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:02:12 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:02:12 +0000
Subject: [New-bugs-announce] [issue12970] os.wlak() consider some symlinks
	as dirs instead of	non-dirs
Message-ID: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>

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

Consider code:

for (root, dirs, nondirs) in os.walk(path, followlinks=False):
    print (nondirs)

This code will not print symlinks that refer to some dir. I think it is the bug.

In other words: If followlinks is True, we should consider some symlinks as dirs. If not, any symlink is the non-dir.

Patch included.

Also, please fix documentation about this nuance.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: z.patch
keywords: patch
messages: 143965
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: os.wlak() consider some symlinks as dirs instead of non-dirs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23140/z.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:23:58 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:23:58 +0000
Subject: [New-bugs-announce] [issue12971] os.isdir() should contain
	skiplinks=False in arguments
Message-ID: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za>

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

When skiplinks is False (by default), it should as in current implementation, i.e. using stat().

if skiplinks is True, isidr() should use lstat() and same logick. 

If one will be implemented, os.walk() should be patched (see issue12970) to use this new isdir() with this new parameter instead of own logick in os.walk().

----------
components: Library (Lib)
messages: 143968
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.isdir() should contain skiplinks=False in arguments
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:29:32 2011
From: report at bugs.python.org (Damian)
Date: Tue, 13 Sep 2011 15:29:32 +0000
Subject: [New-bugs-announce] [issue12972] Color prompt + readline
Message-ID: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za>

New submission from Damian :

Hi, when using terminal coloring codes (for instance '\x1b[32mhello world\x1b[0m' for a green 'hello world') the raw_input function and readline module behave well except under a very specific use case...

========================================

import readline # provides history via up/down

prompt = '\x1b[32m>>> \x1b[0m' # green '>>> ' prompt

while True:
  raw_input(prompt)

========================================

This provides a green prompt and up/down cycles through prior input. This works well as long as the input is shorter than the prompt string length (in this case 13 characters). However, if the input is longer than the prompt then up/down thinks that the first thirteen rendered characters now belong to the prompt. For instance...

atagar at fenrir:~/Desktop/arm$ python tmp.py 
>>> http://docs.python.org/library/readline

Press up, then down to get back to a blank prompt. You'll have...
>>> http://do

This is probably due to a len() check on the raw_input argument...
>>> len('>>> http://do')
13
>>> len('\x1b[32m>>> \x1b[0m')
13

I'm at a bit of a loss for investigating this further - help would be appreciated! -Damian

----------
messages: 143977
nosy: atagar1
priority: normal
severity: normal
status: open
title: Color prompt + readline
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 21:46:50 2011
From: report at bugs.python.org (Adam)
Date: Tue, 13 Sep 2011 19:46:50 +0000
Subject: [New-bugs-announce] [issue12973] int_pow() implementation is
	incorrect
Message-ID: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>

New submission from Adam :

int_pow() (from Objects/intobject.c) shows incorrect results when Python is compiled with Clang (llvm.org); long story short: int_pow() function should use 'unsigned long' type instead of 'long' or some code gets optimised out.

Please, refer to this bug report to find out the details:
http://llvm.org/bugs/show_bug.cgi?id=10923

----------
messages: 143985
nosy: adam at NetBSD.org
priority: normal
severity: normal
status: open
title: int_pow() implementation is incorrect
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 02:48:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 00:48:15 +0000
Subject: [New-bugs-announce] [issue12974] array module: deprecate '__int__'
	conversion support for	array elements
Message-ID: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za>

New submission from Meador Inge :

When reviewing the fix for issue1172711 it was discovered that the 'array' module allows for '__int__' conversions:

>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])

As discussed in issue1172711, this behavior may not be desirable.  We should look at deprecating '__int__' and adding '__index__' as was done for the struct module in issue1530559.

----------
components: Library (Lib)
messages: 144000
nosy: mark.dickinson, meadori, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: array module: deprecate '__int__' conversion support for array elements
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:57:19 2011
From: report at bugs.python.org (Benny Siegert)
Date: Wed, 14 Sep 2011 11:57:19 +0000
Subject: [New-bugs-announce] [issue12976] select module: only use
	EVFILT_TIMER if available	(kqueue backend)
Message-ID: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>

New submission from Benny Siegert :

When building python-2.6 on MirBSD, building the select module (which uses the kqueue backend on this platform) fails. This is because EVFILT_TIMER is not available on the platform.

The proposed patch is for python-2.6 but should apply to tip too.

This was discovered when building the python package from NetBSD pkgsrc, so the patch is taken from there.

----------
components: Extension Modules
files: patch-az
messages: 144022
nosy: bsiegert
priority: normal
severity: normal
status: open
title: select module: only use EVFILT_TIMER if available (kqueue backend)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file23153/patch-az

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 15:41:59 2011
From: report at bugs.python.org (Florian Ludwig)
Date: Wed, 14 Sep 2011 13:41:59 +0000
Subject: [New-bugs-announce] [issue12977] socket.socket.setblocking does not
	raise exception if no	data available
Message-ID: <1316007719.98.0.0164178020562.issue12977@psf.upfronthosting.co.za>

New submission from Florian Ludwig :

The documentation states:

> In non-blocking mode, if a recv() call doesn?t find any data, [...], a error exception is raised; [0]

Which is wrong. If no data is available recv() does not raise an exception but returns an empty string.

[0] http://docs.python.org/library/socket.html#socket.socket.setblocking

----------
assignee: docs at python
components: Documentation
messages: 144024
nosy: Florian.Ludwig, docs at python
priority: normal
severity: normal
status: open
title: socket.socket.setblocking does not raise exception if no data available
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 17:35:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Sep 2011 15:35:26 +0000
Subject: [New-bugs-announce] [issue12978] Figure out extended attributes on
	BSDs
Message-ID: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>

New submission from Benjamin Peterson :

Extended attribute support currently exists in the os module for Linux. BSD's (including OSX) have a similar (but of course incompatible) interface. They should be exposed through the same functions. For example,

os.getxattr("myfile", "user.whatever")

should call on the C level

getxattr("myfile", "user.whatever", value, sizeof(value), 0, 0);

----------
messages: 144028
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Figure out extended attributes on BSDs
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:39:32 2011
From: report at bugs.python.org (ilikepython)
Date: Wed, 14 Sep 2011 18:39:32 +0000
Subject: [New-bugs-announce] [issue12979] tkinter.font.Font object not
	usable as font option
Message-ID: <1316025572.88.0.893423233334.issue12979@psf.upfronthosting.co.za>

New submission from ilikepython :

If a Font object is passed as a font option to a Tk widget e. g.:

import tkinter
import tkinter.font

f = tkinter.font.Font(family='Arial', size=30)
root = Tk()
label = tkinter.Label(root, text="Hello", font=f)
label.pack()

the font does not get respected at runtime.

----------
messages: 144036
nosy: ilikepython
priority: normal
severity: normal
status: open
title: tkinter.font.Font object not usable as font option
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:36:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:36:33 +0000
Subject: [New-bugs-announce] [issue12980] segfault in test_json on AMD64
	FreeBSD 8.2 2.7
Message-ID: <1316028993.76.0.263196651772.issue12980@psf.upfronthosting.co.za>

New submission from STINNER Victor :

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/301

---------------------------------------------
[ 44/359] test_json
Fatal Python error: Segmentation fault

Current thread 0x00000008010041c0:
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  ...
*** Signal 11
---------------------------------------------

Can it be an unlimited loop (recursive loop)? It looks like a stack overflow.

----------
components: Library (Lib)
messages: 144045
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: segfault in test_json on AMD64 FreeBSD 8.2 2.7
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:51:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 19:51:24 +0000
Subject: [New-bugs-announce] [issue12981] rewrite multiprocessing
	(senfd|recvfd) in Python
Message-ID: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>

New submission from Charles-Fran?ois Natali :

Now that sendmsg()/recvmsg() are exposed in socketmodule, we could use them to replace the ad-hoc FD-passing routines used by multiprocessing.reduction.
Antoine suggested adding sendfd()/recvfd() methods to socket objects, but I'm not sure about this, since those only make sense for Unix domain sockets.
Two remarks on the patch attached:
- this removes sendfd()/recvfd() from _multiprocessing (but AFAICT those were never documented as part of the public API)
- EOF/invalid data received result in a RuntimeError

----------
components: Library (Lib)
files: multiprocessing_fd.diff
keywords: patch
messages: 144047
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: rewrite multiprocessing (senfd|recvfd) in Python
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23156/multiprocessing_fd.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 22:32:43 2011
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Wed, 14 Sep 2011 20:32:43 +0000
Subject: [New-bugs-announce] [issue12982] .pyo file cannot be imported
Message-ID: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>

New submission from Eric O. LEBIGOT :

When creating a .pyo file (either with -O or -OO) and removing any .pyc or .py original file, import  complains with "No module called ".  The import does work with .pyc files.

I'm not sure that this is the correct behavior, as the documentation does not seem to make any difference between .pyc and .pyo files on this point:

"It is possible to have a file called spam.pyc (or spam.pyo when -O is used) without a file spam.py for the same module. This can be used to distribute a library of Python code in a form that is moderately hard to reverse engineer."

----------
components: Interpreter Core
messages: 144049
nosy: lebigot
priority: normal
severity: normal
status: open
title: .pyo file cannot be imported
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 00:51:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Sep 2011 22:51:36 +0000
Subject: [New-bugs-announce] [issue12983] byte string literals with invalid
	hex escape codes raise	ValueError instead of SyntaxError
Message-ID: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>

New submission from Ned Deily :

In behavior carried over from Python 2 string literals, Python 3 byte string literals raise a less helpful ValueError exception when an invalid hex escape code is given:

    >>> x = b'\x0'
    ValueError: invalid \x escape

A string literal raises a SyntaxError and a full traceback including line number:

    >>> x = '\x0'
      File "", line 1
    SyntaxError: (unicode error) 'unicodeescape' codec can't decode
     bytes in position 0-2: end of string in escape sequence

----------
components: Interpreter Core
messages: 144059
nosy: ned.deily
priority: normal
severity: normal
status: open
title: byte string literals with invalid hex escape codes raise ValueError instead of SyntaxError
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 01:11:48 2011
From: report at bugs.python.org (Matthew Newcomb)
Date: Wed, 14 Sep 2011 23:11:48 +0000
Subject: [New-bugs-announce] [issue12984] XML NamedNodeMap ( attribName in
	NamedNodeMap fails )
Message-ID: <1316041908.49.0.966708119681.issue12984@psf.upfronthosting.co.za>

New submission from Matthew Newcomb :

I was cleaning up some old code to make it pep8 compliant and came across this bug.  Switching from 'has_key' to 'in' does not work with a xml.dom.minidom.NamedNodeMap.  An easy solution appears to be to add a '__contains__' method to NamedNodeMap.  

This is with:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2

I've tried it with 2.4.3 as well ( on some older machines ).

import xml.dom.minidom

def show_bug():
    document = 'foobar_attributes'
    dom = xml.dom.minidom.parseString(document)
    attribs = dom.getElementsByTagName('dom')[0].attributes

    if attribs.has_key('mbid'):
        print "This works..  found 'mbid' attribute"

    if 'mbid' in attribs:
        print "Will never get here, the above will throw an exception"

>>> show_bug()
This works..  found 'mbid' attribute
Traceback (most recent call last):
  File "", line 1, in 
  File "show_bug.py", line 11, in show_bug
    if 'mbid' in attribs:
  File "/usr/lib/python2.7/xml/dom/minidom.py", line 524, in __getitem__
    return self._attrs[attname_or_tuple]
KeyError: 0

----------
components: XML
files: show_bug.py
messages: 144060
nosy: spolematt
priority: normal
severity: normal
status: open
title: XML NamedNodeMap ( attribName in NamedNodeMap fails )
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file23157/show_bug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:34:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 09:34:37 +0000
Subject: [New-bugs-announce] [issue12985] Check signed arithmetic overflow
	in ./configure
Message-ID: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>

New submission from Stefan Krah :

I'm not sure if this is a good idea: I wonder if it would be an option
to check for overflow behavior at the bottom of ./configure and print a
warning. The patch appears to work for gcc, clang and suncc. It would
have caught the problem in #12973.

The Intel compiler is the odd one here. Even with -O0 this particular
overflow is undefined, but I can't remember seeing the specific
test failures from #12973. So the drawback is that the patch might
give false positives.

$ cat overflow_is_defined.c
#include 
int overflow_is_defined(int x) {
    if (x + 1000 < x)
        return 0;
    return 1;
}
int main() {
    return overflow_is_defined(INT_MAX);
}

gcc-4.4.3
=========

$ gcc -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ gcc -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
overflow_is_defined.c: In function ?overflow_is_defined?:
overflow_is_defined.c:3: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
$ ./overflow_is_defined || echo "undefined"
undefined
$ gcc -Wall -W -O2 -fwrapv -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

clang-3.0
=========

$ clang -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ clang -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ clang -Wall -W -fwrapv -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

suncc-12.2
==========

$ suncc -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ suncc -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

icc-12.0.0
==========

$ icc -Wall -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ icc -Wall -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$

----------
files: configure_catch_overflow.diff
keywords: patch
messages: 144071
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Check signed arithmetic overflow in ./configure
type: feature request
Added file: http://bugs.python.org/file23160/configure_catch_overflow.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:30:17 2011
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 15 Sep 2011 16:30:17 +0000
Subject: [New-bugs-announce] [issue12986] Using getrandbits() in
	uuid.uuid4() is faster and more	readable
Message-ID: <1316104217.68.0.381815581788.issue12986@psf.upfronthosting.co.za>

New submission from Matt Chaput :

Currently the 'uuid' module uses os.urandom (in the absence of a system UUID generation function) to generate random UUIDs in the uuid.uudi4() function. This patch changes the implementation of uuid4() to use random.getrandbits() as the source of randomness instead, for the following reasons:

* In my quick tests, using getrandbits() is much faster on Windows and Linux. Some applications do need to generate UUIDs quickly.

  >>> setup = "import uuid, os, random"
  >>> ur = "uuid.UUID(bytes=os.urandom(16), version=4)"
  >>> grb = "uuid.UUID(int=random.getrandbits(128), version=4)"
  >>> # Windows --------
  >>> timeit.Timer(ur, setup).timeit()
  22.861042160383903
  >>> timeit.Timer(grb, setup).timeit()
  3.8689128309085135
  >>> # Linux --------
  >>> timeit.Timer(ur, setup).timeit()
  29.32686185836792
  >> timeit.Timer(grb, setup).timeit()
  3.7429409027099609

* The patched code is cleaner. It avoids the try...finally required by the possibly unavailable os.urandom function, and the fallback to generating random bytes.

----------
components: Library (Lib)
files: fastuuid4.patch
keywords: patch
messages: 144087
nosy: mattchaput
priority: normal
severity: normal
status: open
title: Using getrandbits() in uuid.uuid4() is faster and more readable
type: performance
Added file: http://bugs.python.org/file23163/fastuuid4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 19:06:16 2011
From: report at bugs.python.org (jan matejek)
Date: Thu, 15 Sep 2011 17:06:16 +0000
Subject: [New-bugs-announce] [issue12987] Demo/scripts/newslist.py has
	non-commercial license	clause
Message-ID: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za>

New submission from jan matejek :

from Demo/scripts/newslist.py :

# Feel free to copy, distribute and modify this code for
# non-commercial use. If you make any useful modifications, let me
# know!
#
# (c) Quentin Stafford-Fraser 1994
# fraser at europarc.xerox.com                     qs101 at cl.cam.ac.uk

this is not very nice for commercial distros - we have to drop the file (for now anyway)

i'm not sure what the "right" solution for upstream is - you might want to remove the file, ask Quentin to relicense it, or just acknowledge its existence and keep it

----------
components: Demos and Tools
messages: 144088
nosy: matejcik
priority: normal
severity: normal
status: open
title: Demo/scripts/newslist.py has non-commercial license clause
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:45:06 2011
From: report at bugs.python.org (Brian Gernhardt)
Date: Thu, 15 Sep 2011 21:45:06 +0000
Subject: [New-bugs-announce] [issue12988] IDLE on Win7 crashes when saving
	to Documents Library
Message-ID: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>

New submission from Brian Gernhardt :

Python 3.2.1 (default, Jul 10 2011, 20:02:51) [MSC v.1500 64 bit (AMD64)] on win32

Steps:
1) Start IDLE
2) Open Save dialog (File > Save or Ctrl-S)
3) Select Libraries from the buttons on the left or the dropdown on top.
4) Double-click on Documents
5) Enter any file name (test.txt)
6) Hit enter or click save
7) See "pythonw.exe has stopped working dialog"

I tried running it from the command line (via c:\python32\python -m idlelib.idle) and it produced no useful error messages.

----------
components: IDLE
messages: 144106
nosy: Brian.Gernhardt
priority: normal
severity: normal
status: open
title: IDLE on Win7 crashes when saving to Documents Library
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 02:08:16 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Fri, 16 Sep 2011 00:08:16 +0000
Subject: [New-bugs-announce] [issue12989] Consistently handle path separator
	in Py_GetPath on	Windows
Message-ID: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>

New submission from Nam Nguyen :

The module search path is constructed from PYTHONPATH env-var, then zip path, then HKCU PythonPath, then HKLM PythonPath, then PYTHONPATH define (in pyconfig.h), and finally argv[0]. If PYTHONHOME is available, the PYTHONPATH define is expanded. These paths are separated by semicolon.

Without PYTHONHOME, PYTHONPATH define is appended to module_search_path as-is, and a semicolon comes **after** that. With PYTHONHOME, PYTHONPATH define is expanded, and there is no semicolon after it. Then, finally, when argv[0] is added to module_search_path, a semicolon is **prepended** before it.

This inconsistency in handling path delimiter leads to a case where two semicolons are next to each other (;;), which is translated to the current directory. It happens when PYTHONHOME is not found. The current directory is put in front of the application directory (argv[0]) causing a security issue whereby external modules might be imported inadvertently.

This patch makes semicolon handling consistent. A semicolon is appended at the end of every path component, except argv[0].

----------
components: Interpreter Core, Windows
files: getpath.consistent.delim.patch
keywords: patch
messages: 144111
nosy: Nam.Nguyen
priority: normal
severity: normal
status: open
title: Consistently handle path separator in Py_GetPath on Windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23169/getpath.consistent.delim.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:19:49 2011
From: report at bugs.python.org (Ricky Teng)
Date: Fri, 16 Sep 2011 10:19:49 +0000
Subject: [New-bugs-announce] [issue12990] launcher can't work on path
	including tradition chinese	char
Message-ID: <1316168389.55.0.517137945943.issue12990@psf.upfronthosting.co.za>

Changes by Ricky Teng :

----------
assignee: ronaldoussoren
components: Macintosh
nosy: Ricky.Teng, ronaldoussoren
priority: normal
severity: normal
status: open
title: launcher can't work on path including tradition chinese char
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:43:00 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 11:43:00 +0000
Subject: [New-bugs-announce] [issue12991] Python 64-bit build on HP Itanium
	- Executable built	successfully but modules failed with HP Compiler
Message-ID: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za>

New submission from Wong Wah Meng :

Server Info: HP-UX B.11.31 Itanium ia64.
Evaluation copy is used however the license is being purchased, hopefully this are not these errors are not caused by evaluation copy.

# swlist -l product | grep Compiler
  ACXX                  C.06.26.EVAL   HP C/aC++ Compiler 
  C-ANSI-C              C.06.26.EVAL   HP C/aC++ Compiler 
  COMPLIBS              B.11.31        Compiler Support Libraries 

I encountered more failures in module build with my HP-UX ANSI C Compiler versus gcc. I wonder why. I need a Oracle plug-in later, i.e. cx_Oracle and the reason I do not want to ignore these errors now because I thought cx_Oracle will have to (or, better) be built using HP compiler, not gcc for support from Oracle. 

I read through the README file, I followed the instruction to set the required environment variables before the configure is run, and unset them before make is run, also edited Makefile to remove Optimization and the -Olimit 1500. However, it gives me a lot more modules that are failed to be built versus 2 when gcc is used. At the bottom of the mail we can see what failed to be built. 

I have summarized my inquiry as follow:-
1.) Despite following the instruction to edit the Makefile before make is run, I am surprise to see that the Makefile content is changed again when the executable is generated. The changed I edited is restored. Is this expected and did the compiler make use of the content that I edited when it did the build and link? 

$ diff Makefile Makefile_Original
61,62c61,62
< OPT=          -DNDEBUG -O
< BASECFLAGS=   +DD64 -Olimit 1500
---
> OPT=          -DNDEBUG
> BASECFLAGS=   +DD64

2.) A lot of failed module and I suspected it is due +DD64 nopt recognized by the compiler. Why the HP-UX compiler did not recognize the option? 

ld -b +DD64 -lxnet build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/mathmodule.o build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/_math.o -L/usr/local/lib -lm -o build/lib.hp-ux-B.11.31-ia64-2.7/math.so
ld: Unrecognized argument: +DD64
Fatal error.

3.) This is a general question, in the README file there isn't specific instruction on how to enable gcc for 64-bit build. Does gcc support 64-bit build and how to?

4.) These are warning message. I have seen a lot of them. Am I right I can ignore them? I don't see them when I use gcc though. 

        cc -Ae -c +DD64 -g -DNDEBUG  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
"Include/pyfpe.h", line 8: warning #3750-D: "\" followed by white space is not a line splice

Thanks in advance for your input. Here is the output of my make using HP C compiler. 

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _curses            _curses_panel   
_sqlite3           _ssl               _tkinter        
bsddb185           bz2                dl              
gdbm               imageop            linuxaudiodev   
ossaudiodev        readline           spwd            
sunaudiodev        zlib                               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_bisect            _codecs_cn         _codecs_hk      
_codecs_iso2022    _codecs_jp         _codecs_kr      
_codecs_tw         _collections       _csv            
_ctypes            _ctypes_test       _elementtree    
_functools         _heapq             _hotshot        
_io                _json              _locale         
_lsprof            _md5               _multibytecodec 
_multiprocessing   _random            _sha            
_socket            _struct            _testcapi       
array              audioop            binascii        
cmath              cPickle            crypt           
cStringIO          datetime           dbm             
fcntl              future_builtins    grp             
itertools          math               mmap            
nis                operator           parser          
pyexpat            resource           select          
strop              syslog             termios         
time               unicodedata                        

running build_scripts

----------
components: Build
messages: 144123
nosy: wah meng
priority: normal
severity: normal
status: open
title: Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:23:22 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 12:23:22 +0000
Subject: [New-bugs-announce] [issue12992] Python build finished,
	but the necessary bits to build these modules were not found:
	_tkinter
Message-ID: <1316175802.51.0.740552144626.issue12992@psf.upfronthosting.co.za>

New submission from Wong Wah Meng :

Hello there,

I am building python on HP-UX 11.31 (Itanium ia64). I would like to utilize the _tkinter module in my application however I failed to build it. I think this module requires additional tcl + tk source code placed into certain directory and the configure will do the build accordingly. Can someone let me know what files are needed and where should I place them in terms of directory structure, so that I can build python with that built-in module successfully? Thanks!

(PS: I am able to build tcl tk 8.5.9 successfully on the same box however I am not sure how to link that piece of work into python build)

----------
components: Tkinter
messages: 144128
nosy: wah meng
priority: normal
severity: normal
status: open
title: Python build finished, but the necessary bits to build these modules were not found: _tkinter
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:34:19 2011
From: report at bugs.python.org (Mayur & Angela Patel-Lam)
Date: Fri, 16 Sep 2011 12:34:19 +0000
Subject: [New-bugs-announce] [issue12993] prepared statements in sqlite3
	module
Message-ID: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>

New submission from Mayur & Angela Patel-Lam :

The sqlite3 module is wonderful, but the one advantage that C/C++ coders have using that system is the ability to use precompiled/prepared SQL statements.  Some SQL databases like Postgresql allow you to precompile statements using special SQL statements (e.g. PREPARE), so there is no need to change the python DBI for those database systems.  But unfortunately, sqlite3 only offers a C/C++ function, which returns a handle to the prepared statement.  I have sought a way to call this from the python DBI, but I simply don't think it's exposed.

Since my application interleaves several SQL commands, depending on the results of the last iteration, I can't immediately use executemany() to obtain maximum performance on my code.  Precompiled statements offer me the best opportunity to optimize.  I can prepare the 2 or 3 most expensive queries in my loop and call them in whatever order I need.  There are some estimates that prepared statements can accelerate complex queries by an order of magnitude, as the parser and optimizers don't need to come into play for every call.

Would you consider an extension to the sqlite3 DBI to expose prepared statements?  Thanks.

----------
components: Library (Lib)
messages: 144129
nosy: Mayur.&.Angela.Patel-Lam
priority: normal
severity: normal
status: open
title: prepared statements in sqlite3 module
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:36:38 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 12:36:38 +0000
Subject: [New-bugs-announce] [issue12994] cx_Oracle failed to load in newly
	build python 2.7.1
Message-ID: <1316176598.1.0.658499058413.issue12994@psf.upfronthosting.co.za>

New submission from Wong Wah Meng :

Platform : HP-UX 11.31 on Itanium ia64. 
HP Compiler: 
# swlist -l product | grep Compiler
  ACXX                  C.06.26.EVAL   HP C/aC++ Compiler 
  C-ANSI-C              C.06.26.EVAL   HP C/aC++ Compiler 
  COMPLIBS              B.11.31        Compiler Support Libraries 

I downloaded cx_Oracle5.1 source code and run python setup.py build and able to build the module. However, when I import the module it just cannot load without giving any explicit indication what goes wrong. Does anyone knows why?

$ python setup.py build
running build
running build_ext
building 'cx_Oracle' extension
creating build
creating build/temp.hp-ux-B.11.31-ia64-2.7-11g
cc -Ae -Olimit 1500 -g -DNDEBUG -O +z -I/opt/oracle/product/11.1.0/rdbms/demo -I/opt/oracle/product/11.1.0/rdbms/public -I/home/r32813/Build/2.7.1/Python-2.7.1/Include -I/home/r32813/Build/2.7.1/Python-2.7.1/Lib/.. -c cx_Oracle.c -o build/temp.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.o -DBUILD_VERSION=5.0
cc: warning 1913: `1500' does not exist or cannot be read
"/home/r32813/Build/2.7.1/Python-2.7.1/Include/pyfpe.h", line 8: warning #3750-D: 
          "\" followed by white space is not a line splice
      /                       Copyright (c) 1996.                           \ 
                                                                            ^

"NumberVar.c", line 306: warning #4232-D: conversion from "PyObject *" to a
          more strictly aligned type "PyFloatObject *" may cause misaligned
          access
      doubleValue = PyFloat_AS_DOUBLE(value);
                    ^

"NumberVar.c", line 579: warning #4232-D: conversion from "PyObject *" to a
          more strictly aligned type "PyFloatObject *" may cause misaligned
          access
      var->data[pos] = PyFloat_AS_DOUBLE(value);
                       ^

creating build/lib.hp-ux-B.11.31-ia64-2.7-11g
ld -b build/temp.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.o -L/opt/oracle/product/11.1.0/lib32 -L/opt/oracle/product/11.1.0 -lclntsh -o build/lib.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.so

$ ls -lrt build 
total 0
drwx------   2 r32813     users           96 Sep 16 20:33 temp.hp-ux-B.11.31-ia64-2.7-11g
drwx------   2 r32813     users           96 Sep 16 20:33 lib.hp-ux-B.11.31-ia64-2.7-11g
$ cp build/lib.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.so $PYTHONPATH
$ python
iPython 2.7.1 (r271:86832, Sep 15 2011, 14:46:37) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> import cx_Oracle
Traceback (most recent call last):
  File "", line 1, in 
ImportError: Failed to load /home/r32813/Build/2.7.1/Python-2.7.1/Lib/cx_Oracle.so
>>> 
$ env  | grep PYTHON
PYTHONPATH=/home/r32813/Build/2.7.1/Python-2.7.1/Lib
$

----------
components: Extension Modules
messages: 144130
nosy: wah meng
priority: normal
severity: normal
status: open
title: cx_Oracle failed to load in newly build python 2.7.1
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 19:50:14 2011
From: report at bugs.python.org (Vincent Vande Vyvre)
Date: Fri, 16 Sep 2011 17:50:14 +0000
Subject: [New-bugs-announce] [issue12995] Different behaviours with  between v3.1.2 and	v3.2.2
Message-ID: <1316195414.51.0.601610361957.issue12995@psf.upfronthosting.co.za>

New submission from Vincent Vande Vyvre :

Hi,

Trying this code:

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

# -*- coding: utf-8 -*-

import os
import sys
import platform

print('\nPython version: ', sys.version.split()[0])
print(platform.platform())

paths = ['/home/vincent/image.jpg', '/home/vincent/?????.jpg']

for path in paths:
    print('\n', type(path))
    try:
        print(path)
    except UnicodeEncodeError as why:
        print('print > {0}'.format(why))
    try:
        if not os.path.exists(path):
            print('File not found!')
        else:
            print('File exists')
    except UnicodeEncodeError as why:
        print('os.path.exist > {0}'.format(why))
    try:
        stats = os.stat(path)
        print(stats.st_atime)
    except UnicodeEncodeError as why:
        print('os.stat > {0}'.format(why))
    try:
        f = open(path, 'b')
        f.close()
    except Exception as why:
        print('open > {0}'.format(why))

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

on python 3.1.2:

------------------------------------
vincent at tiemoko:~/Python/oqapy/devel$ python3 test_string.py 

Python version:  3.1.2
Linux-2.6.32-33-generic-i686-with-Ubuntu-10.04-lucid

/home/vincent/image.jpg
File exists
1316179838.94
open > Must have exactly one of read/write/append mode

/home/vincent/?????.jpg
File exists
1316179838.81
open > Must have exactly one of read/write/append mode
vincent at tiemoko:~/Python/oqapy/devel$ 

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

on python 3.2.2:

------------------------------------------------
[vincent at myhost ~]$ python test_string.py

Python version:  3.2.2
Linux-3.0-ARCH-x86_64-Pentium-R-_Dual-Core_CPU_T4500_ at _2.30GHz-with-glibc2.2.5

/home/vincent/image.jpg
File exists
1316187109.6772401
open > Must have exactly one of read/write/append mode and at most one plus

print > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
os.path.exist > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
os.stat > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
open > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
[vincent at myhost ~]$

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

Any 'path = path.decode('utf-8')', 'encode(bhla)', 'sys.getfilesystemencoding()', 'magic_transform(abracadabra)'
don't change anythings.

Thanks for yours advice.

vince

----------
components: Unicode
messages: 144143
nosy: VinsS
priority: normal
severity: normal
status: open
title: Different behaviours with  between v3.1.2 and v3.2.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:40:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Sep 2011 18:40:55 +0000
Subject: [New-bugs-announce] [issue12996] multiprocessing.Connection
	endianness issue
Message-ID: <1316198455.11.0.87432837805.issue12996@psf.upfronthosting.co.za>

New submission from Charles-Fran?ois Natali :

Since the rewrite in pure Python of multiprocessing.Connection (issue #11743), multiprocessing.Connection sends and receives the length of the data (used as header) in host byte order.
This will break if the connection's endpoints are on machine with different endianness.
Patch attached (it also removes an unnecessary computation of the length of the data being sent).

----------
components: Library (Lib)
files: multiprocessing_conn_endianness.diff
keywords: needs review, patch
messages: 144148
nosy: haypo, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing.Connection endianness issue
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23171/multiprocessing_conn_endianness.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 00:54:19 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Fri, 16 Sep 2011 22:54:19 +0000
Subject: [New-bugs-announce] [issue12997] sqlite3: PRAGMA foreign_keys = ON
	doesn't work
Message-ID: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>

New submission from Mark Bucciarelli :

If I read http://bugs.python.org/issue10740#msg132470 correctly, the foreign_keys PRAGMA is a no-op b/c "The python sqlite module automatically commits open transactions when it encounters a DDL statement."

Entering as a separate issue as I'm not sure solving 10740 is required to solve this one.

----------
components: None
files: t.py
messages: 144166
nosy: Mark.Bucciarelli
priority: normal
severity: normal
status: open
title: sqlite3: PRAGMA foreign_keys = ON doesn't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23177/t.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:29:26 2011
From: report at bugs.python.org (M)
Date: Sat, 17 Sep 2011 06:29:26 +0000
Subject: [New-bugs-announce] [issue12998] Memory leak with CTypes Structure
Message-ID: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>

New submission from M :

When using Python 2.5.4 on Windows (and potentially other versions and platforms), usage of CTypes like the following cause a memory leak.  The memory leak can be verified with ProcessExplorer, as the memory Python takes up keeps increasing until eventually Python will get a MemoryError.
----
import ctypes
def hi():
    class c1(ctypes.Structure):
            _fields_=[('f1',ctypes.c_uint8)]
    class c2(ctypes.Structure):
            _fields_=[('g1',c1*2)]

while True:
    test=hi()
----

This is true even if the garbage collector is called explicitly:
----
import gc
import ctypes
def hi():
    class c1(ctypes.Structure):
            _fields_=[('f1',ctypes.c_uint8)]
    class c2(ctypes.Structure):
            _fields_=[('g1',c1*2)]

while True:
    test=hi()
    test2=gc.collect()
----

It is also true if "del" is called on the return value of the function.

In order to get the memory leak, it appears to be necessary to have two Structure classes, with one of them containing a "multiple" of the other one as a field.

In a code project where functions returning Structure classes similarly to this example are being used, MemoryError has been encountered.

See: http://stackoverflow.com/users/553702/user553702

----------
components: ctypes
messages: 144170
nosy: a01
priority: normal
severity: normal
status: open
title: Memory leak with CTypes Structure
type: resource usage

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 09:17:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 07:17:25 +0000
Subject: [New-bugs-announce] [issue12999] _XOPEN_SOURCE usage on Solaris
Message-ID: <1316243845.31.0.573111003636.issue12999@psf.upfronthosting.co.za>

Changes by Charles-Fran?ois Natali :

----------
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: _XOPEN_SOURCE usage on Solaris
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 14:06:15 2011
From: report at bugs.python.org (jorge.seifert)
Date: Sat, 17 Sep 2011 12:06:15 +0000
Subject: [New-bugs-announce] [issue13000] unhandled exception at  install
Message-ID: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>

New submission from jorge.seifert :

Unhandled exception just at when start to install on windows 2003

----------
components: Installation
messages: 144182
nosy: jorge.seifert
priority: normal
severity: normal
status: open
title: unhandled exception at  install
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 16:34:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 14:34:31 +0000
Subject: [New-bugs-announce] [issue13001] test_socket.testRecvmsgTrunc
	failure on FreeBSD 7.2	buildbot
Message-ID: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>

New submission from Charles-Fran?ois Natali :

http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 3.x/builds/2129/steps/test/logs/stdio

"""
======================================================================
FAIL: testRecvmsgTrunc (test.test_socket.RecvmsgUDPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1666, in testRecvmsgTrunc
    self.checkFlags(flags, eor=False)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1354, in checkFlags
    self.assertEqual(flags & mask, checkset & mask)
AssertionError: 0 != 16

======================================================================
FAIL: testRecvmsgTrunc (test.test_socket.RecvmsgIntoUDPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1666, in testRecvmsgTrunc
    self.checkFlags(flags, eor=False)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1354, in checkFlags
    self.assertEqual(flags & mask, checkset & mask)
AssertionError: 0 != 16
"""

This fails because MSG_TRUNC isn't always set in msg_flags when receiving a truncated datagram with recvmsg().
It's a known kernel bug (http://svnweb.freebsd.org/base?view=revision&revision=211030), fixed in FreeBSD 8 (and the test indeed passes on the FreeBSD 8 buildbot).

The patch attached skips the test on FreeBSD < 8 (and introduces @support.requires_freebsd_version).

----------
components: Tests
files: freebsd_msgtrunc.diff
keywords: needs review, patch
messages: 144188
nosy: haypo, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: test_socket.testRecvmsgTrunc failure on FreeBSD 7.2 buildbot
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23182/freebsd_msgtrunc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 16:43:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Sep 2011 14:43:55 +0000
Subject: [New-bugs-announce] [issue13002] peephole.c: unused parameter
Message-ID: <1316270635.94.0.378241205596.issue13002@psf.upfronthosting.co.za>

New submission from Stefan Krah :

peephole.c: CONST_STACK_TOP(x) has an unused parameter.

----------
components: Interpreter Core
files: peephole_unused_parameter.diff
keywords: patch
messages: 144189
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: peephole.c: unused parameter
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23183/peephole_unused_parameter.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 06:55:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 18 Sep 2011 04:55:23 +0000
Subject: [New-bugs-announce] [issue13003] Bug in equivalent code for
	itertools.izip_longest
Message-ID: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>

New submission from Eli Bendersky :

Regarding the sample code in: http://docs.python.org/library/itertools#itertools.izip_longest

If an IndexError is raised inside an iterator in the "equivalent" code
from the docs, the generator stops and the error is swallowed.

If an IndexError is raised inside an iterator in the
"izip_longest_next" code in CPython's "Modules/itertoolsmodule.c", the
generator stops and the error propagates.

---

Reported by Adam Forsyth on the docs mailing list. More details in this SO discussion: http://stackoverflow.com/questions/7392902/izip-longest-in-itertools-how-does-rasing-indexerror-inside-the-iterator-work

----------
assignee: docs at python
components: Documentation
messages: 144228
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Bug in equivalent code for itertools.izip_longest
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 19:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 18 Sep 2011 17:41:13 +0000
Subject: [New-bugs-announce] [issue13004] pprint: add option to truncate
	seqeunces
Message-ID: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>

New submission from Terry J. Reedy :

>From python-ideas thread "truncate sequences in pretty-print ?"
On Sat, Sep 17, 2011 at 9:59 PM, Steven Samuel Cole
> i use pprint quite a bit during development to give me quick insight
> into what is going on inside my application.
> however, when there's any sequences involved, the output becomes less
> useful the longer these sequences are - i often find myself scrolling
> around (or even searching) in the terminal window, trying to find the
> bit of output i am interested in.
>
> imo, it would be great if pprint had a parameter 'max_len' or so that
> reduces output of every sequence to a maximum and inserts something
> like '...' to indicate truncation, e.g.
> {'my key': ['my list item 01',
>            'my list item 02',
>            'my list item 03',
>            'my list item 04',
>            'my list item 05',
>            'my list item 06',
>            'my list item 07',
>            'my list item 08',
>            '...',
>            'my list item 10',]}
>
> somewhat comparable to the '...' already printed when a structure is
> more deeply nested than you want to know right now.

On 9/18/2011 10:59 AM, Guido van Rossum wrote:
Agreed, this would be a useful feature. I've reimplemented something
like pprint a few times and always had to implement this truncation
feature. If you or someone can contribute a patch that would be much
appreciated!

----------
components: Library (Lib)
messages: 144247
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: pprint: add option to truncate seqeunces
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:24:54 2011
From: report at bugs.python.org (Luciano Ramalho)
Date: Sun, 18 Sep 2011 19:24:54 +0000
Subject: [New-bugs-announce] [issue13005] operator module docs include repeat
Message-ID: <1316373895.0.0.0510419466495.issue13005@psf.upfronthosting.co.za>

New submission from Luciano Ramalho :

The operator module documentation for versions 3.2 and 3.3 includes the repeat function in a table "9.3.1. Mapping Operators to Functions" [1], but fails to mention that the repeat function is deprecated and mul should be used instead, as described in the 2.7 version of the operator module docs [2].

The main entry for the repeat function was removed in the 3.2 and 3.3 docs, only the mention in the table remains [1].

[1] http://docs.python.org/py3k/library/operator#mapping-operators-to-functions
[2] http://docs.python.org/library/operator#operator.__repeat__

----------
assignee: docs at python
components: Documentation
messages: 144251
nosy: docs at python, luciano
priority: normal
severity: normal
status: open
title: operator module docs include repeat
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 06:32:46 2011
From: report at bugs.python.org (Stephen Vavasis)
Date: Mon, 19 Sep 2011 04:32:46 +0000
Subject: [New-bugs-announce] [issue13006] bug in core python variable binding
Message-ID: <1316406766.78.0.388912606851.issue13006@psf.upfronthosting.co.za>

New submission from Stephen Vavasis :

There seems to be a serious bug in how python 2.7.2 binds variables to values.  In the attached function buildfunclist, you see that there is a variable called 'funclist' that is initialized to [], and then is modified only with 'append' calls.  This means that once append is called 46 times, one expects that funclist[45] is defined and will not change?  And yet funclist[45] changes several times as more data items are appended.  The same bug is present in 3.2.2.  My operating system is Windows 7 64-bit on a Lenovo Thinkpad T410.  I'm guessing that there is a problem with python's lazy copying-- it is a bit too lazy and failing to make copies when lists are changed.

To exhibit this bug, proceed as follows:

import pickle
h = open('combined_oplists_pickle','r')
combined_oplists = pickle.Unpickler(h).load()
import pybugreport
funclist,funcdist = pybugreport.buildfunclist(combined_oplists)

and then you will see funclist[45] printed out on two successive iterations.  It has changed as a result of an append operation, which should not happen.  (It's 6th entry is longer.)

Here is the output:

funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['', 'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['', 'FaceIndex', ''], ['faceind', '']]]], ['InOutArg', [[['', 'ActiveBoxVectorI', ''], ['interiorOrbitNextLev', '']]]], ['RefGlobal', [[['', 'MIndex', ''], ['guiActiveBoxCount', '']]]], ['Workspace', [[['', 'QMGVector', '<', '', 'BoxCreationData', '', '> ', ''], ['boxCreationVec', '']]]]], [], [[0, 23017], [0, 23048], [0, 23068], [0, 23069]], [[0, 23001]]]
funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['', 'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['', 'FaceIndex', ''], ['faceind', '']]]], ['InOutArg', [[['', 'ActiveBoxVectorI', ''], ['interiorOrbitNextLev', '']]]], ['RefGlobal', [[['', 'MIndex', ''], ['guiActiveBoxCount', '']]]], ['Workspace', [[['', 'QMGVector', '<', '', 'BoxCreationData', '', '> ', ''], ['boxCreationVec', '']]]]], [[0, 23115], [0, 23116], [0, 23117], [0, 23118], [0, 23119], [0, 23120], [0, 23121], [0, 23122], [0, 23123], [0, 23124], [0, 23125], [0, 23126], [0, 23127], [0, 23128], [0, 23129], [0, 23130], [0, 23131], [0, 23132], [0, 23133], [0, 23134], [0, 23135], [0, 23136], [0, 23139], [0, 23140], [0, 23141], [0, 23142], [0, 23143], [0, 23144], [0, 23145], [0, 23146]], [[0, 23017], [0, 23048], [0, 23068], [0, 23069], [0, 23137], [0, 23138], [0, 23147], [0, 23148], [0, 23149], [0, 23161]], [[0, 23001]]]

----------
components: Interpreter Core
files: pybugreport.zip
messages: 144261
nosy: vavasis
priority: normal
severity: normal
status: open
title: bug in core python variable binding
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23190/pybugreport.zip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:18:09 2011
From: report at bugs.python.org (Marien Zwart)
Date: Mon, 19 Sep 2011 14:18:09 +0000
Subject: [New-bugs-announce] [issue13007] gdbm 1.9 has new magic that
	whichdb does not recognize
Message-ID: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>

New submission from Marien Zwart :

dbm.whichdb (python 3) and whichdb.whichdb (python 2) only check for "magic == 0x13579ace" to recognize gdbm databases. The recently released gdbm 1.9 series adds 0x13579acd (for "32bit") and 0x13579acf (for "64bit") magics (see src/gdbmconst.h in the gdbm-1.9 or gdbm-1.9.1 source tree). Python's gdbm linked to gdbm 1.9 creates databases with the new magic, which causes the whichdb tests to fail. To reproduce this just build python against the new libgdbm and run test/test_dbm.py.

whichdb should probably just check for the two new magic numbers too. This will cause it to recognize the new gdbm databases even if python's gdbm extension is linked to an older version of gdbm that cannot open them, but that is probably less likely to cause problems than the current behavior, where a database created by python's gdbm is not recognized as such.

(I've left the "Versions" field untouched as I do not know which versions of python this should be backported to, but it affects all of them.)

----------
components: Library (Lib)
messages: 144277
nosy: marienz
priority: normal
severity: normal
status: open
title: gdbm 1.9 has new magic that whichdb does not recognize
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:21:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 19 Sep 2011 14:21:24 +0000
Subject: [New-bugs-announce] [issue13008] syntax error when pasting valid
	snippet into console	without empty string after the function def
Message-ID: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>

New submission from anatoly techtonik :

This is self-explanative. Function definitions are identical. Syntax error caused by the absence of empty line after the function definition.

Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18) 
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os

>>> def get_size(start_path = '.'):
...     total_size = 0
...     for dirpath, dirnames, filenames in os.walk(start_path):
...         for f in filenames:
...             fp = os.path.join(dirpath, f)
...             total_size += os.path.getsize(fp)
...     return total_size
... 
>>> print get_size()
1595969238
>>> def get_size(start_path = '.'):
...     total_size = 0
...     for dirpath, dirnames, filenames in os.walk(start_path):
...         for f in filenames:
...             fp = os.path.join(dirpath, f)
...             total_size += os.path.getsize(fp)
...     return total_size
... print get_size()
  File "", line 8
    print get_size()
        ^
SyntaxError: invalid syntax

----------
messages: 144278
nosy: techtonik
priority: normal
severity: normal
status: open
title: syntax error when pasting valid snippet into console without empty string after the function def
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:08:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:08:13 +0000
Subject: [New-bugs-announce] [issue13009] Remove documentation in distutils2
	repo
Message-ID: <1316444893.0.0.327846688186.issue13009@psf.upfronthosting.co.za>

New submission from ?ric Araujo :

The docs for packaging now live at docs.python.org.  Maintaining separate documentation for the distutils2 backport would take much time for little benefit.  Tarek agreed that we could just delete them, so I will remove them, add a file to mention their new location and update the PyPI and packages.python.org pages.  I?m opening this report to let people know, I don?t need a patch.

----------
assignee: eric.araujo
components: Distutils2
messages: 144285
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Remove documentation in distutils2 repo
versions: 3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:38:18 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Mon, 19 Sep 2011 16:38:18 +0000
Subject: [New-bugs-announce] [issue13010] devguide doc: ./python.exe on OS X
Message-ID: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>

New submission from Steven Samuel Cole :

it says in the last paragraph of the chapter at http://docs.python.org/devguide/setup.html#unix:

[...] ./python.exe on OS X [...]

.exe seems to indicate that should probably be './python.exe on Windows'

----------
assignee: docs at python
components: Documentation
messages: 144298
nosy: docs at python, ssc
priority: normal
severity: normal
status: open
title: devguide doc: ./python.exe on OS X

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 03:44:51 2011
From: report at bugs.python.org (Malcolm Purvis)
Date: Tue, 20 Sep 2011 01:44:51 +0000
Subject: [New-bugs-announce] [issue13011] Frozen programs require the
	original build directory in	order to run.
Message-ID: <1316483091.36.0.96391936283.issue13011@psf.upfronthosting.co.za>

New submission from Malcolm Purvis :

In Python 2.7.2, Linux executables built with freeze.py will only run on the machine that contains the original build directory.  This defeats the purpose of having frozen programs.  This problem did not exist in Python 2.5.

The following steps reproduce the problem:

1) Build a copy of python:

$ tar -xf Python-2.7.2.tar.bz2
$ cd Python-2.7.2
$ ./configure --prefix=`pwd`/install
$ make
$ make install

2) In another directory, build a frozen program:

$ echo 'print "Hello World"' >hello.py
$ ~/src/Python-2.7.2/python ~/src/Python-2.7.2/Tools/freeze/freeze.py hello.py
$ make
$  ./hello 
Hello World

Copy the binary to another machine:

$ $ ./hello 
Traceback (most recent call last):
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 563, in 
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 545, in main
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 278, in addusersitepackages
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 253, in getusersitepackages
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 243, in getuserbase
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 520, in get_config_var
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 419, in get_config_vars
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 287, in _init_posix
IOError: invalid Python installation: unable to open /home/malcolmp/src/Python-2.7.2/install/lib/python2.7/config/Makefile (No such file or directory)

----------
components: Demos and Tools
messages: 144315
nosy: malcolmp
priority: normal
severity: normal
status: open
title: Frozen programs require the original build directory in order to run.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:44:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 13:44:07 +0000
Subject: [New-bugs-announce] [issue13012] Allow keyword argument in
	str.splitlines()
Message-ID: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>

New submission from Mark Dickinson :

The docstring of str.splitlines says:

splitlines(...)
    S.splitlines([keepends]) -> list of strings

    Return a list of the lines in S, breaking at line boundaries.
    Line breaks are not included in the resulting list unless keepends
    is given and true.

Currently the optional argument can only be specified positionally.  What do people think about also allowing this argument to be specified by keyword?  (And applying the same change to bytes.splitlines.)

The main motivation here is readability:  in

   long_string.splitlines(keepends=True)

it's fairly clear what the boolean argument is doing.  But in

   long_string.splitlines(True)

it's much less clear.  (This came up during a Python training class that I was running recently.)  I'm not advocating making the argument keyword-only;  just allowing those who want to specify it by keyword to do so.

There are many other str methods that don't accept keyword arguments, but it's only this one where I think readability would really benefit.

----------
components: Interpreter Core
messages: 144326
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow keyword argument in str.splitlines()
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:48:11 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:48:11 +0000
Subject: [New-bugs-announce] [issue13013] Resource is not released before
	returning from the	functiion
Message-ID: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>