From report at bugs.python.org  Sat Sep  1 00:27:20 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Aug 2012 22:27:20 +0000
Subject: [New-bugs-announce] [issue15834] 2to3 benchmark not working under
	Python 3
Message-ID: <1346452040.3.0.632075344934.issue15834@psf.upfronthosting.co.za>


New submission from Brett Cannon:

2to3 isn't (ironically) translating lib2to3 so that it can run under Python 3:

File "/Users/bcannon/Developer/repo/benchmarks_py3k/lib/2to3/lib2to3/fixes/fix_operator.py", line 89, in _check_method
    method = getattr(self, "_" + results["method"][0].value.encode("ascii"))

Might need to let Python 3 use its stdlib copy of lib2to3. Otherwise will need to come up with a way to have two copies of a library, one for Python 2 and another for Python 3, and then copy the right thing. Maybe a lib3 directory that is only copied over by make_perf3.sh?

----------
assignee: collinwinter
components: Benchmarks
messages: 169587
nosy: brett.cannon, collinwinter, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: 2to3 benchmark not working under Python 3

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

From report at bugs.python.org  Sat Sep  1 01:52:33 2012
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 31 Aug 2012 23:52:33 +0000
Subject: [New-bugs-announce] [issue15835] HP-UX build needs to be tweaked to
	pick up PATH_MAX
Message-ID: <1346457153.04.0.0294174797728.issue15835@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Building on HP-UX with the HP ANSI C compiler:


% make                                     
        cc -Ae -c  -O  -O  -I. -I./Include    -DPy_BUILD_CORE -o Python/pythonrun.o Python/pythonrun.c
"Python/pythonrun.c", line 805: error #2020: identifier "PATH_MAX" is undefined
  static wchar_t env_home[PATH_MAX+1];
                          ^

1 error detected in the compilation of "Python/pythonrun.c".
*** Error exit code 2

Stop.

Placeholder bug whilst I do some more digging.

----------
assignee: trent
messages: 169593
nosy: trent
priority: normal
severity: normal
status: open
title: HP-UX build needs to be tweaked to pick up PATH_MAX
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep  1 02:26:01 2012
From: report at bugs.python.org (Daniel Wagner-Hall)
Date: Sat, 01 Sep 2012 00:26:01 +0000
Subject: [New-bugs-announce] [issue15836] unittest assertRaises should
	verify excClass is actually	a BaseException class
Message-ID: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za>


New submission from Daniel Wagner-Hall:

The following code in a unittest test is a no-op:

self.assertRaises(lambda: 1)

I would expect this to fail the test, because I naively assumed omitting the exception class would act as:

self.assertRaises(BaseException, lambda: 1)

verifying that *any* Exception is raised.



I believe the correct behaviour is to raise a TypeError if excClass is not a BaseException-derived type, similar to if a non-type is passed as the first arg to issubclass.

Attached is a patch to do so.  It also removes a no-op self.assertRaises from libimport's tests (because it started failing when I ran the tests with the patch).  That assertion is redundant, because the two lines above perform the assertion being attempted.

----------
components: Tests
files: assertRaises.patch
keywords: patch
messages: 169596
nosy: illicitonion
priority: normal
severity: normal
status: open
title: unittest assertRaises should verify excClass is actually a BaseException class
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27079/assertRaises.patch

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

From report at bugs.python.org  Sat Sep  1 04:06:19 2012
From: report at bugs.python.org (Alessandro Moura)
Date: Sat, 01 Sep 2012 02:06:19 +0000
Subject: [New-bugs-announce] [issue15837] Added test to test_random.py
	testing Random.shuffle
Message-ID: <1346465179.1.0.118516816378.issue15837@psf.upfronthosting.co.za>


New submission from Alessandro Moura:

Random.shuffle does not have a test in test_random.py; the attached patch adds this test. In addition, I rewrote the documentation string for Random.shuffle, which apparently did not reflect recent changes in the code and was inconsistent with the definition of the method. This change is also part of this patch; I was not sure if this merited a separate issue, so I just included this here.

On a related matter: in Random.shuffle there is a third optional argument which looks very odd to me:

def shuffle(self, x, random=None, int=int):
....

Besides being confusing to a user typing help(shuffle), what the "int" argument does in shuffle is to convert a float to an integer. But one could pass any one-argument function in principle, and it would be then very hard to predict what shuffle would do... it would not "shuffle" any more in the traditional sense - not with a uniform probability distribution. In summary, I don't see how that argument could be useful, although the people who wrote the library must have had something in mind... if so it would be a good idea to document it.

----------
components: Tests
messages: 169603
nosy: eng793
priority: normal
severity: normal
status: open
title: Added test to test_random.py testing Random.shuffle
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep  1 13:26:44 2012
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Sep 2012 11:26:44 +0000
Subject: [New-bugs-announce] [issue15838] make install tries to create
	lib2to3 grammar pickles in	source directory
Message-ID: <1346498804.77.0.811767404939.issue15838@psf.upfronthosting.co.za>


New submission from Ned Deily:

With the recent activity around making out-of-tree builds work, while investigating Issue15822 I realized that the lib2to3 grammar pickle files are being built in the source directory by the libinstall target step of the main Makefile rather than in the build directory or just in the install location.  The fixes for Issue15645 moved the pickle building to the start of the target recipes:

libinstall:	build_all $(srcdir)/Lib/$(PLATDIR) $(srcdir)/Modules/xxmodule.c
	-PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \
		$(PYTHON_FOR_BUILD) -Wi -c "import lib2to3.pygram, lib2to3.patcomp;lib2to3.patcomp.PatternCompiler()"


On reflection, I think the PYTHONPATH definition is bogus here since LIBDEST is populated immediately after this step. More importantly, lib2to3/pgen2/driver:load_grammar ends up writing the pickle files into the source directory.  Unlike some other cases in the Makefile, if the source directory is read-only, the failure to create the pickle files is not an error during installation but it may likely cause problems for later users of the installed lib2to3 (like in the Issue15822 scenario), i.e. when the missing pickles are attempted to be created in the read-only install directories.

----------
components: 2to3 (2.x to 3.x conversion tool), Build, Installation
messages: 169623
nosy: benjamin.peterson, ned.deily, ronaldoussoren, trent
priority: normal
severity: normal
stage: needs patch
status: open
title: make install tries to create lib2to3 grammar pickles in source directory
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Sep  1 16:09:01 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 01 Sep 2012 14:09:01 +0000
Subject: [New-bugs-announce] [issue15839] SystemError raised by super()
	should be NameError or	RuntimeError
Message-ID: <1346508541.04.0.853072474076.issue15839@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Running the erronous code:

class X:
    super_object = super()

fails with a SystemError("super(): __class__ cell not found")
The exception should be a NameError or SystemError.

----------
components: None
messages: 169634
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: SystemError raised by super() should be NameError or RuntimeError
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep  1 20:33:44 2012
From: report at bugs.python.org (Alexander Konovalenko)
Date: Sat, 01 Sep 2012 18:33:44 +0000
Subject: [New-bugs-announce] [issue15840] Ambiguity with regard to the
	effect of accessing a	closed IOBase instance
Message-ID: <1346524424.76.0.407141547435.issue15840@psf.upfronthosting.co.za>


New submission from Alexander Konovalenko:

Two pieces of the documentation for io.IOBase seem to contradict each other:

At http://docs.python.org/library/io.html#io.IOBase:
"Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case."

At http://docs.python.org/library/io.html#io.IOBase.close:
"Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError."

Perhaps the confusion arises in part because it is not clear when a requirement for all IOBase implementations is documented and when the docs merely describe the default behavior of IOBase that implementations are free to override.

Those passages are inconsistent on two points:

1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise?

2) Undefined behavior means literally anything can happen. Technically, that means calling read() or readable() on a closed file (or other kind of stream) could wreak havoc in a totally unrelated part of the system or segfault the Python interpreter. That is definitely a thing to carefully avoid in any production systems.

On the other hand, raising an exception, even if we don't know in advance whether it will be ValueError or IOError, is pretty much defined behavior. An exception is easy to deal with and to contain inside a module.

So please clarify how dangerous it actually is to access an IOBase stream after it has been closed.

----------
assignee: docs at python
components: Documentation
messages: 169660
nosy: alexkon, docs at python
priority: normal
severity: normal
status: open
title: Ambiguity with regard to the effect of accessing a closed IOBase instance
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep  1 21:18:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Sep 2012 19:18:52 +0000
Subject: [New-bugs-announce] [issue15841] Some StringIO and BytesIO methods
	can succeed after close
Message-ID: <1346527132.85.0.102313792516.issue15841@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> f = io.StringIO()
>>> f.close()
>>> f.readable()
True
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file.

>>> f = io.BytesIO()
>>> f.close()
>>> f.readable()
True
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file

----------
components: IO, Library (Lib)
messages: 169665
nosy: pitrou
priority: normal
severity: normal
status: open
title: Some StringIO and BytesIO methods can succeed after close
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep  1 21:20:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Sep 2012 19:20:13 +0000
Subject: [New-bugs-announce] [issue15842] Some SocketIO methods can succeed
	after close()
Message-ID: <1346527213.21.0.243179396441.issue15842@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> import socket
>>> s = socket.socket()
>>> f = s.makefile("rb", buffering=0)
>>> f
<socket.SocketIO object at 0x7f2f323cd790>
>>> f.close()
>>> f.writable()
False
>>> f.readable()
False

----------
components: IO, Library (Lib)
messages: 169666
nosy: benjamin.peterson, hynek, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Some SocketIO methods can succeed after close()
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Sep  2 00:33:43 2012
From: report at bugs.python.org (Alastair Porter)
Date: Sat, 01 Sep 2012 22:33:43 +0000
Subject: [New-bugs-announce] [issue15843] aifc.open expects only str or file
	pointer
Message-ID: <1346538823.6.0.158703748918.issue15843@psf.upfronthosting.co.za>


New submission from Alastair Porter:

Passing a unicode filename to aifc.open() results in the argument being treated like a filepointer instead of opening the file.

The argument check,
http://hg.python.org/cpython/file/default/Lib/aifc.py#l332
only checks if the argument is a str. Should this be extended to accept all string-type objects?

Example usage:
>>> import aifc
>>> aifc.open(u"/some/path")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 924, in open
    return Aifc_read(f)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 335, in __init__
    self.initfp(f)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/aifc.py", line 286, in initfp
    chunk = Chunk(file)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/chunk.py", line 61, in __init__
    self.chunkname = file.read(4)
AttributeError: 'unicode' object has no attribute 'read'

----------
components: None
messages: 169673
nosy: alastairp
priority: normal
severity: normal
status: open
title: aifc.open expects only str or file pointer
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep  2 02:53:25 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sun, 02 Sep 2012 00:53:25 +0000
Subject: [New-bugs-announce] [issue15844] weird import errors
Message-ID: <1346547205.78.0.590339633235.issue15844@psf.upfronthosting.co.za>


New submission from Daniel Swanson:

I'm dealing with a bunch of nested folders and my imports have gone crazy. When I try to test one of the lower level scripts that imports one of the higher level one it gives me an error message. But, when I run the top one, (which cascadingly imports just about everything) it doesn't. And now I've got one trying to import something on the same level and it says it doesn't exist!
This happens whenever I try to use folders, because of this, I only have one file of programs.

----------
components: None
messages: 169680
nosy: weirdink13
priority: normal
severity: normal
status: open
title: weird import errors
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep  2 04:19:56 2012
From: report at bugs.python.org (Alessandro Moura)
Date: Sun, 02 Sep 2012 02:19:56 +0000
Subject: [New-bugs-announce] [issue15845] Fixing some byte-to-string
	conversion warnings
Message-ID: <1346552396.88.0.397419581961.issue15845@psf.upfronthosting.co.za>


New submission from Alessandro Moura:

This is related to issue 15826.

When run with the -b option, some glob.py and os.py functions give warnings due to byte-to-string conversions:


amoura at amoura-laptop:~/cpython$ ./python -b -c "import glob; glob.glob(b'cover*/glob.cover')"
/home/amoura/cpython/Lib/glob.py:64: BytesWarning: Comparison between bytes and string
  if basename == '':
amoura at amoura-laptop:~/cpython$ ./python -b -c "import os; os.makedirs(b'tst/making/dirs')"
/home/amoura/cpython/Lib/os.py:266: BytesWarning: Comparison between bytes and string
  if tail == cdir:           # xxx/newdir/. exists if xxx/newdir exists

The attached patch fixes this.

There is a rather more mysterious phenomenon with exceptions (which is triggered by test_exceptions for ImportException, but it happens for any Exception class):

>>> e = Exception(b'aaa')
[60596 refs]
>>> e.args[0]
b'aaa'
[60601 refs]
>>> str(e)
__main__:1: BytesWarning: str() on a bytes instance
"b'aaa'"
[60615 refs]
>>> e.args[0]
b'aaa'
[60615 refs]
>>> str(e)
"b'aaa'"
[60615 refs]
>>> e.args[0]
b'aaa'
[60615 refs]

In other words, if a bytes argument is given to the exception, the first call to str triggers the warning, but further calls don't. Is this worth pursuing?

----------
components: Library (Lib)
files: os_glob_bytes.patch
keywords: patch
messages: 169683
nosy: eng793
priority: normal
severity: normal
status: open
title: Fixing some byte-to-string conversion warnings
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file27092/os_glob_bytes.patch

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

From report at bugs.python.org  Sun Sep  2 10:46:06 2012
From: report at bugs.python.org (David Halter)
Date: Sun, 02 Sep 2012 08:46:06 +0000
Subject: [New-bugs-announce] [issue15846] literal_eval raises SystemError
	instead of SyntaxError, because of illegal escape sequence
Message-ID: <1346575566.52.0.640732929243.issue15846@psf.upfronthosting.co.za>


New submission from David Halter:

Hi! I'm the developer of Jedi: https://github.com/davidhalter/jedi, which is an auto-completion library. I try to support Python 2.5-3.2.
The bug just appears in Python 3.2.

Parsing string literals with literal_eval works normally without a problem, but in this certain constellation, it raises a SystemError (instead of a SyntaxError).

The error line is simple:
literal_eval(r"'\U'")

But: It only raises the error in that particular place:
https://github.com/davidhalter/jedi/blob/master/parsing.py#L157

To try and test it:

git clone git://github.com/davidhalter/jedi.git
cd jedi
# uncomment the line after TODO in parsing.Scope.add_docstr
python3 test/run.py array

The error message:

Traceback (most recent call last):
  File "./run.py", line 51, in run_definition_test
    result = defs(line_nr, len(line))
  File "./run.py", line 49, in defs
    return set(functions.get_definitions(source, line_nr, indent, path))
  File "./functions.py", line 253, in get_definitions
    scopes = _prepare_goto(source, pos, source_path, f, goto_path)
  File "./functions.py", line 227, in _prepare_goto
    scopes = evaluate.follow_statement(stmt)
  File "./helpers.py", line 23, in __call__
    if self.push_stmt(stmt):
  File "./helpers.py", line 31, in push_stmt
    self.current = RecursionNode(stmt, self.current)
  File "./helpers.py", line 75, in __init__
    or (self.script == builtin.Builtin.scope)
  File "./builtin.py", line 408, in scope
    return self._builtins.parser.module
  File "./builtin.py", line 42, in parser
    self._load_module()
  File "./builtin.py", line 50, in _load_module
    self._parser = parsing.PyFuzzyParser(source, self.path or self.name)
  File "./parsing.py", line 1047, in __init__
    self.parse()
  File "./parsing.py", line 1600, in parse
    stmt, tok = self._parse_statement(self.current)
  File "./parsing.py", line 1386, in _parse_statement
    self.scope.add_docstr(self.last_token[1])
  File "./parsing.py", line 157, in add_docstr
    literal_eval(r"'\U'")
  File "/usr/lib/python3.2/ast.py", line 48, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/usr/lib/python3.2/ast.py", line 36, in parse
    return compile(source, filename, mode, PyCF_ONLY_AST)
SystemError: ../Objects/tupleobject.c:126: bad argument to internal function

Cheers!
David

----------
messages: 169687
nosy: davidhalter
priority: normal
severity: normal
status: open
title: literal_eval raises SystemError instead of SyntaxError, because of illegal escape sequence
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep  2 15:12:15 2012
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sun, 02 Sep 2012 13:12:15 +0000
Subject: [New-bugs-announce] [issue15847] parse_args stopped accepting tuples
Message-ID: <1346591535.01.0.313863035332.issue15847@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

After recent change (78307 '#13922: argparse no longer incorrectly strips '--' after the first one.'), parse_args stopped working with a tuple
argument. It is easy to pass tuple to argparse by using positional function arguments:

def f(*args):
   parser.parse_args(args)

This will fail, because args is a tuple.

It is necessary to have at least one positional argument to trigger the bug.

----------
components: Library (Lib)
files: argparse_parse_args_tuple.diff
keywords: patch
messages: 169695
nosy: bethard, r.david.murray, zbysz
priority: normal
severity: normal
status: open
title: parse_args stopped accepting tuples
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27095/argparse_parse_args_tuple.diff

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

From report at bugs.python.org  Sun Sep  2 16:29:27 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 02 Sep 2012 14:29:27 +0000
Subject: [New-bugs-announce] [issue15848] PEP 3121,
	384 Refactoring applied to xxsubtype module
Message-ID: <1346596167.75.0.401355088857.issue15848@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the xxsubtype module!

----------
components: Extension Modules
files: xxsubtype_pep3121-384_v0.patch
keywords: patch
messages: 169701
nosy: Robin.Schreiber, belopolsky
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to xxsubtype module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file27097/xxsubtype_pep3121-384_v0.patch

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

From report at bugs.python.org  Sun Sep  2 16:32:33 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 02 Sep 2012 14:32:33 +0000
Subject: [New-bugs-announce] [issue15849] PEP 3121,
	384 Refactoring applied to xx module
Message-ID: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the xx module!

----------
components: Extension Modules
files: xxmodule_pep3121-384_v0.patch
keywords: patch
messages: 169702
nosy: Robin.Schreiber, belopolsky
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to xx module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file27098/xxmodule_pep3121-384_v0.patch

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

From report at bugs.python.org  Sun Sep  2 18:25:55 2012
From: report at bugs.python.org (Varun Masuraha)
Date: Sun, 02 Sep 2012 16:25:55 +0000
Subject: [New-bugs-announce] [issue15850] list.count() results wrong if both
	booleans & 1's/0's	are present in the list
Message-ID: <1346603155.58.0.703735136333.issue15850@psf.upfronthosting.co.za>


New submission from Varun Masuraha:

setup:
>>>myList=[1,True,'blah blah']
>>>print(myList.count(1))

Actual result:
2

Expected:
1

----------
messages: 169707
nosy: varun_masuraha
priority: normal
severity: normal
status: open
title: list.count() results wrong if both booleans & 1's/0's are present in the list
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep  2 20:36:04 2012
From: report at bugs.python.org (=?utf-8?q?Eduardo_A=2E_Bustamante_L=C3=B3pez?=)
Date: Sun, 02 Sep 2012 18:36:04 +0000
Subject: [New-bugs-announce] [issue15851] Lib/robotparser.py doesn't accept
	setting a user agent	string, instead it uses the default.
Message-ID: <1346610964.7.0.836759738208.issue15851@psf.upfronthosting.co.za>


New submission from Eduardo A. Bustamante L?pez:

I found that http://en.wikipedia.org/robots.txt returns 403 if the provided user agent is in a specific blacklist.

And since robotparser doesn't provide a mechanism to change the default user agent used by the opener, it becomes unusable for that site (and sites that have a similar policy).

I think the user should have the possibility to set a specific user agent string, to better identify their bot.

I attach a patch that allows the user to change the opener used by RobotFileParser, in case the need of some specific behavior arises.

I also attach a simple example of how it solves the issue, at least with wikipedia.

----------
components: Library (Lib)
files: robotparser.py.diff
keywords: patch
messages: 169718
nosy: Eduardo.A..Bustamante.L?pez
priority: normal
severity: normal
status: open
title: Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27100/robotparser.py.diff

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

From report at bugs.python.org  Sun Sep  2 23:41:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 02 Sep 2012 21:41:42 +0000
Subject: [New-bugs-announce] [issue15852] typos in curses argument error
	messages
Message-ID: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

It seems like a couple error messages in the curses module need correcting:

PyErr_SetString(PyExc_TypeError, "insch requires 1 or 4 arguments");

http://hg.python.org/cpython/file/8ff2f4634ed8/Modules/_cursesmodule.c#l1322

PyErr_SetString(PyExc_TypeError, "instr requires 0 or 3 arguments");

http://hg.python.org/cpython/file/8ff2f4634ed8/Modules/_cursesmodule.c#l1385

In both cases, "or" should be "to".

----------
components: Library (Lib)
keywords: easy
messages: 169725
nosy: cjerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: typos in curses argument error messages
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep  3 02:27:22 2012
From: report at bugs.python.org (David Pietz)
Date: Mon, 03 Sep 2012 00:27:22 +0000
Subject: [New-bugs-announce] [issue15853] Idle "quit unexpectedly" w/
	attempted edit of preferences
Message-ID: <1346632042.85.0.745944196118.issue15853@psf.upfronthosting.co.za>


New submission from David Pietz:

Currently I am trying to edit idle preferences so I can edit a script which appends a log of Idle activity that I may review for study purposes.
I could not really interpret much of the crash logs in console but there seem to be two types of memory errors. I have also seen a variety of situations crash Idle and it is hampering my study as my text uses 3.x not the installed 2.x on my Macbook Pro.  As I saw an issue track mentioning os x 10.6, I upgraded to Mountain Lion, os x 10.8 but the behavior is the same. This is my first post.

----------
messages: 169732
nosy: David.Pietz
priority: normal
severity: normal
status: open
title: Idle "quit unexpectedly" w/ attempted edit of preferences
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep  3 02:39:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 03 Sep 2012 00:39:54 +0000
Subject: [New-bugs-announce] [issue15854] curses test_curses test_unget_wch
Message-ID: <1346632794.75.0.136590838621.issue15854@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As of: changeset:   78843:8ff2f4634ed8
date:        Sun Sep 02 16:37:09 2012 -0400

I am getting this failure:

$ ./python.exe -m test -v -u curses test_curses
== CPython 3.3.0rc1+ (default:8ff2f4634ed8, Sep 2 2012, 16:02:43) [GCC 4.2.1 Compatible Apple Clang 3.1 (tags/Apple/clang-318.0.58)]
==   Darwin-11.4.0-x86_64-i386-64bit little-endian
==   .../build/test_python_17427
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, hash_randomization=1)
[1/1] test_curses
test test_curses crashed -- Traceback (most recent call last):
  File ".../Lib/test/regrtest.py", line 1221, in runtest_inner
    test_runner()
  File ".../Lib/test/test_curses.py", line 336, in test_main
    main(stdscr)
  File ".../Lib/test/test_curses.py", line 322, in main
    test_unget_wch(stdscr)
  File ".../Lib/test/test_curses.py", line 283, in test_unget_wch
    raise AssertionError("%r != %r" % (read, ch))
AssertionError: -61 != '?'

Looks like this may be related to issue 15785.

----------
components: Library (Lib)
messages: 169734
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: curses test_curses test_unget_wch
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep  3 15:25:50 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Sep 2012 13:25:50 +0000
Subject: [New-bugs-announce] [issue15855] memoryview methods are missing
	docstrings
Message-ID: <1346678750.91.0.0208236939901.issue15855@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

With attached patch python -mpydoc memoryview display looks as follows:

...
 |  cast(...)
 |      M.cast(format[, shape]) -> memoryview
 |      
 |      Cast a memoryview to a new format or shape.
 |  
 |  release(...)
 |      M.release() -> None
 |      
 |      Release the underlying buffer exposed by the memoryview object.
 |  
 |  tobytes(...)
 |      M.tobytes() -> bytes
 |      
 |      Return the data in the buffer as a bytestring.
 |  
 |  tolist(...)
 |      M.tobytes() -> list
 |      
 |      Return the data in the buffer as a list of elements.

----------
files: memoryobject-docstrings.diff
keywords: patch
messages: 169762
nosy: belopolsky, skrah
priority: normal
severity: normal
status: open
title: memoryview methods are missing docstrings
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file27109/memoryobject-docstrings.diff

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

From report at bugs.python.org  Mon Sep  3 17:13:44 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 03 Sep 2012 15:13:44 +0000
Subject: [New-bugs-announce] [issue15856] inspect.getsource(SomeClass)
	doesn't show @decorators
Message-ID: <1346685224.9.0.738134714561.issue15856@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

Since bug #1006219 was fixed, inspect.getsource(func) has returned the source of a function including any decorators on the function. But doing the same with a class, the returned source doesn't include decorators.

With functions, the co_firstlineno attribute of the code object points to the start of the decorators. With classes, that's not possible, so it's likely that a bit more regex trickery will be needed to scan back to decorators.

I've confirmed the same thing happens in 3.2 and 2.7, and looking at the code of inspect.py in trunk, it looks like it will do the same thing.

----------
components: Library (Lib)
messages: 169767
nosy: takluyver
priority: normal
severity: normal
status: open
title: inspect.getsource(SomeClass) doesn't show @decorators
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep  3 18:24:57 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 03 Sep 2012 16:24:57 +0000
Subject: [New-bugs-announce] [issue15857] memoryview of a ctypes struct has
	incompatible invalid	format
Message-ID: <1346689497.87.0.0543181973017.issue15857@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Starting with the example in memoryview documentation:

>>> from ctypes import BigEndianStructure, c_long
>>> class BEPoint(BigEndianStructure):
...     _fields_ = [("x", c_long), ("y", c_long)]
...
>>> point = BEPoint(100, 200)
>>> a = memoryview(point)

I am trying to unpack the resulting view:

>>> a.tolist()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format T{>l:x:>l:y:}

>>> struct.unpack_from(a.format,a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: bad char in struct format

>>> struct.unpack_from('>ll',a)
(0, 100)


It looks like there is one or more bugs in play here.

----------
messages: 169771
nosy: belopolsky, skrah
priority: normal
severity: normal
status: open
title: memoryview of a ctypes struct has incompatible invalid format
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep  3 21:47:40 2012
From: report at bugs.python.org (Tom Lynn)
Date: Mon, 03 Sep 2012 19:47:40 +0000
Subject: [New-bugs-announce] [issue15858] tarfile missing entries due to
	omitted uid/gid fields
Message-ID: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za>


New submission from Tom Lynn:

The tarfile module silently truncates the list of entries when reading a tar file if it sees an entry with a uid/gid field containing only spaces/NULs.  I got such a tarball from Java Maven/plexus-archiver.  I don't know whether they write such fields deliberately, but it seems reasonable to me, especially since they were providing the user/group names textually.

I'd like to see two fixes - a None/-1/0 value for the uid/gid and not silently swallowing HeaderErrors in TarFile.next() (or at least documenting why it's being done).  0 would be consistent with the default value when writing, but None seems more honest.  -1 seems hard to defend.

Only tested on silly Python versions (2.6, PyPy-1.8), sorry.  It's what I've got to hand, but I think this issue also applies to recent Python too going by looking at the hg trunk.

----------
components: Library (Lib)
messages: 169799
nosy: tlynn
priority: normal
severity: normal
status: open
title: tarfile missing entries due to omitted uid/gid fields
type: behavior
versions: 3rd party, Python 2.6

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

From report at bugs.python.org  Tue Sep  4 07:24:43 2012
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 04 Sep 2012 05:24:43 +0000
Subject: [New-bugs-announce] [issue15859] PyUnicode_EncodeFSDefault win32
	inconsistancy.
Message-ID: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za>


New submission from Campbell Barton:

There is an inconsistency in PyUnicode_EncodeFSDefault(), on Linux its argument is checked to be unicode, and NULL is returned when its not. On windows however, this throws an assertion.

The problem with this is, in some CAPI code you may pass an argument and check for NULL as an error case, and allow the python API's exception to be exposed to the script author.

The problem here is a linux developer can use PyUnicode_EncodeFSDefault() this way, but not a windows developer.

A simplified use case below of a case where PyUnicode_EncodeFSDefault would fail.

Attached a fix so windows and posix systems behave the same.

---
const char *PyC_UnicodeAsByte(PyObject *py_str, PyObject **coerce)
{
	if (PyBytes_Check(py_str)) {
		return PyBytes_AS_STRING(py_str);
	}
	else if ((*coerce = PyUnicode_EncodeFSDefault(py_str))) {
		return PyBytes_AS_STRING(*coerce);
	}
---

Also: heres a list to the bug report in blenders tracker, where the bug was found.

https://projects.blender.org/tracker/index.php?func=detail&aid=31856&group_id=9&atid=498

----------
files: fix_unicode.diff
keywords: patch
messages: 169816
nosy: ideasman42
priority: normal
severity: normal
status: open
title: PyUnicode_EncodeFSDefault win32 inconsistancy.
Added file: http://bugs.python.org/file27114/fix_unicode.diff

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

From report at bugs.python.org  Tue Sep  4 15:07:00 2012
From: report at bugs.python.org (Julian Berman)
Date: Tue, 04 Sep 2012 13:07:00 +0000
Subject: [New-bugs-announce] [issue15860] Use TestCase assertion methods in
	unittest.mock.assert*	to make them easier to read
Message-ID: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za>


New submission from Julian Berman:

Mock's assertion failures can be extremely hard to read for a few reasons -- mostly the noisy default repr that mock objects have, but also because they don't give you the hints that `unittest.TestCase`'s `assert*` methods give you (things like diffing two lists for example).

unittest.mock.Mock's `assert*` methods could hook into the TestCase's assertion methods if Mock either gained a MockInTestCase subclass or started taking an arg to `__init__` that was an instance of `TestCase`, so that `assert*` could then use the assertion methods on the instance.

#11664 could (should) then obviously use this argument by default when patching.

Another added advantage would be that the raised exception could then be `TestCase.failureException`, whatever that might be, rather than `AssertionError`, though I doubt that's that big a deal since that's usually a subclass of `AssertionError` I bet.

----------
components: Library (Lib)
messages: 169826
nosy: Julian, michael.foord
priority: normal
severity: normal
status: open
title: Use TestCase assertion methods in unittest.mock.assert* to make them easier to read
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep  4 23:41:43 2012
From: report at bugs.python.org (Bryan Oakley)
Date: Tue, 04 Sep 2012 21:41:43 +0000
Subject: [New-bugs-announce] [issue15861] ttk.Treeview "unmatched open brace
	in list"
Message-ID: <1346794903.35.0.326071924778.issue15861@psf.upfronthosting.co.za>


New submission from Bryan Oakley:

If you try to insert an item into the treeview, give it a tuple of values for the "values" attribute, and one of those values has unbalanced braces, you'll get an error "unmatched open brace in list"

To reproduce:

import Tkinter as tk
import ttk

root = tk.Tk()
tree = ttk.Treeview(root)
tree.insert("","end",values=("one","two","bam! {"))

root.mainloop()

----------
components: Tkinter
messages: 169839
nosy: Bryan.Oakley
priority: normal
severity: normal
status: open
title: ttk.Treeview "unmatched open brace in list"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  4 23:43:34 2012
From: report at bugs.python.org (Cemal Duman)
Date: Tue, 04 Sep 2012 21:43:34 +0000
Subject: [New-bugs-announce] [issue15862] IDLE not working when due to wrong
	Hard Drive point of	os.path.expanduser
Message-ID: <1346795014.76.0.789021764596.issue15862@psf.upfronthosting.co.za>


New submission from Cemal Duman:

Hi 
Unfortunately i'm using Vista on my corparate laptop I can open my Python CLI without any problem but IDLE is not responding. When i started idle.py by issuing following command:

C:\Python27>python.exe Lib\idlelib\idle.py

I see following output:

C:\Python27>
 Warning: os.path.expanduser("~") points to
 H:\,
 but the path does not exist.

H:\ is my network drive. When i run the os.path.expanduser("~") at CLI i get following directory.

'C:\\Users\\edumcem\'

Thanks / Cemal

----------
components: IDLE
messages: 169840
nosy: Cemal.Duman
priority: normal
severity: normal
status: open
title: IDLE not working when due to wrong Hard Drive point of os.path.expanduser
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  5 00:44:19 2012
From: report at bugs.python.org (Alexander Konovalenko)
Date: Tue, 04 Sep 2012 22:44:19 +0000
Subject: [New-bugs-announce] [issue15863] Fine-grained info about Python
	versions which support	changes introduced in micro releases
Message-ID: <1346798659.62.0.336544157965.issue15863@psf.upfronthosting.co.za>


New submission from Alexander Konovalenko:

Some security fixes and bug fixes that are simultaneously issued for multiple Python versions require changes to the documentation. I'm now looking at the hash randomization vulnerability that was fixed in 2.6.8 and 2.7.3.

The docs always mention the release in which a new feature was added. That's great. But for a security fix such as the bug in question, the set of versions which support it doesn't look like "2.x.y or later". 

The documentation for the -R command-line option and the PYTHONHASHSEED environment variable says "New in version 2.6.8". A reader who is not familiar with the context would infer that those feature are supported in Python 2.7 through 2.7.2, which is not the case. The docs should say "New in version 2.6.8 and 2.7.3".
http://docs.python.org/using/cmdline.html#cmdoption-R
http://docs.python.org/using/cmdline.html#envvar-PYTHONHASHSEED

The documentation for the sys.flags.hash_randomization attribute says "New in version 2.7.3". Again, that leaves out the version 2.6.8 and future versions in the 2.6.x branch, which presumably support the new attribute. The docs should say "New in version 2.6.8 and 2.7.3".
http://docs.python.org/library/sys.html#sys.flags

Disclaimer: I did not test the relevant micro releases to see whether they actually support those features. Just checked the release dates and applied common sense.

If you know of any other micro release bugfixes that were mentioned in the docs, the same considerations apply to them. Please verify the docs are correct, fix them or file appropriate bugs.

----------
assignee: docs at python
components: Documentation
messages: 169841
nosy: alexkon, docs at python
priority: normal
severity: normal
status: open
title: Fine-grained info about Python versions which support changes introduced in micro releases
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Sep  5 00:59:35 2012
From: report at bugs.python.org (Daniel Wagner-Hall)
Date: Tue, 04 Sep 2012 22:59:35 +0000
Subject: [New-bugs-announce] [issue15864] Package cache doesn't cache
	packages with overlapping	sys.path entries
Message-ID: <1346799575.05.0.866449286676.issue15864@psf.upfronthosting.co.za>


New submission from Daniel Wagner-Hall:

Importing the same module twice should only execute its code once, and should only lead to one copy of the classes defined in the module's file.

If a subdirectory of $PWD is on $PYTHONPATH, and a package is imported both relative to $PWD and relative to that subdirectory, its code is loaded twice, and its classes are defined twice independently.

Downloading the attached file, and running:

mkdir folder
cd folder
tar xf file.tgz
PYTHONPATH=$(pwd)/package python main.py

should print import once, but does print import twice.

----------
files: packageissue.tgz
messages: 169842
nosy: daniel.wagner-hall
priority: normal
severity: normal
status: open
title: Package cache doesn't cache packages with overlapping sys.path entries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27119/packageissue.tgz

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

From report at bugs.python.org  Wed Sep  5 02:42:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 05 Sep 2012 00:42:31 +0000
Subject: [New-bugs-announce] [issue15865] reflect bare star * in function
	signature documentation
Message-ID: <1346805751.63.0.697181229134.issue15865@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to make sure that the bare * in the function signatures of pure Python functions is properly reflected in the documentation.

This will bring the signatures in the documentation closer to the signatures that we have in the Python code -- a goal articulated by Ezio in a comment to issue 15831.

For example, configparser.RawConfigParser() has this function signature:

def __init__(self, defaults=None, dict_type=_default_dict,
             allow_no_value=False, *, delimiters=('=', ':'),
             comment_prefixes=('#', ';'), inline_comment_prefixes=None,
             strict=True, empty_lines_in_values=True,
             default_section=DEFAULTSECT,
             interpolation=_UNSET):

But its documentation has no *:

class configparser.RawConfigParser(defaults=None, dict_type=collections.OrderedDict, allow_no_value=False, delimiters=('=', ':'), comment_prefixes=('#', ';'), inline_comment_prefixes=None, strict=True, empty_lines_in_values=True, default_section=configaparser.DEFAULTSECT, interpolation=None)

(from http://docs.python.org/dev/library/configparser.html#configparser.RawConfigParser )

>From a search of the code, there are about 60 occurrences of a bare * in the signature of a pure Python function (not all of which will need to be updated).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 169850
nosy: cjerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: reflect bare star * in function signature documentation
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep  5 20:54:34 2012
From: report at bugs.python.org (Wim)
Date: Wed, 05 Sep 2012 18:54:34 +0000
Subject: [New-bugs-announce] [issue15866] encode(...,
	'xmlcharrefreplace') produces entities for surrogate pairs
Message-ID: <1346871274.13.0.653364801762.issue15866@psf.upfronthosting.co.za>


New submission from Wim:

Encoding a (well-formed) Unicode string containing a non-BMP character, using the xmlcharrefreplace error handler, will produce two XML entities for surrogate codepoints instead of one entity for the actual character.

Here's a transcript (Python 2.7.3, x86_64):


  >>> b = '\xf0\x9f\x92\x9d'
  >>> u = b.decode('utf8')
  >>> u
  u'\U0001f49d'
  >>> u.encode('ascii', errors='xmlcharrefreplace')
  '&#55357;&#56477;'
  >>> ( u'\U0001f49d' ).encode('ascii', errors='xmlcharrefreplace')
  '&#55357;&#56477;'
  >>> list(u)
  [u'\ud83d', u'\udc9d']
  >>> u.encode('utf8', errors='xmlcharrefreplace')
  '\xf0\x9f\x92\x9d'

The utf8 bytestring is correctly decoded, and the print representation shows one single Unicode character. Encoding using xmlcharrefreplace produces two XML entities, which is wrong[1]: a single non-BMP character should be represented in XML as a single entity reference, in this case presumably '&#128157;'.

As the last two lines show, I'm using a narrow build (so the unicode strings are represented internally in UTF-16, I guess). Converting the string back to utf8 does the right thing, and emits a single UTF8 sequence representing the supplementary-plane codepoint.

(FWIW, the backslashreplace error handler also emits a surrogate pair, but I don't know if there is a complete specification for what that handler does, so it's possible that it's not wrong.)

[1] http://www.w3.org/International/questions/qa-escapes#bytheway

----------
components: Library (Lib), Unicode
messages: 169886
nosy: ezio.melotti, wiml
priority: normal
severity: normal
status: open
title: encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  6 03:22:43 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 06 Sep 2012 01:22:43 +0000
Subject: [New-bugs-announce] [issue15867] It's hard to decypher how to build
	off of the provided	objects from the importlib docs
Message-ID: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za>


New submission from Julian Berman:

I find that the importlib documentation is a bit too low level. Import hooks are not that common, so requiring a bit of reading is OK with me, but I somewhat *understand* PEP 302, so I have a general idea of *what* I want to do and what kind of objects can accomplish that, and still find it hard to figure out how to take the pieces provided by importlib and use them to do what I want.

If I provide a specific example, I want to create a path hook that "just" does the usual import behavior, but before executing the module, does some transformation on the source code, say. In trying to figure out the best way to do that I had a hard time using the docs to figure out which pieces I should assemble to do that. I'm going to just describe the rough series of steps I went through, and hopefully that will help give a picture of where in the docs I had trouble.

`importlib.abc` has a few things that would appear to help. None of the things seem like an exact match, so immediately I'm confused -- after reading PEP 302 I'd have expected to need to find an object to implement one or both of `get_code` or `get_source` on, or one that has that implemented that I can subclass and extend. The closest thing there that I find is PyPycLoader, which seems to be saying it implements the standard import behavior, but the docs say its deprecated and to use SourceLoader. At this point, after checking out `SourceLoader` and seeing that it has me implementing two methods whose purpose I don't quite understand, even after reading the short descriptions of them, at least not in the context of what I want to do, I begin to suspect that what I really want is to combine SourceLoader with some things from the `imp` module, or maybe `importlib.__import__`, but am left wondering again how much I need to implement before I just can use that. I then notice `importlib.util.module_for_loader`, and add that to the simple loader I've written which I'm still waiting to plug `imp` into, before realizing that that decorator eats the `fullname` attribute and *only* passes along the module, which confuses me, since now I don't know how to retrieve the source for the module object that I'm being passed -- so I save the path name in `__init__` for the class, and assume that's what I should be doing, despite not seeing an example doing that. Assuming that's even correct as-is, it took me quite a bit to put those pieces together.

So I apologize for rambling -- I think essentially what'd improve things is providing more examples, or perhaps a HOWTO entry, that targeted assembling the pieces provided in the module into a few clear, complete examples of finders, loaders and importers.

----------
assignee: docs at python
components: Documentation
messages: 169901
nosy: Julian, docs at python
priority: normal
severity: normal
status: open
title: It's hard to decypher how to build off of the provided objects from the importlib docs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep  6 11:32:14 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 06 Sep 2012 09:32:14 +0000
Subject: [New-bugs-announce] [issue15868] leak in bytesio.c
Message-ID: <1346923934.68.0.507975450675.issue15868@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Coverity found a leak in bytesio.c. Patch attached.

----------
components: Extension Modules
files: bytesio_leak.diff
keywords: patch
messages: 169907
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: leak in bytesio.c
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file27133/bytesio_leak.diff

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

From report at bugs.python.org  Thu Sep  6 13:11:14 2012
From: report at bugs.python.org (Dominik George)
Date: Thu, 06 Sep 2012 11:11:14 +0000
Subject: [New-bugs-announce] [issue15869] Include .desktop file and icon
Message-ID: <1346929874.07.0.220677915984.issue15869@psf.upfronthosting.co.za>


New submission from Dominik George:

As a graphical application, IDLE, is shipped, a .desktop file should be included for intallation to /usr/share/applications. Furthermore, a 16x16 pixel version in XPM format of the Python icon should be shipped to accompany the menu entries.

Attached is a tarball containing .desktop files for IDLE 2 and 3 as well as the icon.

----------
components: IDLE
files: python-freedesktop-files.tar.bz2
messages: 169912
nosy: natureshadow
priority: normal
severity: normal
status: open
title: Include .desktop file and icon
type: enhancement
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file27135/python-freedesktop-files.tar.bz2

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

From report at bugs.python.org  Thu Sep  6 17:49:26 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 06 Sep 2012 15:49:26 +0000
Subject: [New-bugs-announce] [issue15870] PyType_FromSpec should take
	metaclass as an argument
Message-ID: <1346946566.36.0.583610018294.issue15870@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

PyType_FromSpec() is a convenient function to create types dynamically in C extension modules, but its usefulness is limited by the fact that it creates new types using the default metaclass.

I suggest adding a new C API function

PyObject *PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec)

and redefine PyType_FromSpec() as

PyType_FromSpecEx((PyObject *)&PyType_Type, spec)


This functionality cannot be implemented by user because PyType_FromSpec requires access to private slotoffsets table.

A (trivial) patch attached.

----------
assignee: belopolsky
components: Interpreter Core
files: typeobject.diff
keywords: needs review, patch
messages: 169925
nosy: belopolsky, loewis
priority: normal
severity: normal
stage: test needed
status: open
title: PyType_FromSpec should take metaclass as an argument
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27137/typeobject.diff

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

From report at bugs.python.org  Thu Sep  6 19:14:26 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 06 Sep 2012 17:14:26 +0000
Subject: [New-bugs-announce] [issue15871] Online docs: make index search
	always available.
Message-ID: <1346951666.84.0.523873961498.issue15871@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

For the Windows Help version of the docs, the left side box has 4 tabs: Contents, Index, Search, Favorites. I now mostly use the Index tab. That means that I can enter an indexed keyword, topic, or object name and jump from place to place in the docs.

The left margin of the online docs only has a text search box equivalent to the Windows search tab (which I essentially never use). The index is only available on the front page, possibly not even visible without scrolling. Consequently, people, especially beginners, tend to use the text search box when they should be using the index. The result is often useless.

The issue came up on python-list about a beginner entering 'print' and getting nothing useful. With the Windows doc, 'print' in the index search immediately brings up print (builtin function) (twice, I did not look into why). The same thing in the search lists 153 pages, with the builtin functions page at 75. Not too surprising, as it is a long page with only 3 occurrences of 'print'. Also not useful.

So I think the online docs should also have an always available index search box in addition to the text search box (which should be properly labeled as such). 'Enter a module, class, for function name.' should be applied to index search, not text search.

An alternative is for the one box to give both index search results and text search results, but doing the latter when one only wants the former is a waste of both server and reader resources.

----------
assignee: docs at python
components: Documentation
messages: 169930
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: Online docs: make index search always available.
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep  6 22:07:15 2012
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 06 Sep 2012 20:07:15 +0000
Subject: [New-bugs-announce] [issue15872] shutil.rmtree(...,
	ignore_errors=True) doesn't ignore all errors
Message-ID: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

This used to work correctly in Python 3.2:

Python 3.3.0rc1 (default, Aug 29 2012, 00:39:20) 
[GCC 4.7.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.rmtree('/etc/fstab', ignore_errors=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/shutil.py", line 456, in rmtree
    "Not a directory: '{}'".format(path))
NotADirectoryError: [Errno 20] Not a directory: '/etc/fstab'

----------
messages: 169936
nosy: jwilk
priority: normal
severity: normal
status: open
title: shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep  6 23:08:50 2012
From: report at bugs.python.org (John Nagle)
Date: Thu, 06 Sep 2012 21:08:50 +0000
Subject: [New-bugs-announce] [issue15873] "datetime" cannot parse ISO 8601
	dates and times
Message-ID: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>


New submission from John Nagle:

The datetime module has support for output to a string of dates and times in ISO 8601 format ("2012-09-09T18:00:00-07:00"), with the object method "isoformat([sep])".  But there's no support for parsing such strings.  A string to datetime class method should be provided, one capable of parsing at least the RFC 3339 subset of ISO 8601.

The problem is parsing time zone information correctly.
The allowed formats for time zone are
   empty       - no TZ, date/time is "naive" in the datetime sense
   Z           - zero, or Zulu time, i.e. UTC.
   [+-]nn.nn   - offset from UTC
   
"strptime" does not understand timezone offsets. The "datetime" documentation suggests that the "z" format directive handles time zone info, but that's not actually implemented for input.  

Pypi has four modules for parsing ISO 8601 dates. Each has least one major
problem in time zone handling:

iso8601 0.1.4 		
   Abandonware.  Mishandles time zone when time zone is "Z" and
   the default time zone is specified. 
iso8601.py 0.1dev 	
   Always returns a "naive" datetime object, even if zone specified.
iso8601plus 0.1.6 	
   Fork of abandonware version above.  Same bug.
zc.iso8601 0.2.0
   Zope version.  Imports the pytz module with the full Olsen time zone
   database, but doesn't actually use that database.

Thus, nothing in Pypi provides a good alternative. 

It would be appropriate to handle this in the datetime module.  One small, correct, tested function would be better than the existing five bad alternatives.

----------
components: Library (Lib)
messages: 169941
nosy: nagle
priority: normal
severity: normal
status: open
title: "datetime" cannot parse ISO 8601 dates and times
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep  7 02:04:51 2012
From: report at bugs.python.org (Nat Hillard)
Date: Fri, 07 Sep 2012 00:04:51 +0000
Subject: [New-bugs-announce] [issue15874] argparse cannot parse bash
	variable arguments in	file-given arguments
Message-ID: <1346976291.75.0.854427077128.issue15874@psf.upfronthosting.co.za>


New submission from Nat Hillard:

When using the argparse argument fromfile_prefix_chars to obtain command line arguments from a file, it is not possible to make use of bash environment variables within this file. 

Ideally one would be able to `export BAR='/Users/x/Desktop/bar'`, and then give arguments such as:

--foo
$BAR

and have this correctly expanded at read time to --foo '/Users/x/Desktop/bar'.

To my knowledge, this is currently only possible if you give the arguments directly via the command line:
python test.py --foo $BAR

It would be great to be able to use environment variables within files as well!

----------
components: Library (Lib)
messages: 169958
nosy: ZhuangZi, bethard
priority: normal
severity: normal
status: open
title: argparse cannot parse bash variable arguments in file-given arguments
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  7 03:24:22 2012
From: report at bugs.python.org (Manuke)
Date: Fri, 07 Sep 2012 01:24:22 +0000
Subject: [New-bugs-announce] [issue15875] tarfile may not make @LongLink for
	non-ascii character
Message-ID: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za>


New submission from Manuke:

When I will make a GNU tar-file with 'tarfile', @LongLink may not be made though the name of the archived-file is long, if the name uses non-ascii characters.

In tarfile.py, the check code of the filename length is described as follows now:

tarfile.py: 1032
<         if len(info["name"]) > LENGTH_NAME:

But, the type of the value is 'str', it is not encoded.
It must be described as follows:

>         if len(info["name"].encode(encoding, errors)) > LENGTH_NAME:

There seems to be the same problem in Line 1029(and the other functions for other formats), but I have not confirmed.

----------
components: Library (Lib)
messages: 169962
nosy: Manuke
priority: normal
severity: normal
status: open
title: tarfile may not make @LongLink for non-ascii character
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep  7 08:36:12 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 07 Sep 2012 06:36:12 +0000
Subject: [New-bugs-announce] [issue15876] test_curses refleak
Message-ID: <1346999772.54.0.326284288663.issue15876@psf.upfronthosting.co.za>


New submission from Ross Lagerwall:

[1/1] test_curses
beginning 6 repetitions
123456
.
test_curses leaked [1, 1, 1] references, sum=3
1 test failed:
    test_curses
[154814 refs]

----------
assignee: rosslagerwall
messages: 169973
nosy: rosslagerwall
priority: low
severity: normal
status: open
title: test_curses refleak
type: resource usage

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

From report at bugs.python.org  Fri Sep  7 08:38:03 2012
From: report at bugs.python.org (Dan Callaghan)
Date: Fri, 07 Sep 2012 06:38:03 +0000
Subject: [New-bugs-announce] [issue15877] xml.dom.minidom cannot parse
	ISO-2022-JP
Message-ID: <1346999883.79.0.0390921600311.issue15877@psf.upfronthosting.co.za>


New submission from Dan Callaghan:

Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> c = u'\u65e5\u672c\u8a9e'
>>> import xml.dom.minidom

Encoded as UTF-8, everything is fine:

>>> xml.dom.minidom.parseString('<?xml version="1.0" encoding="UTF-8" ?><x>%s</x>' % c.encode('UTF-8'))
<xml.dom.minidom.Document instance at 0x7f310d27dcf8>

but not ISO-2022-JP:

>>> xml.dom.minidom.parseString('<?xml version="1.0" encoding="ISO-2022-JP" ?><x>%s</x>' % c.encode('ISO-2022-JP'))
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
  File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/minidom.py", line 1925, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", line 942, in parseString
    return builder.parseString(string)
  File "/usr/lib64/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 48

lxml can handle it fine though:

>>> import lxml.etree
>>> lxml.etree.fromstring('<?xml version="1.0" encoding="ISO-2022-JP" ?><x>%s</x>' % c.encode('ISO-2022-JP'))
<Element x at 0x7f310d284960>
>>> _.text == c
True

----------
components: XML
messages: 169974
nosy: dcallagh
priority: normal
severity: normal
status: open
title: xml.dom.minidom cannot parse ISO-2022-JP
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  7 10:15:46 2012
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCa0L7QstCx0LA=?=)
Date: Fri, 07 Sep 2012 08:15:46 +0000
Subject: [New-bugs-announce] [issue15878] struct long type size
Message-ID: <1347005746.88.0.0980620754305.issue15878@psf.upfronthosting.co.za>


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

Such code PackageFile.write(struct.pack( "l", PkgHdrSize)) have different behaviour on 32-bit and 64-bit systems.
In case 32-bit system it writes to file 4 bytes. and 8 bytes in case 64-bit system, but in http://docs.python.org/library/struct.html p.7.3.2.2 long type have strict 4-byte size.

----------
messages: 169980
nosy: ??????.?????
priority: normal
severity: normal
status: open
title: struct long type size
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  7 17:44:41 2012
From: report at bugs.python.org (Jon Obermark)
Date: Fri, 07 Sep 2012 15:44:41 +0000
Subject: [New-bugs-announce] [issue15879] set.__or__, __and__,
	etc create subclass types, but ignore __new__
Message-ID: <1347032681.85.0.731459990005.issue15879@psf.upfronthosting.co.za>


New submission from Jon Obermark:

If they are not going to call the __metaclass__ or the class __new__, then they should return `set` objects instead of subclass objects, so that it is clear what is going on.

As it is, the results of set operations receive some subclass information but not all.  So they are not really obeying the notion of a subclass: the results are neither `set` objects, nor properly-constructed objects of the `set` subclass.

e.g. 
class Fooset(Set):
  def __new__(cls, s = []):
    print 'New called'
    self = super(Fooset, cls).__new__(cls)
    self.update(s)
    if isinstance(s, Fooset):
      self.foo = s.foo
    else:
      self.foo = 'default'
    return self

x = Fooset([1,2,5])
y = x|x


The object `y` reports being of the type `Fooset`, but has not been constructed by the `type` that makes `Fooset` objects.

----------
messages: 169986
nosy: Jon.Obermark
priority: normal
severity: normal
status: open
title: set.__or__, __and__, etc create subclass types, but ignore __new__

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

From report at bugs.python.org  Fri Sep  7 18:40:15 2012
From: report at bugs.python.org (Kalle Rutanen)
Date: Fri, 07 Sep 2012 16:40:15 +0000
Subject: [New-bugs-announce] [issue15880] os.path.split() and long UNC names
Message-ID: <1347036015.89.0.836232949292.issue15880@psf.upfronthosting.co.za>


New submission from Kalle Rutanen:

On Windows, long-UNC paths are needed to inspect and modify paths with more than 260 characters. The os.path.split() function behaves incorrectly in the presence of a long-UNC prefix //?/ or \\?\. Consider iterating d = os.path.split(d)[0] with d = '//?/e:/python-test/dir'. Then the values of d are as follows:

'//?/e:/python-test/dir'
'//?/e:/python-test'
'//?/e:'
'//?'
'//'

The two last splits are the incorrect ones, where the splitting should end at '//?/e:'.

One consequence of this is that os.makedirs(d) crashes, because it attempts to run os.mkdir('//') at the bottom of its recursion. The same thing happens when replacing all / with \\ in the above.

----------
components: Library (Lib)
messages: 169990
nosy: kaba2
priority: normal
severity: normal
status: open
title: os.path.split() and long UNC names
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  7 20:56:40 2012
From: report at bugs.python.org (Chris McDonough)
Date: Fri, 07 Sep 2012 18:56:40 +0000
Subject: [New-bugs-announce] [issue15881] multiprocessing 'NoneType' object
	is not callable
Message-ID: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za>


New submission from Chris McDonough:

The symptom is an exact duplicate of the symptom reported in the following (closed) issue:

http://bugs.python.org/issue9775

The issue is also related to the following other issues:

http://bugs.python.org/issue4106
http://bugs.python.org/issue9205
http://bugs.python.org/issue9207

To reproduce the symptom driving the patches that will be attached to this issue:

  git clone git://github.com/pypa/pip.git
  cd pip
  /any/python setup.py dev
  /any/python setup.py test

You can either wait for the entire test suite to finish or you can press ctrl-C at any time (the tests take a long time).  In either case, a traceback like the following will be printed to the console.

  Error in atexit._run_exitfuncs:
  Traceback (most recent call last):
    File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
    File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", line 284, in _exit_function
      info('process shutting down')
  TypeError: 'NoneType' object is not callable
  Error in sys.exitfunc:
  Traceback (most recent call last):
    File "/home/chrism/opt/Python-2.7.3/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
      func(*targs, **kargs)
    File "/home/chrism/opt/Python-2.7.3/lib/python2.7/multiprocessing/util.py", line 284, in _exit_function
      info('process shutting down')
  TypeError: 'NoneType' object is not callable

>From what I understand in other issues, multiprocessing.util._exit_function shouldn't actually be called *after*  the containing module's globals are destroyed (it should be called before), but this does indeed happen.

Patches will be attached that anticipate the symptom and prevent a shutdown error.  One will be attached for Python 2.7 branch, the other for the Python tip.   Each causes functions that are called at shutdown time to keep a reference around to other functions and globals used within the function, and each does some checks for the insane state and prevents an error from happening in this insane state.

----------
components: Library (Lib)
messages: 170003
nosy: mcdonc
priority: normal
severity: normal
status: open
title: multiprocessing 'NoneType' object is not callable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Sep  8 00:47:55 2012
From: report at bugs.python.org (Aaron)
Date: Fri, 07 Sep 2012 22:47:55 +0000
Subject: [New-bugs-announce] [issue15882] _decimal.Decimal constructed from
	tuple
Message-ID: <1347058075.63.0.395926246222.issue15882@psf.upfronthosting.co.za>


New submission from Aaron:

I think I may have found a problem with the code that constructs Infinity from tuples in the C _decimal module.

# pure python (3.x or 2.x)
>>> decimal.Decimal( (0, (0, ), 'F'))
Decimal('Infinity')

# _decimal
>>> decimal.Decimal( (0, (0, ), 'F'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

Also, there is no unit test coverage for constructing these special values from tuples either.  I have provided some that pass with the existing pure python code and with the modifications to the _decimal C code.

The unit tests can be applied to Python 2.7.x as well, if desired.  They would go in the ExplicitConstructionTest.test_explicit_from_tuples() method.

----------
components: Extension Modules
files: _decimal.diff
keywords: patch
messages: 170017
nosy: hac.man
priority: normal
severity: normal
status: open
title: _decimal.Decimal constructed from tuple
versions: Python 3.3
Added file: http://bugs.python.org/file27144/_decimal.diff

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

From report at bugs.python.org  Sat Sep  8 15:35:02 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 08 Sep 2012 13:35:02 +0000
Subject: [New-bugs-announce] [issue15883] Add Py_errno to work around
	multiple CRT issue
Message-ID: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za>


New submission from Christian Heimes:

errno is usually implemented as thread local variable, more precisely as a macro that calls a function which returns the memory address of a thread local variable. Each C runtime library has its own function and TLS which introduces an issue when a Python extension uses a different CRT than the core. AFAIK that an issue only an issue on Windows with other versions of Visual Studio.

This means that mixed CRTs break the three PyErr_SetFromErrno* functions as they always access the errno of the core's CRT. The patch adds a Py_errno macro that must be used in extensions before a PyErr_SetFromErrno() function is used.

Example:
fd = open(filename, O_RDONLY);
if (fd == -1) {
    Py_errno = errno;
    return PyErr_SetFromErrnoWithFilename(PyExc_OSError, filename);
}

The issue was discovered by me a about two weeks ago and further analyzed by Martin. http://mail.python.org/pipermail/python-dev/2012-August/121460.html

----------
components: Build, Extension Modules, Interpreter Core
files: pyerrno.patch
keywords: patch
messages: 170050
nosy: christian.heimes, georg.brandl, loewis, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add Py_errno to work around multiple CRT issue
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27148/pyerrno.patch

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

From report at bugs.python.org  Sat Sep  8 19:59:36 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 08 Sep 2012 17:59:36 +0000
Subject: [New-bugs-announce] [issue15884] PEP 3121,
	384 Refactoring applied to ctypes module
Message-ID: <1347127176.13.0.489231744375.issue15884@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
assignee: belopolsky
nosy: belopolsky
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to ctypes module
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  9 02:15:09 2012
From: report at bugs.python.org (Albert Zeyer)
Date: Sun, 09 Sep 2012 00:15:09 +0000
Subject: [New-bugs-announce] [issue15885] @staticmethod __getattr__ doesn't
	work
Message-ID: <1347149709.6.0.110064908732.issue15885@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

Code:

```
class Wrapper:
        @staticmethod
        def __getattr__(item):
                return repr(item) # dummy

a = Wrapper()
print(a.foo)
```

Expected output: 'foo'

Actual output with Python 2.7:

Traceback (most recent call last):
  File "test_staticmethodattr.py", line 7, in <module>
    print(a.foo)
TypeError: 'staticmethod' object is not callable

Python 3.2 does return the expected ('foo').
PyPy returns the expected 'foo'.

----------
components: Interpreter Core
messages: 170070
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: @staticmethod __getattr__ doesn't work
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep  9 09:17:30 2012
From: report at bugs.python.org (Masato HASHIMOTO)
Date: Sun, 09 Sep 2012 07:17:30 +0000
Subject: [New-bugs-announce] [issue15886] Doc: same word iteration
Message-ID: <1347175050.22.0.936746811947.issue15886@psf.upfronthosting.co.za>


New submission from Masato HASHIMOTO:

Same word (<path_fd>) is iterated in Doc/library/os.rst.

1858 This function can support :ref:`specifying a file descriptor
1859 <path_fd>`, :ref:`specifying a file descriptor <path_fd>` and :ref:`not
1860 following symlinks <follow_symlinks>`.

version: releasing/3.3.0 @ 78787:c5bc19ce4d2b

----------
assignee: docs at python
components: Documentation
messages: 170081
nosy: docs at python, hashimo
priority: normal
severity: normal
status: open
title: Doc: same word iteration
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep  9 12:18:57 2012
From: report at bugs.python.org (Simonas Kazlauskas)
Date: Sun, 09 Sep 2012 10:18:57 +0000
Subject: [New-bugs-announce] [issue15887] urlencode should accept generators
	or two elements tuples
Message-ID: <1347185937.29.0.747427121658.issue15887@psf.upfronthosting.co.za>


New submission from Simonas Kazlauskas:

``urllib.parse.urlencode([('i', i) for i in range(1000)])`` works, but ``urlencode(('i', i) for i in range(1000))`` raises a ``TypeError: not a valid non-string sequence or mapping object``.

Allowing urlencode to accept generators would make life a bit easier.

----------
components: Library (Lib)
messages: 170094
nosy: nagisa
priority: normal
severity: normal
status: open
title: urlencode should accept generators or two elements tuples
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep  9 13:32:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 09 Sep 2012 11:32:29 +0000
Subject: [New-bugs-announce] [issue15888] ipaddress HOWTO examples have some
	errors
Message-ID: <1347190349.96.0.156720503481.issue15888@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The ipaddress HOWTO seems to have some errors in its interactive doctest examples.  Below are the errors after running the doctests for it using the regrtest patch posted to issue 15629.  (This is the first doc file for which I have used the modified script to open an issue.)

The errors seem valid to me on casual inspection.

Note that you need to add an initial ">>> import ipaddress" at the beginning of the first doctest example to have these actually run.


----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 146, in ipaddress.rst
Failed example:
    ipaddress.ip_network('2001:db8::1/96')
Exception raised:
    Traceback (most recent call last):
      File "Lib/doctest.py", line 1287, in __run
        compileflags, 1), test.globs)
      File "<doctest ipaddress.rst[15]>", line 1, in <module>
        ipaddress.ip_network('2001:db8::1/96')
      File "Lib/ipaddress.py", line 79, in ip_network
        return IPv6Network(address, strict)
      File "Lib/ipaddress.py", line 2056, in __init__
        raise ValueError('%s has host bits set' % self)
    ValueError: 2001:db8::1/96 has host bits set
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 181, in ipaddress.rst
Failed example:
    net4.numhosts
Exception raised:
    Traceback (most recent call last):
      File "Lib/doctest.py", line 1287, in __run
        compileflags, 1), test.globs)
      File "<doctest ipaddress.rst[25]>", line 1, in <module>
        net4.numhosts
    AttributeError: 'IPv4Network' object has no attribute 'numhosts'
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 184, in ipaddress.rst
Failed example:
    net6.numhosts
Exception raised:
    Traceback (most recent call last):
      File "Lib/doctest.py", line 1287, in __run
        compileflags, 1), test.globs)
      File "<doctest ipaddress.rst[27]>", line 1, in <module>
        net6.numhosts
    AttributeError: 'IPv6Network' object has no attribute 'numhosts'
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 190, in ipaddress.rst
Failed example:
    for x in net4.hosts():
Exception raised:
    Traceback (most recent call last):
      File "Lib/doctest.py", line 1287, in __run
        compileflags, 1), test.globs)
      File "<doctest ipaddress.rst[29]>", line 1
        for x in net4.hosts():
                             ^
    SyntaxError: unexpected EOF while parsing
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 219, in ipaddress.rst
Failed example:
    addr6.exploded
Expected:
    '2001:0db8:0000:0000:0000:0000:0000:0000'
Got:
    '2001:0db8:0000:0000:0000:0000:0000:0001'
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 221, in ipaddress.rst
Failed example:
    addr6.compressed
Expected:
    '2001:db8::'
Got:
    '2001:db8::1'
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 244, in ipaddress.rst
Failed example:
    net6[1]
Expected:
    IPv6Address('2001::1')
Got:
    IPv6Address('2001:db8::1')
----------------------------------------------------------------------
File "Doc/howto/ipaddress.rst", line 246, in ipaddress.rst
Failed example:
    net6[-1]
Expected:
    IPv6Address('2001::ffff:ffff')
Got:
    IPv6Address('2001:db8::ffff:ffff')

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 170097
nosy: cjerdonek, docs at python, ncoghlan, pmoody
priority: normal
severity: normal
stage: needs patch
status: open
title: ipaddress HOWTO examples have some errors
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep  9 14:20:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 09 Sep 2012 12:20:19 +0000
Subject: [New-bugs-announce] [issue15889] regrtest --start option raises
	AttributeError in many	scenarios
Message-ID: <1347193219.18.0.453057488599.issue15889@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The --start option to regrtest raises an AttributeError in many scenarios.  For example, these both raise an error:

$ ./python.exe -m test --start test_random
$ ./python.exe -m test --start test_random test_binascii test_random

Traceback (most recent call last):
  File ".../Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File ".../Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File ".../Lib/test/__main__.py", line 13, in <module>
    regrtest.main()
  File ".../Lib/test/regrtest.py", line 562, in main
    del tests[:tests.index(start)]
AttributeError: 'NoneType' object has no attribute 'index'

Patch attached.

----------
components: Tests
files: issue-regrtest-start-1.patch
keywords: easy, patch
messages: 170099
nosy: cjerdonek, ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: regrtest --start option raises AttributeError in many scenarios
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27151/issue-regrtest-start-1.patch

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

From report at bugs.python.org  Sun Sep  9 20:27:06 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Sun, 09 Sep 2012 18:27:06 +0000
Subject: [New-bugs-announce] [issue15890] lib2to3 pickles created with wrong
	permissions
Message-ID: <1347215226.9.0.69518719078.issue15890@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

The fix of #15822 caused another break. After installing 3.3rc2 from source, ls -ltc --full-time /usr/local/lib/python3.3/lib2to3/ shows:

-rw-------. 1 root root  1455 2012-09-09 20:55:36.475519602 +0300 PatternGrammar3.3.0.candidate.2.pickle
-rw-------. 1 root root 20862 2012-09-09 20:55:36.425520211 +0300 Grammar3.3.0.candidate.2.pickle
drwx------. 2 root root  4096 2012-09-09 20:55:33.681520171 +0300 __pycache__/
drwxr-xr-x. 4 root root  4096 2012-09-09 20:55:30.087520195 +0300 tests/
drwxr-xr-x. 3 root root  4096 2012-09-09 20:55:30.063457702 +0300 pgen2/
drwxr-xr-x. 3 root root  4096 2012-09-09 20:55:30.028520614 +0300 fixes/
-rw-r--r--. 1 root root 28046 2012-09-09 20:55:09.319519773 +0300 refactor.py
-rw-r--r--. 1 root root 28386 2012-09-09 20:55:09.279456945 +0300 pytree.py
-rw-r--r--. 1 root root  1114 2012-09-09 20:55:09.242458183 +0300 pygram.py
-rw-r--r--. 1 root root   793 2012-09-09 20:55:09.205457004 +0300 PatternGrammar.txt
-rw-r--r--. 1 root root  7075 2012-09-09 20:55:09.168457078 +0300 patcomp.py
-rw-r--r--. 1 root root 11624 2012-09-09 20:55:09.131457019 +0300 main.py
-rw-r--r--. 1 root root    67 2012-09-09 20:55:09.091644598 +0300 __main__.py
-rw-r--r--. 1 root root     7 2012-09-09 20:55:09.052457036 +0300 __init__.py
-rw-r--r--. 1 root root  6589 2012-09-09 20:55:09.014519602 +0300 Grammar.txt
-rw-r--r--. 1 root root 14533 2012-09-09 20:55:08.977519642 +0300 fixer_util.py
-rw-r--r--. 1 root root  6706 2012-09-09 20:55:08.940519615 +0300 fixer_base.py
-rw-r--r--. 1 root root 10011 2012-09-09 20:55:08.903519608 +0300 btm_utils.py
-rw-r--r--. 1 root root  6833 2012-09-09 20:55:08.865457147 +0300 btm_matcher.py


The pickles are now correctly newer than the Grammar texts, but are readable only by root. Quick chmod fixes this, but has to be done manually on systems with strict UMASK for root.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 170124
nosy: tpievila
priority: normal
severity: normal
status: open
title: lib2to3 pickles created with wrong permissions
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep  9 21:08:04 2012
From: report at bugs.python.org (Julian Berman)
Date: Sun, 09 Sep 2012 19:08:04 +0000
Subject: [New-bugs-announce] [issue15891] A public facing API for __unittest
	= True
Message-ID: <1347217684.87.0.845437270023.issue15891@psf.upfronthosting.co.za>


New submission from Julian Berman:

Can `__unittest = True`, which is used to hide stack frames from tracebacks inside the testing framework, be documented as being public, or, if that's not acceptable, be replaced by something that is? `_exc_info_to_string` is a hairy function to need to rewrite when authoring a testing framework, but it's a rather common thing to want, and would be nice if it was easily done by integrating with what `TestCase` is already doing.

It's also (with or without formal blessing) being used in the wild in at least one place I know of here http://bazaar.launchpad.net/~testtools-committers/testtools/trunk/view/head:/testtools/testcase.py#L798  and since it's not terribly critical and will fail rather nicely even if the API changes suddenly I'd bet other places are using it too, though I haven't bothered to check.

See also http://twistedmatrix.com/trac/ticket/4127  which would be easier to implement if this were acceptable to use for external code.

----------
components: Library (Lib)
messages: 170126
nosy: Julian, michael.foord
priority: normal
severity: normal
status: open
title: A public facing API for __unittest = True
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Sep  9 23:56:02 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Sep 2012 21:56:02 +0000
Subject: [New-bugs-announce] [issue15892] _PyImport_GetDynLoadFunc() doesn't
	check return value of	fstat()
Message-ID: <1347227762.77.0.329908285172.issue15892@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The function _PyImport_GetDynLoadFunc() in Python/dynload_shlib.c doesn't check the return value of fstat()

CID 486250: Other violation (CHECKED_RETURN)At (3): Calling function "fstat(fileno(fp), &statb)" without checking return value. This library function may fail and return an error code.
At (4): No check of the return value of "fstat(fileno(fp), &statb)".
 93        fstat(fileno(fp), &statb);

Suggested fix:
if (fstat(fileno(fp), &statb) == -1) {
    PyErr_SetFromErrnoWithFilename(PyExc_IOError, pathname);
    return NULL;
}
}

----------
components: Interpreter Core
messages: 170138
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: _PyImport_GetDynLoadFunc() doesn't check return value of fstat()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 10 00:09:58 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Sep 2012 22:09:58 +0000
Subject: [New-bugs-announce] [issue15893] Py_FrozenMain() resource leak and
	missing malloc checks
Message-ID: <1347228598.43.0.424519630485.issue15893@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In Python/frozenmain.c the function Py_FrozenMain() doesn't handle argv_copy and argv_copy2 correctly. Both variables contain memory that is allocated with PyMem_Malloc(). argv_copy2 is never checked for NULL and both variables are not correctly cleaned up in error cases.

CID 486834: Resource leak (RESOURCE_LEAK)At (11): Variable "argv_copy" going out of scope leaks the storage it points to. 
CID 486835: Resource leak (RESOURCE_LEAK)At (9): Variable "argv_copy2" going out of scope leaks the storage it points to.

Suggested fix:
Separate var declaration from PyMem_Malloc() calls and use a goto label to clean up the variables and its content at the end of the function.

----------
components: Interpreter Core
messages: 170139
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Py_FrozenMain() resource leak and missing malloc checks
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 10 00:23:14 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Sep 2012 22:23:14 +0000
Subject: [New-bugs-announce] [issue15894] _PyImport_ReInitLock() doesn't
	check return value of	PyThread_acquire_lock
Message-ID: <1347229394.03.0.409721609393.issue15894@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Coverity claims that the call to PyThread_acquire_lock with NOWAIT_LOCK can fail. It sounds plausible as you don't wait for the lock to succeed.

CID 486861: Unchecked return value (CHECKED_RETURN)At (3): Calling function "PyThread_acquire_lock(PyThread_type_lock, int)" without checking return value (as is done elsewhere 22 out of 23 times).
At (9): No check of the return value of "PyThread_acquire_lock(import_lock, 0)".
 205        PyThread_acquire_lock(import_lock, 0);
 206        /* XXX: can the previous line fail? */

By the way the code would be more readable with NOWAIT_LOCK instead of 0.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 170141
nosy: brett.cannon, christian.heimes
priority: normal
severity: normal
status: open
title: _PyImport_ReInitLock() doesn't check return value of PyThread_acquire_lock
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Sep 10 00:50:50 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 09 Sep 2012 22:50:50 +0000
Subject: [New-bugs-announce] [issue15895] PyRun_SimpleFileExFlags() can leak
	a FILE pointer
Message-ID: <1347231050.54.0.0211027720618.issue15895@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In Python/pythonrun.c PyRun_SimpleFileExFlags() may leak a FILE pointer if closeit is False and maybe_pyc_file returns true. This happens when the filename ends with ".pyc" or ".pyc". In this case the file is opened a second time with fopen() a few lines lower and assigned to the same variable "fp". However "fp" is never closed.

The bug was found by Coverity as CID 719689.

Georg: I've set the priority to release blocker as a resource leak of a file pointer and therefore rare file descriptor is IMHO a severe issue.

----------
assignee: georg.brandl
files: closeown.patch
keywords: patch
messages: 170142
nosy: brett.cannon, christian.heimes, georg.brandl
priority: release blocker
severity: normal
stage: patch review
status: open
title: PyRun_SimpleFileExFlags() can leak a FILE pointer
type: resource usage
Added file: http://bugs.python.org/file27159/closeown.patch

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

From report at bugs.python.org  Mon Sep 10 01:04:39 2012
From: report at bugs.python.org (Vitaly)
Date: Sun, 09 Sep 2012 23:04:39 +0000
Subject: [New-bugs-announce] [issue15896] Sporadic EINVAL in nonblocking
	pipe os.read when forked	child fails on Mac OS
Message-ID: <1347231879.4.0.256223701777.issue15896@psf.upfronthosting.co.za>


New submission from Vitaly:

Python 2.6.7 on Mac OS 10.7.4 running on MacBookPro laptop.


run attachment as: python test_pipe_error.py

The test() function makes multiple calls to _execute_child() in a loop. Every other call to _execute_child() fails with:
=====
os.read(3, 1048576) self pid:  43953
EINVAL FROM TEST:  Traceback (most recent call last):
  File "test_pipe_error.py", line 127, in test
    _execute_child()
  File "test_pipe_error.py", line 95, in _execute_child
    newData = os.read(errpipe_read, rSize)
OSError: [Errno 22] Invalid argument
=====

_execute_child() is based on subprocess.Popen._execute_child, but with most Popen code removed and errpipe_read configured as os.O_NONBLOCK in the parent process.  Raising of an Exception() instance is used to simulate failure in os.execvp() instead of calling os.execvp().

We initially experienced the EINVAL issue in the parent process' os.read call when os.execvp failed in the child (e.g., errno=2, "file not found"), so I stripped the code to bare minimum in order to reproduce the problem with a smaller code snippet.

----------
components: Library (Lib)
files: test_pipe_error.py
messages: 170144
nosy: vitaly
priority: normal
severity: normal
status: open
title: Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file27160/test_pipe_error.py

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

From report at bugs.python.org  Mon Sep 10 02:08:38 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2012 00:08:38 +0000
Subject: [New-bugs-announce] [issue15897] zipimport.c doesn't check return
	value of fseek()
Message-ID: <1347235718.45.0.529510656833.issue15897@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The code im zipimport.c doesn't check the return value of fseek() in at least four places. The missing checks may hide issues with the file or file system.

Solution:
Check for -1 and return with an appropriate call to PyErr_SetFromErrno()

----------
components: Extension Modules
keywords: easy
messages: 170146
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: zipimport.c doesn't check return value of fseek()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 10 02:58:14 2012
From: report at bugs.python.org (Andrew Moffat)
Date: Mon, 10 Sep 2012 00:58:14 +0000
Subject: [New-bugs-announce] [issue15898] OSX TTY bug
Message-ID: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za>


New submission from Andrew Moffat:

I'm getting some kind of race condition on OSX when trying to read the output from a pseudoterminal of a forked process.  This race conditional only occurs if I run tty.tcsetattr on the master side of the pty, regardless of if I actually change the mode or not.

Try running the following code on OSX multiple times.  Sometimes you'll see "testing", sometimes you won't, sometimes it hangs.  If you comment out "tty.tcsetattr", you will consistently see "testing".


import os
import pty
import resource
import signal
import tty


master, slave = pty.openpty()
pid = os.fork()


# BUG IS HERE
# we're not making any changes to the tty mode, but
# the mere act of setting a mode causes the output to only
# show up sometimes.
#
# comment out "tty.tcsetattr" and the bug goes away
mode = tty.tcgetattr(master)
tty.tcsetattr(master, tty.TCSANOW, mode)


# child process
if pid == 0:
    os.setsid()
    os.close(master)

    os.dup2(slave, 0)
    os.dup2(slave, 1)
    os.dup2(slave, 2)

    max_fd = resource.getrlimit(resource.RLIMIT_NOFILE)[0]
    os.closerange(3, max_fd)

    # make controlling terminal.  taken from pty.fork
    tmp_fd = os.open(os.ttyname(1), os.O_RDWR)
    os.close(tmp_fd)

    os.write(1, "testing".encode())

    os._exit(255)

# parent process
else:
    os.close(slave)

    try:
        print(os.read(master, 1024))

    finally:
        os.kill(pid, signal.SIGKILL)

----------
messages: 170147
nosy: amoffat
priority: normal
severity: normal
status: open
title: OSX TTY bug
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Sep 10 11:01:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 10 Sep 2012 09:01:56 +0000
Subject: [New-bugs-announce] [issue15899] howto/unicode.rst doctest
	corrections
Message-ID: <1347267716.91.0.310284408834.issue15899@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to fix Doc/howto/unicode.rst so that its doctests pass when using the doctest module.

Patch forthcoming.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 170167
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: howto/unicode.rst doctest corrections
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 10 11:58:22 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2012 09:58:22 +0000
Subject: [New-bugs-announce] [issue15900] Memory leak in
	PyUnicode_TranslateCharmap()
Message-ID: <1347271102.51.0.468950657705.issue15900@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Objects/unicodeobject.c:PyUnicode_TranslateCharmap() leaks a reference to the variable unicode. PyUnicode_Translate() is also implemented around the helper function _PyUnicode_TranslateCharmap() but it properly decrefs the reference to the first argument.

PyUnicode_Translate() also has an obsolete onError goto label. The patch fixes the leak and simplifies PyUnicode_Translate().

CID 719686

----------
components: Interpreter Core
files: translate_leak.patch
keywords: 3.3regression, patch
messages: 170170
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Memory leak in PyUnicode_TranslateCharmap()
type: resource usage
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27164/translate_leak.patch

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

From report at bugs.python.org  Mon Sep 10 11:59:39 2012
From: report at bugs.python.org (Simon R)
Date: Mon, 10 Sep 2012 09:59:39 +0000
Subject: [New-bugs-announce] [issue15901] multiprocessing sharedctypes Array
	don't accept strings
Message-ID: <1347271179.81.0.646236436369.issue15901@psf.upfronthosting.co.za>


New submission from Simon R:

I've simply tested the example reported in the py3k documentation, and it don't works.

See the site:
http://docs.python.org/py3k/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing.sharedctypes

The program exit with this error:

> python sha.py
Traceback (most recent call last):
  File "sha.py", line 21, in <module>
    s = Array('c', 'hello world', lock=lock)
  File "/usr/lib/python3.2/multiprocessing/sharedctypes.py", line 112, in Array
    obj = RawArray(typecode_or_type, size_or_initializer)
  File "/usr/lib/python3.2/multiprocessing/sharedctypes.py", line 89, in RawArray
    result.__init__(*size_or_initializer)
TypeError: one character string expected


Observe that the following code works correctly with python2!

I'm using python 3.2.3 and gcc 4.7.1 under ArchLinx 
 
Te code is:

http://docs.python.org/py3k/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing.sharedctypes

####################################################################

from multiprocessing import Process, Lock
from multiprocessing.sharedctypes import Value, Array
from ctypes import Structure, c_double

class Point(Structure):
    _fields_ = [('x', c_double), ('y', c_double)]

def modify(n, x, s, A):
    n.value **= 2
    x.value **= 2
    s.value = s.value.upper()
    for a in A:
        a.x **= 2
        a.y **= 2

if __name__ == '__main__':
    lock = Lock()

    n = Value('i', 7)
    x = Value(c_double, 1.0/3.0, lock=False)
    s = Array('c', 'hello world', lock=lock)
    A = Array(Point, [(1.875,-6.25), (-5.75,2.0), (2.375,9.5)], lock=lock)

    p = Process(target=modify, args=(n, x, s, A))
    p.start()
    p.join()

    print((n.value))
    print((x.value))
    print((s.value))
    print([(a.x, a.y) for a in A])

----------
components: ctypes
messages: 170171
nosy: bred
priority: normal
severity: normal
status: open
title: multiprocessing sharedctypes Array don't accept strings
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep 10 14:04:49 2012
From: report at bugs.python.org (Paul Moore)
Date: Mon, 10 Sep 2012 12:04:49 +0000
Subject: [New-bugs-announce] [issue15902] imp.load_module won't accept None
	for the file argument	for a C extension
Message-ID: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za>


New submission from Paul Moore:

imp.load_module appears to have a regression - the file argument is not allowed to be None when loading a C_EXTENSION. The pywin32 post-install script for version 217 calls imp.load_module for a C extension with file=None, so presumably this worked in earlier versions.

Note that apparently pywin32 tip no longer calls load_module in this way, and load_module is marked as deprecated in the documentation, so it is not clear if this issue actually needs fixing.

See #15828 for some background.

----------
components: Library (Lib)
keywords: 3.3regression
messages: 170178
nosy: brett.cannon, georg.brandl, ncoghlan, pmoore
priority: normal
severity: normal
status: open
title: imp.load_module won't accept None for the file argument for a C extension
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 10 14:23:03 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 10 Sep 2012 12:23:03 +0000
Subject: [New-bugs-announce] [issue15903] Make rawiobase_read() read
	directly to bytes object
Message-ID: <1347279783.86.0.217898740398.issue15903@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

Currently rawiobase_read() reads to a bytearray object and then copies the data to a bytes object.

There is a TODO comment saying that the bytes object should be created directly.  The attached patch does that.

----------
files: iobase_read.patch
keywords: patch
messages: 170183
nosy: sbt
priority: normal
severity: normal
status: open
title: Make rawiobase_read() read directly to bytes object
Added file: http://bugs.python.org/file27166/iobase_read.patch

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

From report at bugs.python.org  Mon Sep 10 16:16:38 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 10 Sep 2012 14:16:38 +0000
Subject: [New-bugs-announce] [issue15904] file,
	close() can fail assert on Windows in 2.7
Message-ID: <1347286598.53.0.580767825859.issue15904@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

With Python 2.7 on Windows the following crashes with an assertion:

    >>> import os
    [43042 refs]
    >>> f = open("foobar", "wb")
    [43048 refs]
    >>> os.close(f.fileno())
    [43048 refs]
    >>> f.close()
    <Failed assertion>

A box pops up with

    Program: C:\Repos\cpython-27\PCbuild\python_d.exe
    File: f:\dd\vctools\crt_bld\self_x86\crt\src\close.c
    Line: 48

    Expression: (_osfile(fh) & FOPEN)

Python 3.2 and 3.3 give IOError(EBADF, ...) as expected.

Compare #15261 and #15263.

----------
messages: 170188
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: file,close() can fail assert on Windows in 2.7
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 10 18:09:46 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2012 16:09:46 +0000
Subject: [New-bugs-announce] [issue15905] Copy to fixed size buffer w/o
	check in sys_update_path
Message-ID: <1347293386.49.0.00561600810364.issue15905@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In Python/sysmodule.c the function sys_update_path() uses wcscpy to copy data to a fixed size buffer. The input comes from an external source (argv[0]) and could theoretically be larger than the buffer.

Suggested solution:
Increase the buffer a bit:

    wchar_t argv0copy[sizeof(wchar_t)* (MAXPATHLEN+1)];

and use wcsncpy:

    wcsncpy(argv0copy, argv0, MAXPATHLEN);
    argv0copy[MAXPATHLEN] = L'\0';


CID 486850

----------
components: Interpreter Core
messages: 170200
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Copy to fixed size buffer w/o check in sys_update_path
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 10 18:35:12 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 10 Sep 2012 16:35:12 +0000
Subject: [New-bugs-announce] [issue15906] argparse add_argument() confusing
	behavior when type=str, default=[], action='append'
Message-ID: <1347294912.91.0.997140520288.issue15906@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

Run the following code snippet:

-----snip snip-----
import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--test", dest="test", type=str,
    default=[], action='append')

args = parser.parse_args()

print args.test, repr(args.test)
-----snip snip-----

In Python 3.3 (with the appropriate syntactic changes), args.test is clearly a list.  In Python 2.7 and 3.2, args.test is the string "[]".  I can't tell from reading the docs what the expected value should be, but intuitively, the Python 3.3 behavior makes the most sense, i.e. that args.test is a list, not the string representation of a list!

Removing type=str from add_argument() "fixes" the value, but that doesn't seem right because str is the default type so that should have no effect.

We discovered this when we tried to do args.test.append('foo') and tracebacked because args.test wasn't a list.

Original bug report in Ubuntu: https://launchpad.net/bugs/1048710
but I've tested this with upstream hg head for 2.7, 3.2, and 3.3.  It works in Ubuntu's 3.3rc2 but not in upstream head 3.3rc2+, so from reading Misc/NEWS I think the fix for issue #12776 and issue #11839 might be involved.

----------
messages: 170202
nosy: barry
priority: normal
severity: normal
status: open
title: argparse add_argument() confusing behavior when type=str, default=[], action='append'
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Sep 10 19:00:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 10 Sep 2012 17:00:59 +0000
Subject: [New-bugs-announce] [issue15907] move doctest test-data files into
	a subdirectory of	Lib/test
Message-ID: <1347296459.35.0.660655246065.issue15907@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

doctest currently has 8 "data" files used for testing that are spread across Lib/test (in addition to the main test files test_doctest.py and test_doctest2.py):

doctest_aliases.py
sample_doctest.py
sample_doctest_no_docstrings.py
sample_doctest_no_doctests.py
test_doctest.txt
test_doctest2.txt
test_doctest3.txt
test_doctest4.txt

This issue is to move these files into a common subdirectory of Lib/test (e.g. Lib/test/doctest).  This will simplify the organization of doctest's tests (e.g. by making the supporting files easier to discover) and reduce clutter in the main test directory.

Note that test_zipimport_support (and perhaps also test_pyclbr) will also require changes.

This issue came out of discussions with R. David Murray in the context of working on issue 14649.

----------
components: Library (Lib), Tests
messages: 170204
nosy: cjerdonek, r.david.murray
priority: normal
severity: normal
status: open
title: move doctest test-data files into a subdirectory of Lib/test
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 10 20:39:12 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 10 Sep 2012 18:39:12 +0000
Subject: [New-bugs-announce] [issue15908] SHA1 crashes in 64 bits when the
	string to hash is
Message-ID: <1347302352.79.0.333687005709.issue15908@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

#14888 solves this for MD5, but SHA1 is affected too.

----------
assignee: jcea
messages: 170214
nosy: jcea, pitrou
priority: normal
severity: normal
status: open
title: SHA1 crashes in 64 bits when the string to hash is
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 10 20:56:48 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 10 Sep 2012 18:56:48 +0000
Subject: [New-bugs-announce] [issue15909] test_mmap failure on Windows
	buildbots
Message-ID: <1347303408.84.0.405583449019.issue15909@psf.upfronthosting.co.za>


New submission from Stefan Krah:

All Windows bots have multiple failures in test_mmap:

======================================================================
ERROR: test_entire_file (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_mmap.py", line 19, in setUp
    os.unlink(TESTFN)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_8132_tmp'

======================================================================
ERROR: test_error (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_mmap.py", line 19, in setUp
    os.unlink(TESTFN)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '@test_8132_tmp'


[...]

----------
components: Tests
messages: 170217
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_mmap failure on Windows buildbots
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 10 21:20:56 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 10 Sep 2012 19:20:56 +0000
Subject: [New-bugs-announce] [issue15910] MD5 and SHA1 crash when "updated"
	with strings bigger	than 2**32 bytes
Message-ID: <1347304856.87.0.716554283125.issue15910@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

#14888 and #15908 solve the issue for "hash.new()", but "hash.update()" is failing too.

----------
assignee: jcea
messages: 170219
nosy: jcea, pitrou
priority: normal
severity: normal
status: open
title: MD5 and SHA1 crash when "updated" with strings bigger than 2**32 bytes
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 10 21:30:36 2012
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 10 Sep 2012 19:30:36 +0000
Subject: [New-bugs-announce] [issue15911] Debugging import problems is hard
Message-ID: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

Debugging problems involving the frozen importlib._bootstrap is difficult, because the source for importlib._bootstrap is not available to pdb.  The bootstrap code can be stepped through, but with only function names and line numbers available, not source lines.

The value of having importlib written in Python would be greatly enhanced if it were more like a regular Python module that, eg, pdb could display source lines from.

----------
components: Interpreter Core, Library (Lib)
messages: 170221
nosy: exarkun
priority: normal
severity: normal
status: open
title: Debugging import problems is hard
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 10 21:48:08 2012
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Mon, 10 Sep 2012 19:48:08 +0000
Subject: [New-bugs-announce] [issue15912] Intermittent import failure
Message-ID: <1347306488.32.0.579862468215.issue15912@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

The attached unit test fails with an ImportError... sometimes.  Here's a little blob of shell that seems to make the failure come up more quickly:

while ~/Projects/cpython/3.3/python -m unittest -v test_broken_import; do
    rm -rf test_broken_import;
    rm -rf __pycache__/;
done

An example of the output when I run it:


exarkun at top:/tmp$ while ~/Projects/cpython/3.3/python -m unittest -v test_broken_import_minimal; do rm -rf test_broken_import; rm -rf __pycache__/; done
test_renamedSource (test_broken_import_minimal.BrokenTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.004s

OK
test_renamedSource (test_broken_import_minimal.BrokenTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.005s

OK
test_renamedSource (test_broken_import_minimal.BrokenTests) ... > /tmp/test_broken_import_minimal.py(53)test_renamedSource()
-> print(e)
(Pdb) c
No module named 'twisted_renamed_helper'
ERROR

======================================================================
ERROR: test_renamedSource (test_broken_import_minimal.BrokenTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test_broken_import_minimal.py", line 50, in test_renamedSource
    from twisted_renamed_helper import module
ImportError: No module named 'twisted_renamed_helper'

----------------------------------------------------------------------
Ran 1 test in 0.759s

FAILED (errors=1)

----------
components: Interpreter Core
files: test_broken_import_minimal.py
messages: 170225
nosy: exarkun
priority: normal
severity: normal
status: open
title: Intermittent import failure
versions: Python 3.3
Added file: http://bugs.python.org/file27168/test_broken_import_minimal.py

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

From report at bugs.python.org  Mon Sep 10 23:27:24 2012
From: report at bugs.python.org (Ellery Newcomer)
Date: Mon, 10 Sep 2012 21:27:24 +0000
Subject: [New-bugs-announce] [issue15913] PyBuffer_SizeFromFormat is missing
Message-ID: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za>


New submission from Ellery Newcomer:

this function is listed in the buffer docs and in abstract.h, but there is no implementation anywhere.

----------
components: None
messages: 170239
nosy: ellery.newcomer
priority: normal
severity: normal
status: open
title: PyBuffer_SizeFromFormat is missing
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Sep 10 23:29:48 2012
From: report at bugs.python.org (Sean B. Palmer)
Date: Mon, 10 Sep 2012 21:29:48 +0000
Subject: [New-bugs-announce] [issue15914] multiprocessing.SyncManager
	connection hang
Message-ID: <1347312588.21.0.484965926655.issue15914@psf.upfronthosting.co.za>


New submission from Sean B. Palmer:

create.py:

import multiprocessing
manager = multiprocessing.Manager()
namespace = manager.Namespace()
print("create.py complete")

run.py:

import create
print("run.py complete")

Correct behaviour occurs for create.py:

$ python3 create.py
create.py complete

INCORRECT behaviour occurs for run.py:

$ python3 run.py

No output, because it hangs. On SIGINT:

^CTraceback (most recent call last):
  File "run.py", line 1, in <module>
    import create
  File "[...]/create.py", line 7, in <module>
    test()
  File "[...]/create.py", line 5, in test
    namespace = manager.Namespace()
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/managers.py", line 670, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/managers.py", line 568, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/connection.py", line 175, in Client
    answer_challenge(c, authkey)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/multiprocessing/connection.py", line 412, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
KeyboardInterrupt

$ python3
Python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:25:50) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

This appears to be a duplicate of this *closed* bug:

http://bugs.python.org/issue7474

This was closed because nobody could reproduce the behaviour on Python 3. I have reproduced it, but I don't know how to reopen that bug, so I'm filing this one. The test case in 7474 also fails for me.

----------
messages: 170240
nosy: palmer
priority: normal
severity: normal
status: open
title: multiprocessing.SyncManager connection hang
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep 10 23:54:07 2012
From: report at bugs.python.org (Ellery Newcomer)
Date: Mon, 10 Sep 2012 21:54:07 +0000
Subject: [New-bugs-announce] [issue15915] array.array does not support the
	buffer interface
Message-ID: <1347314047.19.0.593208170998.issue15915@psf.upfronthosting.co.za>


New submission from Ellery Newcomer:

According to http://docs.python.org/library/array.html,

array.array supports the buffer interface; however in python 2.7, PyObject_CheckBuffer says this is not the case.

all is well in python 3.2, though.

----------
files: test.c
messages: 170242
nosy: ellery.newcomer
priority: normal
severity: normal
status: open
title: array.array does not support the buffer interface
versions: Python 2.7
Added file: http://bugs.python.org/file27169/test.c

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

From report at bugs.python.org  Tue Sep 11 01:54:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 10 Sep 2012 23:54:55 +0000
Subject: [New-bugs-announce] [issue15916] change doctest DocTestSuite not to
	raise ValueError if	no docstrings
Message-ID: <1347321295.19.0.66061447718.issue15916@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, calling doctest.DocTestSuite() raises a ValueError if the module passed to it has no docstrings.  This was the subject of issue 14649.

This issue is to discuss and possibly change DocTestSuite's behavior not to raise an exception in that situation.

In the discussion for issue 14649 (in particular with R. David Murray), it was acknowledged that the current behavior probably isn't correct or desirable.  However, treating the behavior as a bug and fixing it in maintenance branches would have been too big of a change.

Thus, if this change is made, it could be slated for the next feature release.

----------
components: Library (Lib)
keywords: easy
messages: 170250
nosy: asvetlov, cjerdonek, r.david.murray
priority: normal
severity: normal
status: open
title: change doctest DocTestSuite not to raise ValueError if no docstrings
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Sep 11 07:13:11 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 11 Sep 2012 05:13:11 +0000
Subject: [New-bugs-announce] [issue15917] hg hook to detect unmerged
	changesets
Message-ID: <1347340391.86.0.248701031918.issue15917@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached Mercurial hook checks that all the changesets in a 3.x branch are merged with either another cset in the same branch or a cset in the following 3.x branch.

This is to detect and prevent situations where people commit something on e.g. 3.2 and push it without merging it with default.

----------
files: checkmerge.py
messages: 170263
nosy: ezio.melotti, georg.brandl, loewis, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: hg hook to detect unmerged changesets
type: enhancement
Added file: http://bugs.python.org/file27171/checkmerge.py

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

From report at bugs.python.org  Tue Sep 11 11:06:17 2012
From: report at bugs.python.org (Vitaly)
Date: Tue, 11 Sep 2012 09:06:17 +0000
Subject: [New-bugs-announce] [issue15918] subprocess.Popen reads
	errpipe_read incorrectly, can result in short read
Message-ID: <1347354377.74.0.358322632323.issue15918@psf.upfronthosting.co.za>


New submission from Vitaly:

subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't loop to read all the data until EOF -- it only loops over EINTR until it gets a single successful os.read() call.  However, since this is a pipe read (not a real file read), the system doesn't guarantee that the blocking read will read everything up to requested read size or EOF, whichever comes first.  So, the single os.read call could return a partial read, and the subsequent un-pickling of the exception would fail/crash.

Sorry, I can't submit a patch as I am merely a Python user, not a Python developer, and it would take me too long to set up and figure out Python build just for this one issue.

----------
components: Library (Lib)
messages: 170279
nosy: vitaly
priority: normal
severity: normal
status: open
title: subprocess.Popen reads errpipe_read incorrectly, can result in short read
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep 11 13:28:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 11 Sep 2012 11:28:20 +0000
Subject: [New-bugs-announce] [issue15919] hg.python.org: log page entries
	don't always link to	revision
Message-ID: <1347362900.6.0.139284928383.issue15919@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

On hg.python.org, it seems like the entries on the "log" page don't
always link to the corresponding revision, for example some of the rows in--

http://hg.python.org/cpython/shortlog/1d9e89f6abec

This seems to happen whenever the revision description begins with
text that results in a link to something else (e.g. an issue number).  See, for example, the row for--

"#15886: remove redundant phrase"

In contrast, the "graph" page seems always to link to the revision:

http://hg.python.org/cpython/graph

Related to this, if the description field contains text that results
in a link to something else, then the UI doesn't make a distinction
between the portion of the description that links to the revision and
the portion that links to the something else.

For example, with description text "Fix for fcc629208842", "Fix for"
links to the revision for the log entry, but "fcc629208842" links to
the named revision, and there is no separation or visual indicator
that the two portions of text link to different things.

It might be better if the revision link was separate from the
description text.  That would be one way to address both of the issues
above.

(This was originally posted to python-dev here:
http://mail.python.org/pipermail/python-dev/2012-September/121635.html )

----------
messages: 170290
nosy: cjerdonek, ezio.melotti, pitrou
priority: normal
severity: normal
status: open
title: hg.python.org: log page entries don't always link to revision

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

From report at bugs.python.org  Tue Sep 11 14:07:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 11 Sep 2012 12:07:30 +0000
Subject: [New-bugs-announce] [issue15920] make howto/regex.rst doctests pass
Message-ID: <1347365250.51.0.50908200461.issue15920@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to make the doctests in howto/regex.rst pass using vanilla doctest.  After this issue, 10 out of the 17 HOWTO's will pass with vanilla doctest.

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-doctest-howto-regex-1.patch
keywords: patch
messages: 170295
nosy: cjerdonek, docs at python, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: make howto/regex.rst doctests pass
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27173/issue-doctest-howto-regex-1.patch

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

From report at bugs.python.org  Tue Sep 11 14:46:34 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Sep 2012 12:46:34 +0000
Subject: [New-bugs-announce] [issue15921] select module uses uninitialized
	value "tv.tv_usec"
Message-ID: <1347367594.05.0.129732037388.issue15921@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Starting with Python 3.3 the select module access the uninitialized tv.tv_usec member of a timeval struct. I don't see the point of initializing the local variable long tv_usec from tv.tv_usec. The comment above the code states that long tv_usec is required as a workaround for Mac OS X.

http://hg.python.org/cpython/file/4754c4a710e6/Modules/selectmodule.c#l242

Coverity message:
CID 719694: Uninitialized scalar variable (UNINIT)At (5): Using uninitialized value "tv.tv_usec".
 242        long tv_usec = tv.tv_usec;
 243        if (_PyTime_ObjectToTimeval(tout, &tv.tv_sec, &tv_usec) == -1)
 244            return NULL;
 245        tv.tv_usec = tv_usec;

Suggested fix:
change line 242 to "long tv_usec;"

----------
keywords: 3.3regression
messages: 170299
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: select module uses uninitialized value "tv.tv_usec"
type: resource usage
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep 11 15:28:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 11 Sep 2012 13:28:23 +0000
Subject: [New-bugs-announce] [issue15922] make howto/urllib2.rst doctests
	pass
Message-ID: <1347370103.61.0.784697754485.issue15922@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to make the doctests in howto/urllib2.rst pass using vanilla doctest.

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-doctest-howto-urllib-1.patch
keywords: easy, patch
messages: 170305
nosy: cjerdonek, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: make howto/urllib2.rst doctests pass
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27174/issue-doctest-howto-urllib-1.patch

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

From report at bugs.python.org  Tue Sep 11 23:13:59 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 11 Sep 2012 21:13:59 +0000
Subject: [New-bugs-announce] [issue15923] Building from a fresh clone breaks
	on Parser/asdl_c.py
Message-ID: <1347398039.31.0.775610002592.issue15923@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

After a fresh clone, configure && make fails due to a fairly obvious bug in the code.  Note that if you `hg revert --all`, configure && make will succeed, probably because the timestamps get updated enough to fool make.

@resist[~/projects/python:1043]% hg clone ssh://hg at hg.python.org/releasing/3.3.0
[...]
@resist[~/projects/python:1044]% cd 3.3.0/
@resist[~/projects/python/3.3.0:1045]% ./configure && make
[...]

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl
Error visitingSum([Constructor(Load, []), Constructor(Store, []), Constructor(Del, []), Constructor(AugLoad, []), Constructor(AugStore, []), Constructor(Param, [])], [])
not all arguments converted during string formatting
Traceback (most recent call last):
  File "/home/barry/projects/python/3.3.0/Parser/asdl.py", line 309, in visit
    meth(object, *args)
  File "./Parser/asdl_c.py", line 1043, in visitSum
    self.simpleSum(sum, name)
  File "./Parser/asdl_c.py", line 1067, in simpleSum
    self.emit("default:" % name, 2)
TypeError: not all arguments converted during string formatting
make: *** [Python/Python-ast.c] Error 1

----------
messages: 170344
nosy: barry, georg.brandl, loewis
priority: normal
severity: normal
status: open
title: Building from a fresh clone breaks on Parser/asdl_c.py
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 12 00:26:38 2012
From: report at bugs.python.org (Joshua Landau)
Date: Tue, 11 Sep 2012 22:26:38 +0000
Subject: [New-bugs-announce] [issue15924] 404 link on Python about page
Message-ID: <1347402398.06.0.816784008055.issue15924@psf.upfronthosting.co.za>


New submission from Joshua Landau:

http://www.python.org/about/ section "Python plays well with others", last paragraph, link "extension modules" links to http://www.python.org/doc/ext/intro.html, a 404 page.

http://www.python.org/doc/ext/ redirects to http://docs.python.org/extending/

----------
components: None
messages: 170345
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: 404 link on Python about page

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

From report at bugs.python.org  Wed Sep 12 02:37:45 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 12 Sep 2012 00:37:45 +0000
Subject: [New-bugs-announce] [issue15925] email.utils.parsedate(),
	email.utils.parsedate_tz() and
	email.utils.parsedate_to_datetime()	should return None when
	date cannot be parsed
Message-ID: <1347410265.94.0.383870526813.issue15925@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Documentation (in Python 3.3) says that None is returned when date cannot be parsed.

In Python 3.2:

>>> email.utils.parsedate("0")
>>> email.utils.parsedate_tz("0")
>>>

In Python 3.3:

>>> email.utils.parsedate("0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/email/utils.py", line 232, in parsedate
    return _parsedate(data)
  File "/usr/lib64/python3.3/email/_parseaddr.py", line 172, in parsedate
    t = parsedate_tz(data)
  File "/usr/lib64/python3.3/email/_parseaddr.py", line 51, in parsedate_tz
    if res[9] is None:
TypeError: 'NoneType' object is not subscriptable
>>> email.utils.parsedate_tz("0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/email/utils.py", line 238, in parsedate_tz
    return _parsedate_tz(data)
  File "/usr/lib64/python3.3/email/_parseaddr.py", line 51, in parsedate_tz
    if res[9] is None:
TypeError: 'NoneType' object is not subscriptable
>>> email.utils.parsedate_to_datetime("0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/email/utils.py", line 243, in parsedate_to_datetime
    *dtuple, tz = __parsedate_tz(data)
TypeError: 'NoneType' object is not iterable
>>>

----------
messages: 170347
nosy: Arfrever
priority: release blocker
severity: normal
status: open
title: email.utils.parsedate(), email.utils.parsedate_tz() and email.utils.parsedate_to_datetime() should return None when date cannot be parsed
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 12 05:13:01 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 12 Sep 2012 03:13:01 +0000
Subject: [New-bugs-announce] [issue15926] Segmentation fault after multiple
	reinitializations
Message-ID: <1347419581.97.0.0354883385349.issue15926@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

#include <Python.h>
#include <stdlib.h>
int main()
{
    int i;
    for (i = 0; i < 100; i++) {
        printf("%d\n", i);
        Py_Initialize();
        Py_Finalize();
    }
    return 0;
}

The above code succeeds with Python 3.2, but causes segmentation fault with Python 3.3:

$ ./reinitializations
0
1
2
3
4
5
6
7
8
9
Segmentation fault
$

----------
keywords: 3.3regression
messages: 170349
nosy: Arfrever
priority: high
severity: normal
status: open
title: Segmentation fault after multiple reinitializations
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 12 06:49:50 2012
From: report at bugs.python.org (Kalon Mills)
Date: Wed, 12 Sep 2012 04:49:50 +0000
Subject: [New-bugs-announce] [issue15927] cvs.reader does not support
	escaped newline when	quoting=cvs.QUOTE_NONE
Message-ID: <1347425390.54.0.862014726204.issue15927@psf.upfronthosting.co.za>


New submission from Kalon Mills:

cvs.reader improperly prematurely ends row parsing when parsing a row with an escaped newline but with quoting turned off.  cvs.reader properly handles quoted newlines.  cvs.writer properly handles writing escaped unquoted newlines so only the reader has an issue.

Given a dialect with escapechar='\\', quoting=csv.QUOTE_NONE, lineterminator='\n':

writer.writerow(['one\nelement']) will correctly write 'one\\\nelement\n'

however pass that back into a reader and it will produce two rows: ['one\n'] ['element']

I would expect the reader to parse it correctly and return the original value of ['one\nelement']
 
I've attached a test script that exhibits the improper behavior.  It uses a dialect to set an escapechar and disable quoting.

----------
components: None
files: test_csv.py
messages: 170352
nosy: kalaxy
priority: normal
severity: normal
status: open
title: cvs.reader does not support escaped newline when quoting=cvs.QUOTE_NONE
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27177/test_csv.py

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

From report at bugs.python.org  Wed Sep 12 07:45:02 2012
From: report at bugs.python.org (zhang kai)
Date: Wed, 12 Sep 2012 05:45:02 +0000
Subject: [New-bugs-announce] [issue15928] Open url with proxy causes
	TypeError
Message-ID: <1347428702.03.0.0537807562119.issue15928@psf.upfronthosting.co.za>


New submission from zhang kai:

Here is the code which causes this bug:
 proxy_handler = urllib2.ProxyHandler({'https': proxy})
 opener = urllib2.build_opener(proxy_handler)
 f = opener.open(url+'?'+params)

Here are the traceback information:
Traceback (most recent call last):
  File "proxy.py", line 65, in <module>
    main()
  File "proxy.py", line 62, in main
    print proxy_manager.get_proxy()
  File "proxy.py", line 45, in get_proxy
    make_request(TEST_URL, proxy=one["proxy_server"])
  File "proxy.py", line 27, in make_request
    f = opener.open(url+'?'+params)
  File "/usr/lib/python2.7/urllib2.py", line 400, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 418, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 378, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1215, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1174, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  File "/usr/lib/python2.7/httplib.py", line 958, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python2.7/httplib.py", line 992, in _send_request
    self.endheaders(body)
  File "/usr/lib/python2.7/httplib.py", line 954, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 814, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 776, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1160, in connect
    self._tunnel()
  File "/usr/lib/python2.7/httplib.py", line 748, in _tunnel
    line = response.fp.readline(_MAXLINE + 1)
TypeError: readline() takes exactly 1 argument (2 given)

----------
components: Library (Lib)
messages: 170354
nosy: zhang.kai
priority: normal
severity: normal
status: open
title: Open url with proxy causes TypeError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 12 11:00:57 2012
From: report at bugs.python.org (Julien Castets)
Date: Wed, 12 Sep 2012 09:00:57 +0000
Subject: [New-bugs-announce] [issue15929] argparse non alphanum characters
	replacement
Message-ID: <1347440457.56.0.780058714044.issue15929@psf.upfronthosting.co.za>


New submission from Julien Castets:

argparse.add_argument replaces dashes with underscores. If an argument contains another non alphanum character, accessing to it will result to a syntax error.

#! /usr/bin/env python

import argparse

if __name__ == '__main__':
    argParser = argparse.ArgumentParser()
    argParser.add_argument('--foo+', action='store_true')
    arguments = argParser.parse_args()

    print 'getattr foo+: %s' % getattr(arguments, 'foo+') # ok
    print arguments.foo+ # syntax error

The patch replaces every non alnum character with an underscore.

----------
components: None
files: argparse.patch
keywords: patch
messages: 170361
nosy: brmzkw
priority: normal
severity: normal
status: open
title: argparse non alphanum characters replacement
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27178/argparse.patch

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

From report at bugs.python.org  Wed Sep 12 14:37:02 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 12 Sep 2012 12:37:02 +0000
Subject: [New-bugs-announce] [issue15930] buffer overrun in
	wcstombs_errorpos()
Message-ID: <1347453422.44.0.810518034926.issue15930@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Coverity has found a buffer overrun in wcstombs_errorpos() defined at 
http://hg.python.org/cpython/file/25e41fdc4e60/Objects/unicodeobject.c#l3237

Message:
CID 719672: Out-of-bounds access (OVERRUN)At (2): Overrunning array "buf" of 2 4-byte elements by passing it to a function which accesses it at element index 15 (byte offset 60) using argument "16UL". 

On a 64bit Linux system SIZE_OF_WCHAR_T is 4 and MB_LEN_MAX 16. In this constellation buf is 8 bytes long (wchar_t[2]) but outbuf has a size of 16 bytes. This causes a buffer overrun in wcstombs(outbuf, buf, sizeof(outbuf)).

----------
keywords: 3.3regression
messages: 170373
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: buffer overrun in wcstombs_errorpos()
type: resource usage
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 12 17:32:22 2012
From: report at bugs.python.org (Gabor Kovacs)
Date: Wed, 12 Sep 2012 15:32:22 +0000
Subject: [New-bugs-announce] [issue15931] inspect.findsource fails after
	directory change
Message-ID: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za>


New submission from Gabor Kovacs:

The attached script works in 2.6(.4) but not in 2.7(.3); the script cannot locate its own source code if invoked by relative path and work directory has changed. If line 8 uncommented, everything is fine due to caching. 

I think this is related to issue #4050 changes in inspect.py. 

~ kgabor$ python ./instest.py

None ./instest.py
Traceback (most recent call last):
  File "./instest.py", line 10, in <module>
    print inspect.getsourcefile(A), inspect.getfile(A),inspect.findsource(A)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 529, in findsource
    raise IOError('source code not available')
IOError: source code not available

~ kgabor$ pwd
/Users/kgabor

~ kgabor$ python /Users/kgabor/instest.py

/Users/kgabor/instest.py /Users/kgabor/instest.py (['import inspect\n', 'import os\n', '\n', 'class A:\n', ' def __init__(self):\n', '  self.a=1\n', '\n', '#print inspect.getsourcefile(A),inspect.getfile(A),inspect.findsource(A)\n', "os.chdir('/')\n", 'print inspect.getsourcefile(A), inspect.getfile(A),inspect.findsource(A)\n'], 3)

----------
components: Library (Lib)
files: instest.py
messages: 170389
nosy: kgabor79
priority: normal
severity: normal
status: open
title: inspect.findsource fails after directory change
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file27179/instest.py

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

From report at bugs.python.org  Wed Sep 12 17:56:31 2012
From: report at bugs.python.org (berdario)
Date: Wed, 12 Sep 2012 15:56:31 +0000
Subject: [New-bugs-announce] [issue15932] files in the csv documentation's
	examples are not closed
Message-ID: <1347465391.09.0.1751065548.issue15932@psf.upfronthosting.co.za>


New submission from berdario:

I changed the examples to use the with statement

----------
assignee: docs at python
components: Documentation
files: doc.diff
keywords: patch
messages: 170394
nosy: berdario, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: files in the csv documentation's examples are not closed
Added file: http://bugs.python.org/file27181/doc.diff

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

From report at bugs.python.org  Wed Sep 12 18:20:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Sep 2012 16:20:16 +0000
Subject: [New-bugs-announce] [issue15933] flaky test in test_datetime
Message-ID: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Seen on a buildbot:

======================================================================
FAIL: test_today (test.datetimetester.TestSubclassDateTime_Fast)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/datetimetester.py", line 1009, in test_today
    abs(todayagain - today) < timedelta(seconds=0.5))
AssertionError: False is not true

http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.2/builds/1341/steps/test/logs/stdio

----------
components: Tests
keywords: easy
messages: 170401
nosy: belopolsky, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: flaky test in test_datetime
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 12 18:21:35 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Sep 2012 16:21:35 +0000
Subject: [New-bugs-announce] [issue15934] flaky test in test_ftplib
Message-ID: <1347466895.7.0.169569796798.issue15934@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Seen on a buildbot:

======================================================================
ERROR: test_storlines (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_ftplib.py", line 583, in test_storlines
    self.client.storlines('stor', f)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ftplib.py", line 811, in storlines
    conn.unwrap()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ssl.py", line 495, in unwrap
    s = self._sslobj.shutdown()
socket.timeout: The read operation timed out

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/4429/steps/test/logs/stdio

----------
components: Tests
messages: 170402
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: flaky test in test_ftplib
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 12 23:26:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 12 Sep 2012 21:26:15 +0000
Subject: [New-bugs-announce] [issue15935] clarify argparse docs re:
	add_argument() type and	default arguments
Message-ID: <1347485175.79.0.860808168134.issue15935@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to clarify in the documentation the argparse behavior for which tests were added in issue 15906.

The behavior involves when the type callable should be applied to default arguments.  See, for example, the following comment for what roughly needs to be added:

http://bugs.python.org/issue15906#msg170404

I will provide a patch.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 170421
nosy: barry, bethard, cjerdonek, docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: clarify argparse docs re: add_argument() type and default arguments
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 13 00:09:02 2012
From: report at bugs.python.org (Jacek Bzdak)
Date: Wed, 12 Sep 2012 22:09:02 +0000
Subject: [New-bugs-announce] [issue15936] Add link from os.urandom to
	random.SystemRandom
Message-ID: <1347487742.57.0.57747338883.issue15936@psf.upfronthosting.co.za>


New submission from Jacek Bzdak:

It would be great if one sentence was added to os.urandom description: 
"For easy to use interface to system randomness please see random.SystemRandom class". 

The reason for this change is that many references quote only os.urandom as a cryptographically strong randomeness source in python, and for some people it might be not obvious that there already exists such easy to use api to use cryptographically strong randomness (that is random.SystemRandom class). It would be good to point such people to right class. 

Myself for example spent last hour trying to create makeshift Random subclass that uses os.urandom as it's randomness source.

----------
assignee: docs at python
components: Documentation
messages: 170423
nosy: Jacek.Bzdak, docs at python
priority: normal
severity: normal
status: open
title: Add link from os.urandom to random.SystemRandom
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 13 10:54:51 2012
From: report at bugs.python.org (Cioroianu Nicolin)
Date: Thu, 13 Sep 2012 08:54:51 +0000
Subject: [New-bugs-announce] [issue15937] Assertion
	failure	(C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas,
	line 1175).
Message-ID: <1347526491.38.0.848154883344.issue15937@psf.upfronthosting.co.za>


New submission from Cioroianu Nicolin:

Hello,

Running the following script frame:

import re
#import modulefinder

#m=str(raw_input("Get a string:"))
m= "IT_SetBusParameters(param1,param2,param3,param4,param5,param6)"
if m:
    cnt=m.count(',')
    if cnt:
        nr=0
        s=re.split(',',m)
        for nr in cnt:
            print s[i]
            i=i+1
        #PendingDeprecationWarning
        else:
            return
    print "finished"

I have used PyScripter as running ide.


I received the following failure:
Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175).

Exception class: EAssertionFailed
Exception message: Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175).
Exception address: 00908B3E
------------------------------------------------------------------------------
PyScripter version : 2.5.3.0 x86
Python DLL : python27.dll
Python Engine : peRemote
------------------------------------------------------------------------------
Stack list, generated 13.09.2012 09:45:16
(00507B39){PyScripter.exe} [00908B39] cPyRemoteDebugger.TPyRemoteInterpreter.ShutDownServer (Line 1175, "cPyRemoteDebugger.pas" + 41) + $1B
(00006609){PyScripter.exe} [00407609] System. at Assert + $25
(00507B39){PyScripter.exe} [00908B39] cPyRemoteDebugger.TPyRemoteInterpreter.ShutDownServer (Line 1175, "cPyRemoteDebugger.pas" + 41) + $1B
(00505F0D){PyScripter.exe} [00906F0D] cPyRemoteDebugger.TPyRemoteInterpreter.ReInitialize (Line 831, "cPyRemoteDebugger.pas" + 32) + $2
(003A45C5){PyScripter.exe} [007A55C5] cPyBaseDebugger.TPythonControl.PrepareRun (Line 871, "cPyBaseDebugger.pas" + 18) + $4
(003A469D){PyScripter.exe} [007A569D] cPyBaseDebugger.TPythonControl.Run (Line 897, "cPyBaseDebugger.pas" + 5) + $3
(00516455){PyScripter.exe} [00917455] frmPyIDEMain.TPyIDEMainForm.actRunExecute (Line 1901, "frmPyIDEMain.pas" + 8) + $A
(0005A8E3){PyScripter.exe} [0045B8E3] System.Classes.TBasicAction.Execute + $F
(000895F5){PyScripter.exe} [0048A5F5] Vcl.ActnList.TContainedAction.Execute + $31
(0008A350){PyScripter.exe} [0048B350] Vcl.ActnList.TCustomAction.Execute + $50
(0005A7A7){PyScripter.exe} [0045B7A7] System.Classes.TBasicActionLink.Execute + $13
(0020B1C9){PyScripter.exe} [0060C1C9] TB2Item.TTBCustomItem.Click (Line 1474, "TB2Item.pas" + 23) + $7
(0022FBA8){PyScripter.exe} [00630BA8] SpTBXItem.TSpTBXCustomItem.Click (Line 4400, "SpTBXItem.pas" + 2) + $2
(0020B0C2){PyScripter.exe} [0060C0C2] TB2Item.TTBCustomItem.ClickWndProc (Line 1423, "TB2Item.pas" + 29) + $5
(0005B5D8){PyScripter.exe} [0045C5D8] System.Classes.StdWndProc + $14
(001550C7){PyScripter.exe} [005560C7] Vcl.Forms.TApplication.ProcessMessage + $F3
(0015510A){PyScripter.exe} [0055610A] Vcl.Forms.TApplication.HandleMessage + $A
(00155449){PyScripter.exe} [00556449] Vcl.Forms.TApplication.Run + $C9
(00564A59){PyScripter.exe} [00965A59] PyScripter.PyScripter (Line 136, "" + 14) + $2
------------------------------------------------------------------------------
System   : Windows 7 Professional, Version: 6.1, Build: 1DB1, "Service Pack 1"
Processor: Intel,        Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2490 MHz MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42 64 bits DEP
Memory: 8142; free 5122
Display  : 1600x900 pixels, 32 bpp
------------------------------------------------------------------------------
List of loaded modules:
[00400000] C:\Program Files (x86)\PyScripter\PyScripter.exe
           2.5.3.0 - 2.5.3.0
[05BC0000] C:\Python27\DLLs\_socket.pyd
<1E1D0000> (no module version info)
[10000000] C:\Python27\DLLs\_ssl.pyd
           (no module version info)
[1D110000] C:\Python27\DLLs\select.pyd
           (no module version info)
[1D120000] C:\Python27\DLLs\unicodedata.pyd
           (no module version info)
[1E000000] C:\Windows\system32\python27.dll
           2.7.150.1013 - 2.7
           Python Core
[1E7A0000] C:\Windows\system32\pywintypes27.dll
           2.7.217.0 - 2.7.217.0
[1EA10000] C:\Python27\lib\site-packages\win32\win32file.pyd
           2.7.217.0 - 2.7.217.0
[1EB90000] C:\Python27\lib\site-packages\win32\win32pipe.pyd
           2.7.217.0 - 2.7.217.0
[65DF0000] C:\Windows\System32\itircl.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Microsoft? InfoTech IR Local DLL
[65E20000] C:\Windows\system32\hhctrl.ocx
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft? HTML Help Control
[66320000] C:\Windows\System32\itss.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft? InfoTech Storage System Library
[66710000] C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17825_none_72d273598668a06b\gdiplus.dll
           6.1.7601.17825 - 6.1.7601.17825 (win7sp1_gdr.120420-1503)
           Microsoft GDI+
[668E0000] C:\Windows\system32\NetworkExplorer.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Network Explorer
[66C20000] C:\Windows\system32\WMVCore.DLL
           12.0.7601.17514 - 12.0.7601.17514 (win7sp1_rtm.101119-1850)
           Windows Media Playback/Authoring DLL
[66E90000] C:\Windows\system32\wpdshext.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Portable Devices Shell Extension
[670D0000] C:\Windows\system32\LINKINFO.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Volume Tracking
[671B0000] C:\Windows\System32\shdocvw.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Shell Doc Object and Control Library
[67210000] C:\Windows\system32\EhStorAPI.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Enhanced Storage API
[67240000] C:\Windows\system32\audiodev.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Portable Media Devices Shell Extension
[67280000] C:\Windows\system32\PortableDeviceApi.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Portable Device API Components
[67310000] C:\Windows\system32\ntshrui.dll
           6.1.7601.17755 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Shell extensions for sharing
[67380000] C:\Windows\system32\WMASF.DLL
           12.0.7600.16385 - 12.0.7600.16385 (win7_rtm.090713-1255)
           Windows Media ASF DLL
[673C0000] C:\Windows\System32\DAVHLPR.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           DAV Helper DLL
[673D0000] C:\Windows\System32\davclnt.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Web DAV Client DLL
[673F0000] C:\Windows\system32\EhStorShell.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Enhanced Storage Shell Extension DLL
[67430000] C:\Windows\System32\ntlanman.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft? Lan Manager
[67450000] C:\Windows\System32\drprov.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft Remote Desktop Session Host Server Network Provider
[67460000] C:\Windows\system32\IconCodecService.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Converts a PNG part of the icon to a legacy bmp icon
[68130000] C:\Windows\system32\slc.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Software Licensing Client Dll
[68140000] C:\Windows\system32\olepro32.dll
           6.1.7601.17514 - 6.1.7601.17514
[686F0000] C:\Windows\SysWOW64\mshtml.dll
           8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255)
           Microsoft (R) HTML Viewer
[68D50000] C:\Windows\system32\DUI70.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows DirectUI Engine
[69190000] C:\Windows\SysWOW64\ATL.DLL
           3.5.2284.0 - 3.05.2284
           ATL Module for Windows XP (Unicode)
[691B0000] C:\Windows\SysWOW64\msls31.dll
           3.10.349.0 - 3.10.349.0
           Microsoft Line Services library file
[691E0000] C:\Windows\system32\explorerframe.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           ExplorerFrame
[69410000] C:\Windows\system32\WindowsCodecs.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Microsoft Windows Codecs Library
[6C8C0000] C:\Windows\SysWOW64\pngfilt.dll
           8.0.7600.16385 - 8.00.7600.16385 (win7_rtm.090713-1255)
           IE PNG plugin image decoder
[6C910000] C:\Windows\system32\MLANG.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Multi Language Support DLL
[6D090000] C:\Windows\SysWOW64\ieframe.dll
           8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255)
           Internet Browser
[6E3F0000] C:\Windows\system32\ImgUtil.dll
           8.0.7601.17514 - 8.00.7601.17514 (win7sp1_rtm.101119-1850)
           IE plugin image decoder support DLL
[6E400000] C:\Windows\system32\DUser.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows DirectUser Engine
[70580000] C:\Windows\System32\netshell.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Network Connections Shell
[70A60000] C:\Windows\System32\msxml6.dll
           6.30.7601.17857 - 6.30.7601.17857
           MSXML 6.0 SP3
[71740000] C:\Windows\system32\msimtf.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Active IMM Server DLL
[71750000] C:\Windows\system32\xmllite.dll
           1.3.1001.0 - 1.3.1001.0
           Microsoft XmlLite Library
[71960000] C:\Program Files (x86)\Internet Explorer\ieproxy.dll
           8.0.7601.17874 - 8.00.7601.17874 (win7sp1_gdr.120626-1620)
           IE ActiveX Interface Marshaling Library
[71AC0000] C:\Windows\system32\browcli.dll
           6.1.7601.17887 - 6.1.7601.17887 (win7sp1_gdr.120704-0720)
           Browser Service Client DLL
[71AD0000] C:\Windows\system32\dfscli.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows NT Distributed File System Client DLL
[71AE0000] C:\Windows\SysWOW64\fdWNet.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Function Discovery WNet Provider Dll
[71AF0000] C:\Windows\System32\wcnapi.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Connect Now - API Helper DLL
[71B10000] C:\Windows\System32\fdwcn.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Connect Now - Config Function Discovery Provider DLL
[71B30000] C:\Windows\SysWOW64\FunDisc.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Function Discovery Dll
[71B60000] C:\Windows\system32\SearchFolder.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           SearchFolder
[71C00000] C:\Windows\SysWOW64\actxprxy.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           ActiveX Interface Marshaling Library
[71C50000] C:\Windows\System32\StructuredQuery.dll
           7.0.7601.17514 - 7.00.7601.17514 (win7sp1_rtm.101119-1850)
           Structured Query
[71CB0000] C:\Program Files (x86)\Common Files\microsoft shared\ink\tiptsf.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Tablet PC Input Panel Text Services Framework
[722A0000] C:\Windows\SysWOW64\fdproxy.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Function Discovery Proxy Dll
[722B0000] C:\Windows\System32\npmproxy.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Network List Manager Proxy
[72380000] C:\Windows\SysWOW64\thumbcache.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft Thumbnail Cache
[72480000] C:\Windows\system32\RICHED20.DLL
           5.31.23.1230 - 5.31.23.1230
           Rich Text Edit Control, v3.1
[72500000] C:\Windows\system32\msimg32.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           GDIEXT Client DLL
[72810000] C:\Windows\system32\dtsh.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Detection and Sharing Status API
[729F0000] C:\Windows\system32\FirewallAPI.dll
           6.1.7600.16385 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Windows Firewall API
[72AB0000] C:\Windows\system32\SXS.DLL
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Fusion 2.5
[72B20000] C:\Windows\system32\NTDSAPI.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Active Directory Domain Services API
[72B40000] C:\Windows\system32\wbem\fastprox.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           WMI Custom Marshaller
[72D20000] C:\Windows\system32\wbem\wbemsvc.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           WMI
[73070000] C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
           6.10.7601.17514 - 6.10 (win7_rtm.090713-1255)
           User Experience Controls Library
[73470000] C:\Windows\system32\NetworkItemFactory.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           NetworkItem Factory
[73630000] C:\Windows\System32\Secur32.dll
           6.1.7601.17856 - 6.1.7601.17856 (win7sp1_gdr.120601-1505)
           Security Support Provider Interface
[73640000] C:\Windows\system32\dwmapi.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft Desktop Window Manager API
[73660000] C:\Windows\system32\sfc_os.DLL
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows File Protection
[73670000] C:\Windows\system32\sfc.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows File Protection
[736B0000] C:\Windows\system32\uxtheme.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft UxTheme Library
[73950000] C:\Windows\system32\Userenv.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Userenv
[73AA0000] C:\Windows\system32\WINSTA.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Winstation Library
[73B30000] C:\Windows\System32\wship6.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Winsock2 Helper DLL (TL/IPv6)
[73B70000] C:\Windows\system32\RpcRtRemote.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Remote RPC Extension
[73B80000] C:\Windows\system32\rsaenh.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft Enhanced Cryptographic Provider
[73BC0000] C:\Windows\system32\CRYPTSP.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Cryptographic Service Provider API
[73BE0000] C:\Windows\system32\wbemcomn.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           WMI
[73C40000] C:\Windows\system32\wbem\wbemprox.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           WMI
[73CF0000] C:\Windows\system32\PROPSYS.dll
           7.0.7601.17514 - 7.00.7600.16385 (win7_rtm.090713-1255)
           Microsoft Property System
[73E30000] C:\Windows\system32\oleacc.dll
           7.0.0.0 - 7.0.0.0 (win7sp1_gdr.110826-1504)
           Active Accessibility Core Component
[73E70000] C:\Windows\system32\winspool.drv
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Spooler Driver
[73ED0000] C:\Windows\system32\wtsapi32.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Windows Remote Desktop Session Host Server SDK APIs
[73EE0000] C:\Windows\system32\mpr.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Multiple Provider Router DLL
[73F00000] C:\Windows\system32\winmm.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           MCI API DLL
[73F40000] C:\Windows\system32\cscapi.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Offline Files Win32 API
[73F50000] C:\Windows\system32\rasadhlp.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Remote Access AutoDial Helper
[73F60000] C:\Windows\System32\fwpuclnt.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           FWP/IPsec User-Mode API
[73FA0000] C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
           9.0.30729.6161 - 9.00.30729.6161
           Microsoft? C Runtime Library
[740E0000] C:\Windows\system32\ntmarta.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows NT MARTA provider
[74370000] C:\Windows\system32\version.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Version Checking and File Installation Libraries
[743C0000] C:\Windows\System32\nlaapi.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Network Location Awareness 2
[743D0000] C:\Windows\system32\wkscli.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Workstation Service Client DLL
[743E0000] C:\Windows\system32\srvcli.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Server Service Client DLL
[74400000] C:\Windows\system32\netutils.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Net Win32 API Helpers DLL
[74410000] C:\Windows\system32\MSWSOCK.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft Windows Sockets 2.0 Service Provider
[74450000] C:\Windows\system32\profapi.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           User Profile Basic API
[744F0000] C:\Windows\system32\DNSAPI.dll
           6.1.7601.17570 - 6.1.7600.16385 (win7_rtm.090713-1255)
           DNS Client API DLL
[748E0000] C:\Windows\system32\WSOCK32.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Socket 32-Bit DLL
[749F0000] C:\Windows\system32\NETAPI32.DLL
           6.1.7601.17887 - 6.1.7601.17887 (win7sp1_gdr.120704-0720)
           Net Win32 API DLL
[74A10000] C:\Windows\System32\wshtcpip.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Winsock2 Helper DLL (TL/IPv4)
[74A80000] C:\Windows\system32\apphelp.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Application Compatibility Client Library
[74AD0000] C:\Windows\system32\WINNSI.DLL
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Network Store Information RPC interface
[74AE0000] C:\Windows\system32\IPHLPAPI.DLL
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           IP Helper API
[74CB0000] C:\Windows\syswow64\CRYPTBASE.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Base cryptographic API DLL
[74CC0000] C:\Windows\syswow64\SspiCli.dll
           6.1.7601.17856 - 6.1.7601.17856 (win7sp1_gdr.120601-1505)
           Security Support Provider Interface
[74D20000] C:\Windows\syswow64\msvcrt.dll
           7.0.7601.17744 - 7.0.7601.17744 (win7sp1_gdr.111215-1535)
           Windows NT CRT DLL
[74DD0000] C:\Windows\syswow64\RPCRT4.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Remote Procedure Call Runtime
[74EC0000] C:\Windows\syswow64\DEVOBJ.dll
           6.1.7601.17621 - 6.1.7601.17621 (win7sp1_gdr.110523-2108)
           Device Information Set DLL
[74F10000] C:\Windows\syswow64\ole32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Microsoft OLE for Windows
[75070000] C:\Windows\system32\IMM32.DLL
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Multi-User Windows IMM32 API Client DLL
[75160000] C:\Windows\syswow64\LPK.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Language Pack
[75170000] C:\Windows\syswow64\WLDAP32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Win32 LDAP API DLL
[751C0000] C:\Windows\syswow64\PSAPI.DLL
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Process Status Helper
[751D0000] C:\Windows\syswow64\USER32.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Multi-User Windows USER API Client DLL
[752D0000] C:\Windows\syswow64\WINTRUST.dll
           6.1.7601.17787 - 6.1.7601.17787 (win7sp1_gdr.120229-1502)
           Microsoft Trust Verification APIs
[75300000] C:\Windows\syswow64\GDI32.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           GDI Client DLL
[753F0000] C:\Windows\syswow64\CFGMGR32.dll
           6.1.7601.17621 - 6.1.7601.17621 (win7sp1_gdr.110523-2108)
           Configuration Manager DLL
[75420000] C:\Windows\syswow64\CLBCatQ.DLL
           2001.12.8530.16385 - 2001.12.8530.16385 (win7_rtm.090713-1255)
           COM+ Configuration Catalog
[754B0000] C:\Windows\SysWOW64\sechost.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Host for SCM/SDDL/LSA Lookup APIs
[754D0000] C:\Windows\syswow64\oleaut32.dll
           6.1.7601.17676 - 6.1.7601.17676
[75560000] C:\Windows\syswow64\kernel32.dll
           6.1.7601.17651 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows NT BASE API Client DLL
[75670000] C:\Windows\syswow64\NSI.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           NSI User-mode interface DLL
[75680000] C:\Windows\syswow64\SHLWAPI.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Shell Light-weight Utility Library
[756E0000] C:\Windows\syswow64\SETUPAPI.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Setup API
[75880000] C:\Windows\syswow64\CRYPT32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Crypto API32
[759A0000] C:\Windows\syswow64\wininet.dll
           8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255)
           Internet Extensions for Win32
[75AA0000] C:\Windows\syswow64\urlmon.dll
           8.0.7601.17874 - 8.00.7600.16385 (win7_rtm.090713-1255)
           OLE32 Extensions for Win32
[75BE0000] C:\Windows\syswow64\WS2_32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows Socket 2.0 32-Bit DLL
[75C20000] C:\Windows\syswow64\comdlg32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Common Dialogs DLL
[75CA0000] C:\Windows\syswow64\KERNELBASE.dll
           6.1.7601.17651 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Windows NT BASE API Client DLL
[75CF0000] C:\Windows\syswow64\USP10.dll
           1.626.7601.17514 - 1.0626.7601.17514 (win7sp1_rtm.101119-1850)
           Uniscribe Unicode script processor
[75DA0000] C:\Windows\syswow64\shell32.dll
           6.1.7601.17859 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           Windows Shell Common Dll
[769F0000] C:\Windows\syswow64\iertutil.dll
           8.0.7601.17874 - 8.00.7601.17874 (win7sp1_gdr.120626-1620)
           Run time utility for Internet Explorer
[76BF0000] C:\Windows\syswow64\MSCTF.dll
           6.1.7600.16385 - 6.1.7600.16385 (win7_rtm.090713-1255)
           MSCTF Server DLL
[76CC0000] C:\Windows\syswow64\ADVAPI32.dll
           6.1.7601.17514 - 6.1.7600.16385 (win7_rtm.090713-1255)
           Advanced Windows 32 Base API
[77130000] C:\Windows\syswow64\MSASN1.dll
           6.1.7601.17514 - 6.1.7601.17514 (win7sp1_rtm.101119-1850)
           ASN.1 Runtime APIs
[77160000] C:\Windows\SysWOW64\ntdll.dll
           6.1.7601.17725 - 6.1.7600.16385 (win7_rtm.090713-1255)
           NT Layer DLL
------------------------------------------------------------------------------
Active Controls hierarchy:
TPyIDEMainForm "PyIDEMainForm"
------------------------------------------------------------------------------

----------
components: Regular Expressions
messages: 170429
nosy: ezio.melotti, mrabarnett, nicolincioroianu
priority: normal
severity: normal
status: open
title: Assertion failure (C:\Delphi\progs32\Python\PythonIDE\cPyRemoteDebugger.pas, line 1175).
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 13 13:12:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 13 Sep 2012 11:12:42 +0000
Subject: [New-bugs-announce] [issue15938] expose way to count examples in
	doctest.DocFileSuite()
Message-ID: <1347534762.13.0.990789726192.issue15938@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add to the doctest module an easy way to obtain the number of doctest examples in a unittest.TestSuite instance returned by a call to the doctest.DocFileSuite() function.

The unittest.TestSuite class currently exposes a countTestCases() method that gives the number of TestCase instances inside a test suite.

However, this method isn't useful for determining how many doctest examples that the TestSuite instance returned by a call to DocFileSuite() contains, nor in particular whether the instance contains any actual tests.  Calling countTestCases() on the return value returns the number of files that were parsed and not the number of doctest examples.

In fact, getting the number of doctest examples contained in such a TestSuite is surprisingly obscure and seems to rely on implementation details and accessing private attributes.  Here is one way to do it (annotated with comments):

    paths = ['Doc/howto/ipaddress.rst', 'Doc/howto/unicode.rst']

    # The return value of DocFileSuite is a unittest.TestCase instance, and
    # each item in the return value is a doctest.DocFileCase instance (which
    # in turn is also a doctest.DocTestCase and unittest.TestCase instance).
    suite = doctest.DocFileSuite(*paths, module_relative=False)

    total = 0
    for case in suite:
        doc_test = case._dt_test  # a doctest.DocTest instance.
        total += len(doc_test.examples)

    print("total test cases:  %s" % suite.countTestCases())
    print("total examples:   %s" % total)

Ideally, you would just be able to do something like this instead:

    suite.countExamples()

Exposing a method like that would probably involve converting DocFileSuite from a simple function that returns a unittest.TestSuite into a class that subclasses unittest.TestSuite (so that the function becomes a constructor).

----------
components: Library (Lib)
messages: 170430
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: expose way to count examples in doctest.DocFileSuite()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 13 15:41:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 13 Sep 2012 13:41:38 +0000
Subject: [New-bugs-announce] [issue15939] make *.rst files in Doc/ parseable
	by doctest
Message-ID: <1347543698.43.0.179468389771.issue15939@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, when trying to parse the *.rst files in the Doc/ folder (i.e. not actually running them but simply generating unittest.TestCase instances from them by passing them to doctest.DocFileSuite()), five files yield errors.

This issue is to make it so that all of the *.rst files in our Doc/ folder are at least parseable by doctest without error.

I will submit a patch.

Below are the errors that currently occur:

(1) test fdoc:library/ctypes.rst crashed -- Traceback (most recent call last):
  ...
ValueError: line 55 of the doctest for ctypes.rst has an invalid option: '+WINDOWS'

(2) test fdoc:library/doctest.rst crashed -- Traceback (most recent call last):
  ...
ValueError: line 1592 of the docstring for doctest.rst has inconsistent leading whitespace: '      """))'

(3) test fdoc:library/multiprocessing.rst crashed -- Traceback (most recent call last):
  ...
ValueError: line 1016 of the docstring for multiprocessing.rst lacks blank after >>>: '>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>'

(4) test fdoc:whatsnew/2.4.rst crashed -- Traceback (most recent call last):
  ...
ValueError: line 1422 of the docstring for 2.4.rst lacks blank after >>>: '   >>>"""'

(5) test fdoc:whatsnew/2.7.rst crashed -- Traceback (most recent call last):
  ...
ValueError: line 1531 of the docstring for 2.7.rst lacks blank after   .: '      ...'

----------
assignee: docs at python
components: Documentation
messages: 170441
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: make *.rst files in Doc/ parseable by doctest
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 13 20:03:47 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Sep 2012 18:03:47 +0000
Subject: [New-bugs-announce] [issue15940] Time module: effect of locale
Message-ID: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

"Module locale 
Internationalization services. The locale settings can affect the return values for some of the functions in the time module."

This is vague and perhaps misleading. The doc also says
"Locale information is not used by asctime()."
"Locale information is not used by ctime()."

Since ctime() = asctime(localtime()), this implies to me that locale is also not used by localtime. Otherwise, locale information would indirectly be used by ctime. (I did not test this directly because I do not know what a legal locale name is on Windows. The doc example 'de_DE' does not work.)

Doc also says
"time.strftime(format[, t]) 
%a Locale?s abbreviated weekday name. 
... <similar for many other format characters>
"

So perhaps the doc should say "The locale setting affects the interpretation of many format specifiers in strftime and strptime".

If is does anything else, what?

----------
assignee: docs at python
components: Documentation
messages: 170448
nosy: belopolsky, docs at python, haypo, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Time module: effect of locale
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 13 20:07:21 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 13 Sep 2012 18:07:21 +0000
Subject: [New-bugs-announce] [issue15941] Time module: effect of
	time.timezone change
Message-ID: <1347559641.51.0.772200483389.issue15941@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

"time.timezone 
The offset of the local (non-DST) timezone, in seconds west of UTC (negative in most of Western Europe, positive in the US, zero in the UK)."

Quite aside from #9305 (UTC is not a place), this does not specify the effect of setting this attribute. It does not change the output of localtime, asctime, or ctime (on Windows). Does is affect anything else? strftime? If setting it has no effect, the doc should say so. (And then perhaps it should be made read-only in the future, as setting it expecting an effect would be a bug.)

----------
assignee: docs at python
components: Documentation
messages: 170450
nosy: belopolsky, docs at python, haypo, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Time module: effect of time.timezone change
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 13 21:02:47 2012
From: report at bugs.python.org (Garrett Cooper)
Date: Thu, 13 Sep 2012 19:02:47 +0000
Subject: [New-bugs-announce] [issue15942] Time representation for Windows
	incorrect when BIOS	clock set to localtime when calling
	time.localtime()
Message-ID: <1347562967.67.0.94049562536.issue15942@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

Windows doesn't return sane values for localtime(3) (per POSIX [1]) when
the BIOS is set to the local time (the host is a Win2k8-R2 machine):

$ python -V; python -c 'import time; print time.strftime("%m-%d-%y %H:%M:%S", time.localtime())'; date; uname -a
Python 2.6.1
09-13-12 19:56:03
Thu, Sep 13, 2012 11:56:03 AM
CYGWIN_NT-6.1-WOW64 QAQA-ORPTO8B466 1.7.11(0.260/5/3) 2012-02-24 14:05 i686 Cygwin

This seems to be a conscious design choice on Microsoft's part:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724961%28v=vs.85%29.aspx

I'll try and follow this up with the POSIX folks or maybe Microsoft, but
for the time being this needs to be documentation as an issue with downstream consumers (perl 5.8.9 also illustrates this issue).

----------
components: Library (Lib)
messages: 170453
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Time representation for Windows incorrect when BIOS clock set to localtime when calling time.localtime()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Sep 14 12:47:29 2012
From: report at bugs.python.org (Santiago Velasco)
Date: Fri, 14 Sep 2012 10:47:29 +0000
Subject: [New-bugs-announce] [issue15943] urllib2 always sends header
	connection: close
Message-ID: <1347619649.5.0.736297150545.issue15943@psf.upfronthosting.co.za>


New submission from Santiago Velasco:

I have noticed that urllib2 will always send the 'connection: close' in the headers, looking at the code there is no way to override this from outside of the open method.

 I am currently working with a server that kills connection upon reading the header, and content will not get served, or only a partial bit of the content gets served, I have tried with several other agents, all are able to download the full content served by the server.

I created a modified version without the 'connection: close' header and that solved the problem for me. I do not always have problems with that header, but I would like the ability to define my own headers, and since the connection: close header gets slapped inside an objects internal method, there is currently no other way I can bypass it.

----------
components: Library (Lib)
messages: 170473
nosy: sanxiago
priority: normal
severity: normal
status: open
title: urllib2 always sends header connection: close
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Sep 14 17:05:30 2012
From: report at bugs.python.org (David Beazley)
Date: Fri, 14 Sep 2012 15:05:30 +0000
Subject: [New-bugs-announce] [issue15944] memoryviews and ctypes
Message-ID: <1347635130.32.0.649142152247.issue15944@psf.upfronthosting.co.za>


New submission from David Beazley:

I've been playing with the interaction of ctypes and memoryviews and am curious about intended behavior.  Consider the following:

>>> import ctypes
>>> d = ctypes.c_double()
>>> m = memoryview(d)
>>> m.ndim
0
>>> m.shape
()
>>> m.readonly
False
>>> m.itemsize
8
>>>

As you can see, you have a memory view for the ctypes double object.  However, the fact that it has a 0-dimension and no shape seems to cause all sorts of weird behavior.  For instance, indexing and slicing don't work:

>>> m[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: invalid indexing of 0-dim memory
>>> m[:]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: invalid indexing of 0-dim memory
>>> 

As such, you can't really seem to do anything interesting with the resulting memory view.  For example, you can't pull data out of it.  Nor can you overwrite the contents (i.e., replacing the contents with an 8-byte byte string).

Attempting to cast the memory view to something else doesn't work either.

>>> d = ctypes.c_double()
>>> m = memoryview(d)
>>> m2 = m.cast('c')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> 

I must be missing something really obvious here.  Is there no way to get access to the memory behind a ctypes object?

----------
messages: 170477
nosy: dabeaz
priority: normal
severity: normal
status: open
title: memoryviews and ctypes
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep 15 12:27:59 2012
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 15 Sep 2012 10:27:59 +0000
Subject: [New-bugs-announce] [issue15945] memoryview + bytes fails
Message-ID: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

Python 3.3.0rc2+ (default:9def2209a839, Sep 10 2012, 08:44:51) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> memoryview(b'foo') + b'bar'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'memoryview' and 'bytes'
>>> b'bar' + memoryview(b'foo')
b'barfoo'
>>>

----------
messages: 170511
nosy: exarkun
priority: normal
severity: normal
status: open
title: memoryview + bytes fails
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep 15 14:57:40 2012
From: report at bugs.python.org (Christian Mikula)
Date: Sat, 15 Sep 2012 12:57:40 +0000
Subject: [New-bugs-announce] [issue15946] Windows 8 x64 - IO-Error
Message-ID: <1347713860.36.0.872797660614.issue15946@psf.upfronthosting.co.za>


New submission from Christian Mikula:

OS Windows 8 Enterprise x64 clean installed.
Python Version 2.6.6 and 2.7.3 both x64 installed.

Problem is to delete one Directory and immediately after create one new with the same Name!

!!! Code !!!

import sys, platform, os, shutil

TEST_PATH = "/test"

print "platform:\t", platform.platform()
print "sys.platform:\t", sys.platform
print "sys.version:\t", sys.version
print "directory test:\t'%s'" % TEST_PATH
print

if os.path.exists(TEST_PATH):
    shutil.rmtree(TEST_PATH)
if not os.path.exists(TEST_PATH):
    os.makedirs(TEST_PATH)

print "success"

!!! End of code !!!

The error is only present if the Directory was deleted previously.

Error:
Traceback (most recent call last):
  File "dir_test.py", line 23, in <module>
    os.makedirs(BUILD_PATH)
  File "C:\Program Files\Python27\lib\os.py", line 157, in makedirs
    mkdir(name, mode)
WindowsError: [Error 5] Zugriff verweigert: '/test'

----------
components: IO, Windows
files: dir_test.png
messages: 170514
nosy: cmikula
priority: normal
severity: normal
status: open
title: Windows 8 x64 - IO-Error
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file27193/dir_test.png

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

From report at bugs.python.org  Sat Sep 15 16:41:47 2012
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 15 Sep 2012 14:41:47 +0000
Subject: [New-bugs-announce] [issue15947] Assigning new values to instance
	of pointer types does	not check validity
Message-ID: <1347720107.38.0.0969129955644.issue15947@psf.upfronthosting.co.za>


New submission from Facundo Batista:

In the doc it says:

"""
Assigning a new value to instances of the pointer types c_char_p, c_wchar_p, and c_void_p changes the memory location they point to, not the contents of the memory block [...].

>>> s = "Hello, World"
>>> c_s = c_wchar_p(s)
>>> print(c_s)
c_wchar_p('Hello, World')
>>> c_s.value = "Hi, there"
>>> print(c_s)
c_wchar_p('Hi, there')
>>> print(s)                 # first object is unchanged
Hello, World
>>>
"""

However, c_s it's not getting "Hi, there" as "the memory location it points to", otherwise next access will surely segfault.

OTOH, if it *does* change the memory location, but the value is cached locally, which is the point of letting it change the memory location? Shouldn't it raise AttributeError or something?

Thanks!

----------
components: ctypes
messages: 170518
nosy: facundobatista
priority: normal
severity: normal
status: open
title: Assigning new values to instance of pointer types does not check validity
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Sep 15 17:29:07 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 15 Sep 2012 15:29:07 +0000
Subject: [New-bugs-announce] [issue15948] Unchecked return value of I/O
	functions
Message-ID: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's C code contains more than 30 lines that don't check the return value of I/O functions like fseek(). A missing check can hide issues like a failing NFS connection.

I've created an (incomplete) list of missing checks with find and grep.

$ find -name '*.c' | sort | xargs egrep '^(\t|\ )*(fopen|fdopen|fread|fseek|fwite|open|read|write|readdir|readlink|lseek|dup|dup2|opendir|fdopendir|closedir|dirfd|readdir|seekdir|scandir|telldir|fcntl|ioctl)\ *\('

./Modules/_ctypes/libffi/src/dlmalloc.c:          read(fd, buf, sizeof(buf)) == sizeof(buf)) {
./Modules/_cursesmodule.c:    fseek(fp, 0, 0);
./Modules/_cursesmodule.c:    fseek(fp, 0, 0);
./Modules/faulthandler.c:        write(thread.fd, thread.header, thread.header_len);
./Modules/getpath.c:    fseek(env_file, 0, SEEK_SET);
./Modules/mmapmodule.c:        lseek(fileno, 0, SEEK_SET);
./Modules/ossaudiodev.c:     ioctl(fd, SNDCTL_DSP_cmd, &arg)
./Modules/posixmodule.c:    ioctl(slave_fd, I_PUSH, "ptem"); /* push ptem */
./Modules/posixmodule.c:    ioctl(slave_fd, I_PUSH, "ldterm"); /* push ldterm */
./Modules/posixmodule.c:    ioctl(slave_fd, I_PUSH, "ttcompat"); /* push ttcompat */
./Modules/_posixsubprocess.c:            fcntl(fd_dir_fd, F_SETFD, old | FD_CLOEXEC);
./Modules/_posixsubprocess.c:            fcntl(p2cread, F_SETFD, old & ~FD_CLOEXEC);
./Modules/_posixsubprocess.c:            fcntl(c2pwrite, F_SETFD, old & ~FD_CLOEXEC);
./Modules/_posixsubprocess.c:            fcntl(errwrite, F_SETFD, old & ~FD_CLOEXEC);
./Modules/signalmodule.c:        write(wakeup_fd, &byte, 1);
./Modules/socketmodule.c:    ioctl(s->sock_fd, FIONBIO, (caddr_t)&block, sizeof(block));
./Modules/socketmodule.c:    ioctl(s->sock_fd, FIONBIO, (unsigned int *)&block);
./Modules/socketmodule.c:    fcntl(s->sock_fd, F_SETFL, delay_flag);
./Modules/zipimport.c:    fseek(fp, -22, SEEK_END);
./Modules/zipimport.c:        fseek(fp, header_offset, 0);  /* Start of file header */
./Modules/zipimport.c:        fseek(fp, header_offset + 8, 0);
./Modules/zipimport.c:        fseek(fp, header_offset + 42, 0);
./Modules/zipimport.c:    fseek(fp, file_offset, 0);
./Modules/zipimport.c:    fseek(fp, file_offset + 26, 0);
./Modules/zlib/gzlib.c:        open(path,
./PC/getpathp.c:    fseek(env_file, 0, SEEK_SET);
./Python/traceback.c:    lseek(fd, 0, 0); /* Reset position */
./Python/traceback.c:    write(fd, buffer, len);
./Python/traceback.c:    write(fd, buffer, len);
./Python/traceback.c:            write(fd, &c, 1);
./Python/traceback.c:        write(fd, "\"", 1);
./Python/traceback.c:        write(fd, "\"", 1);
./Python/traceback.c:    write(fd, "\n", 1);
./Python/traceback.c:            write(fd, "\n", 1);

The missing checks for zipimport.c are already handles by ticket #15897.

----------
keywords: easy
messages: 170521
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Unchecked return value of I/O functions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep 15 19:00:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 15 Sep 2012 17:00:19 +0000
Subject: [New-bugs-announce] [issue15949] docs.python.org not getting updated
Message-ID: <1347728419.57.0.753818975668.issue15949@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

docs.python.org doesn't seem to be getting updated anymore.  For example, this revision from Tuesday, Sept 11 is not reflected:

http://hg.python.org/cpython/rev/c8d60d0c736b

----------
assignee: docs at python
components: Documentation
messages: 170525
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: docs.python.org not getting updated

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

From report at bugs.python.org  Sun Sep 16 12:15:16 2012
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 16 Sep 2012 10:15:16 +0000
Subject: [New-bugs-announce] [issue15950] open() should not accept bool
	argument
Message-ID: <1347790516.11.0.86834770042.issue15950@psf.upfronthosting.co.za>


New submission from Lars Gust?bel:

Today I accidentally did this:

open(True).read()

Passing True as a file argument to open() does not fail, because a bool value is treated like an integer file descriptor (stdout in this case). Even worse is that the read() call hangs in an endless loop on my linux box. On windows I get an EBADF at least.

Wouldn't it be better if open() checked explicitly for a bool argument and raises a TypeError?

----------
components: IO
messages: 170550
nosy: lars.gustaebel
priority: normal
severity: normal
status: open
title: open() should not accept bool argument
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Sep 16 13:55:56 2012
From: report at bugs.python.org (Aleksey Sivokon)
Date: Sun, 16 Sep 2012 11:55:56 +0000
Subject: [New-bugs-announce] [issue15951] string.Formatter returns str for
	empty unicode template
Message-ID: <1347796556.49.0.9624827569.issue15951@psf.upfronthosting.co.za>


New submission from Aleksey Sivokon:

Expected behavior of string.Formatter() is to return unicode strings for unicode templates, and "byte" strings for str templates. Which is exactly what it does, with one frustrating exception: for empty unicode string it returns byte str. Test follows:

import string
template = u""
result = string.Formatter().format(template)
assert isinstance(result, unicode)
# AssertionError

----------
components: Library (Lib)
messages: 170551
nosy: Aleksey.Sivokon
priority: normal
severity: normal
status: open
title: string.Formatter returns str for empty unicode template
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 16 21:59:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 16 Sep 2012 19:59:51 +0000
Subject: [New-bugs-announce] [issue15952] format(value) and
	value.__format__() behave differently	with unicode format
Message-ID: <1347825591.49.0.625826586182.issue15952@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

format(value) and value.__format__() behave differently even though the documentation says otherwise:

"Note: format(value, format_spec) merely calls value.__format__(format_spec)."

(from http://docs.python.org/library/functions.html?#format )

The difference happens when the format string is unicode.  For example:

>>> format(10, u'n')
u'10'
>>> (10).__format__(u'n')  # parentheses needed to prevent SyntaxError
'10'

So either the documentation should be changed, or the behavior should be changed to match.

Related to this: neither the "Format Specification Mini-Language" documentation nor the string.Formatter docs seem to say anything about the effect that a unicode format string should have on the return value (in particular, should it cause the return value to be unicode or not):

http://docs.python.org/library/string.html#formatspec
http://docs.python.org/library/string.html#string-formatting

See also issue 15276 (int formatting), issue 15951 (empty format string), and issue 7300 (unicode arguments).

----------
assignee: docs at python
components: Documentation
messages: 170575
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: format(value) and value.__format__() behave differently with unicode format
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 17 11:13:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2012 09:13:44 +0000
Subject: [New-bugs-announce] [issue15953] Incorrect some fields declaration
	in the PyTypeObject	documentation
Message-ID: <1347873224.57.0.93636410461.issue15953@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The declaration of some fields in the PyTypeObject documentation does not match the sources. Here is a patch that fixes the mismatch.

----------
assignee: docs at python
components: Documentation
files: doc_newtypes.patch
keywords: easy, patch
messages: 170591
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Incorrect some fields declaration in the PyTypeObject documentation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27207/doc_newtypes.patch

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

From report at bugs.python.org  Mon Sep 17 12:14:34 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2012 10:14:34 +0000
Subject: [New-bugs-announce] [issue15954] No error checking after using of
	the wcsxfrm()
Message-ID: <1347876874.21.0.668678433738.issue15954@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The wcsxfrm() function may fail but there is no error check code.

I don't know what exception type should be used here: OSError with an errno EINVAL or some specialized type. I can't prepare tests, because I don't know under what conditions it would be possible error, and whether we can get it on any system at all without broking some internal unicode object invariants.

----------
components: Library (Lib), Windows
messages: 170592
nosy: loewis, storchaka
priority: low
severity: normal
status: open
title: No error checking after using of the wcsxfrm()
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Sep 17 14:22:42 2012
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 17 Sep 2012 12:22:42 +0000
Subject: [New-bugs-announce] [issue15955] gzip, bz2,
	lzma: add method to get decompressed size
Message-ID: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The gzip, bz2 and lzma file reader have no method to get the actual size and compression ratio of a compressed file. In my opinion it's useful to know how much disk space a file will need before it's decompressed.

----------
components: Library (Lib)
messages: 170598
nosy: christian.heimes, nadeem.vawda
priority: normal
severity: normal
status: open
title: gzip, bz2, lzma: add method to get decompressed size
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 17 15:33:47 2012
From: report at bugs.python.org (Steve Newcomb)
Date: Mon, 17 Sep 2012 13:33:47 +0000
Subject: [New-bugs-announce] [issue15956] backreference to named group does
	not work
Message-ID: <1347888827.23.0.363134887653.issue15956@psf.upfronthosting.co.za>


New submission from Steve Newcomb:

The '\\g<startquote>' in the below does not work:

>>> repr( re.compile( '\\<\\!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?P<entityName>[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?P<startquote>[\\042\\047])(?P<entityText>.+?)\\g<startquote>[ \\011\\012\\015]*\\>', re.IGNORECASE | re.DOTALL).search( '<!ENTITY % m.mixedContent "( #PCDATA | i | b)">'))
'None'

In the following, the '\\g<startquote>' has been replaced by '\\2'.  It works.

>>> repr( re.compile( '\\<\\!ENTITY[ \\011\\012\\015]+\\%[ \\011\\012\\015]*(?P<entityName>[A-Za-z][A-Za-z0-9\\.\\-\\_\\:]*)[ \\011\\012\\015]*(?P<startquote>[\\042\\047])(?P<entityText>.+?)\\2[ \\011\\012\\015]*\\>', re.IGNORECASE | re.DOTALL).search( '<!ENTITY % m.mixedContent "( #PCDATA | i | b)">'))
'<_sre.SRE_Match object at 0x7f77503d1918>'

Either this feature is broken or the re module documentation is somehow misleading me.

(Yes, I know there is an XML error in the above.  That's because it's SGML.)

----------
components: Regular Expressions
messages: 170605
nosy: ezio.melotti, mrabarnett, steve.newcomb
priority: normal
severity: normal
status: open
title: backreference to named group does not work
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 17 18:59:55 2012
From: report at bugs.python.org (Cliff Dyer)
Date: Mon, 17 Sep 2012 16:59:55 +0000
Subject: [New-bugs-announce] [issue15957] README.txt points to broken
	"contributing" url in python	wiki
Message-ID: <1347901195.54.0.476141478032.issue15957@psf.upfronthosting.co.za>


New submission from Cliff Dyer:

The README.txt file for distutils2 points to <http://wiki.python.org/Distutils2/Contributing>, which raises a 404.  The correct URL is <http://wiki.python.org/moin/Distutils2/Contributing>.  The attached patch fixes this typo.

----------
assignee: docs at python
components: Distutils2, Documentation
files: broken_link.diff
keywords: patch
messages: 170617
nosy: alexis, docs at python, jcd, tarek
priority: normal
severity: normal
status: open
title: README.txt points to broken "contributing" url in python wiki
Added file: http://bugs.python.org/file27209/broken_link.diff

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

From report at bugs.python.org  Mon Sep 17 20:03:30 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Sep 2012 18:03:30 +0000
Subject: [New-bugs-announce] [issue15958] bytes.join() should allow
	arbitrary buffer objects
Message-ID: <1347905010.83.0.632444428638.issue15958@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This should ideally succeed:

>>> b''.join([memoryview(b'foo'), b'bar'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected bytes, memoryview found

(ditto for bytearray.join)

----------
components: Interpreter Core
messages: 170618
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bytes.join() should allow arbitrary buffer objects
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep 17 21:52:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2012 19:52:36 +0000
Subject: [New-bugs-announce] [issue15959] Declaration mismatch of quick
	integer allocation counters
Message-ID: <1347911556.54.0.0253156044834.issue15959@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In Objects/longobject.c quick_int_allocs and quick_neg_int_allocs defined as int but in Objects/object.c they are declared and used as Py_ssize_t.

Here is a patch that fixes this mismatch.

See also issue4850.

----------
components: Interpreter Core
files: quick_int_allocs.patch
keywords: patch
messages: 170621
nosy: loewis, storchaka
priority: normal
severity: normal
status: open
title: Declaration mismatch of quick integer allocation counters
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27210/quick_int_allocs.patch

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

From report at bugs.python.org  Tue Sep 18 09:40:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 18 Sep 2012 07:40:20 +0000
Subject: [New-bugs-announce] [issue15960] logging.shutdown should cope with
	IO errors from	handler.release methods
Message-ID: <1347954020.8.0.36541508073.issue15960@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

logging.shutdown includes a try/except block to avoid emitting spurious IO errors while the interpreter is shutting down. This fails if a registered handler tries to do IO (such as calling flush()) in its release method.

It would be better if the flush-and-close block was written as:

  try:
      hr.acquire()
      try:
          hr.flush()
          hr.close()
      finally:
          hr.release()
  except (IOError, ValueError):
    # Tolerate handlers that try to do IO in release()

----------
messages: 170635
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: logging.shutdown should cope with IO errors from handler.release methods
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 18 13:34:50 2012
From: report at bugs.python.org (Malthe Borch)
Date: Tue, 18 Sep 2012 11:34:50 +0000
Subject: [New-bugs-announce] [issue15961] Missing return value in
	``system_message``
Message-ID: <1347968090.6.0.249587654203.issue15961@psf.upfronthosting.co.za>


New submission from Malthe Borch:

When ``docutils`` are importable, distutils uses a reporter implementation that incorrectly drops a return value from the ``system_message`` override (see patch).

----------
assignee: eric.araujo
components: Distutils
files: patch.diff
keywords: patch
messages: 170640
nosy: eric.araujo, malthe, tarek
priority: normal
severity: normal
status: open
title: Missing return value in ``system_message``
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file27215/patch.diff

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

From report at bugs.python.org  Tue Sep 18 14:19:54 2012
From: report at bugs.python.org (=?utf-8?q?Nacsa_Krist=C3=B3f?=)
Date: Tue, 18 Sep 2012 12:19:54 +0000
Subject: [New-bugs-announce] [issue15962] Windows STDIN/STDOUT Redirection
	is actually FIXED
Message-ID: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za>


New submission from Nacsa Krist?f:

The Python docs faq says that due to a bug in Windows NT's cmd.exe, the output redirection and piping won't work when started from file extension.

http://docs.python.org/faq/windows.html#how-do-i-make-python-scripts-executable
http://docs.python.org/py3k/faq/windows.html#how-do-i-make-python-scripts-executable

This is actually fixed in Windows, but the fix is disabled by default, and you need to enable it in regedit, the keyword is "InheritConsoleHandles".

Proof & Details:
http://support.microsoft.com/default.aspx?kbid=321788

It would be great if the docs could refer to this fix, as the docs is the major source of information for many.

----------
assignee: docs at python
components: Documentation, Installation, Windows
messages: 170641
nosy: Nacsa.Krist?f, docs at python
priority: normal
severity: normal
status: open
title: Windows STDIN/STDOUT Redirection is actually FIXED
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep 18 15:40:35 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 18 Sep 2012 13:40:35 +0000
Subject: [New-bugs-announce] [issue15963] Improve ./configure's support for
	32/64-bit	debug|release|profiled builds w/ vendor (non-gcc)
	compilers on	proprietary UNIX systems (Solaris/HP-UX/AIX et al).
Message-ID: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Gripe: if you want a 64-bit, non-gcc (i.e. vendor's cc) build on a proprietary UNIX system (i.e. Solaris, HP-UX, AIX etc), "you're going to have a bad time".

Coercing a 64-bit build from a vendor's cc currently requires explicit CFLAGS/LDFLAGS/configure gymnastics for each platform.  It's a pain.

Initial goal: use this issue to document the gymnastics.

Assumption: once all the different techniques are documented, it'll be easier to assess what changes would be appropriate to configure.in.

Side bar design question: on BSD/Linux/OSX w/ gcc/clang, if you're on an amd64 platform, you'll get a 64-bit build.  This isn't the case for Solaris, HP-UX and AIX -- the default is always 32-bit.  You need aforementioned gymnastics to coerce a 64-bit build.

Is this by design?  If so, then I guess I'm proposing that ./configure should have a `--with-64`-type argument that'll generate a 64-bit build.

If not, then we need to decide whether to change the default behavior such that ./configure always generates a 64-bit build if you're on a 64-bit platform -- if you want a 32-bit build, you need to explicitly tell ./configure (i.e. --with-32).

Changing the default is probably only viable for 3.4 onwards.  It'd be nice if 2.7->3.3 had generic configure support for 64-bit builds though (via --with-64).

XXX TODO for trent: review autoconf's offerings... getting 64-bit builds from vendor cc's can't be that unusual.

----------
assignee: trent
components: Build
messages: 170643
nosy: trent
priority: low
severity: normal
status: open
title: Improve ./configure's support for 32/64-bit debug|release|profiled builds w/ vendor (non-gcc) compilers on proprietary UNIX systems (Solaris/HP-UX/AIX et al).
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Sep 18 16:26:19 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 18 Sep 2012 14:26:19 +0000
Subject: [New-bugs-announce] [issue15964] SyntaxError in asdl when building
	2.7 with system Python	3
Message-ID: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Building with--

./configure --with-pydebug && make -j2

errors out after switching branches from default to 2.7 when the system Python is Python 3 (on Mac OS X 10.7.4 using MacPorts).

To reproduce:

$ sudo port select python python32
$ python
No such file or directory
$ python3 -V
Python 3.2.3
$ hg update default
$ ./configure --with-pydebug && make -j2
$ hg update 2.7
$ cp Modules/Setup.dist Modules/Setup
$ ./configure --with-pydebug && make -j2
...
config.status: creating pyconfig.h
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
./install-sh -c -d Include
./Parser/asdl_c.py -h Include ./Parser/Python.asdl
gcc -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c
gcc -c -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
  File "./Parser/asdl_c.py", line 1
    print "Must specify exactly one output file"
                                               ^
SyntaxError: invalid syntax
make: *** [Include/Python-ast.h] Error 1
make: *** Waiting for unfinished jobs....

Running "make distclean" doesn't fix this.  Here is one work-around:

$ sudo port select python python27
$ ./configure --with-pydebug && make -j2

Perhaps the right work-around can be documented in the devguide, or maybe this can be addressed another way.

----------
components: Build
messages: 170646
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: SyntaxError in asdl when building 2.7 with system Python 3
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 18 17:12:52 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 18 Sep 2012 15:12:52 +0000
Subject: [New-bugs-announce] [issue15965] AT_FDCWD is 0xffd19553 on Solaris
	10, resulting in compiler warnings.
Message-ID: <1347981172.74.0.722168531343.issue15965@psf.upfronthosting.co.za>


New submission from Trent Nelson:

On Solaris (s10/nitrogen):


% find /usr/include -type f | xargs fgrep -ni AT_FDCWD
/usr/include/sys/fcntl.h:320:#define    AT_FDCWD                        0xffd19553

(AIX uses -2, FreeBSD uses -100.)

Anyway, that results in:


(cpython at nitrogen:ttypts/10) (Tue/15:34) ..                                                                                                         (~/hg/3.x.trent/build/release)
% touch ../../src/Modules/posixmodule.c 
(cpython at nitrogen:ttypts/10) (Tue/15:34) ..                                                                                                         (~/hg/3.x.trent/build/release)
% time /usr/ccs/bin/make 
/opt/solarisstudio12.3/bin/cc  -DNDEBUG -v -m64 -mt=yes -xbuiltin -xhwcprof -xF -xarch=native -xchip=native -fast -fma=fused -g -xO4 -library=sunperf   -I. -I../../src/Include -IInclude   -DPy_BUILD_CORE  -c ../../src/Modules/posixmodule.c -o Modules/posixmodule.o
"../../src/Modules/posixmodule.c", line 2307: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 2337: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 2386: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 2626: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 2966: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 3198: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 3199: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 3845: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 3989: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 3990: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 4111: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 4267: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 4587: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 7007: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 7092: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 7510: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 8260: warning: initializer does not fit or is out of range: 0xffd19553
"../../src/Modules/posixmodule.c", line 8322: warning: initializer does not fit or is out of range: 0xffd19553
^C
*** Modules/posixmodule.o removed.
/usr/ccs/bin/make  2.79s user 0.28s system 46% cpu 6.598 total

In every case, the affected line is:

    int dir_fd = DEFAULT_DIR_FD;

(DEFAULT_DIR_FD defaults to AT_FDCWD if it's defined.)

Note that Solaris 10 64-bit is LP64, ints are still 32-bit.

----------
assignee: trent
components: Build
messages: 170648
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: AT_FDCWD is 0xffd19553 on Solaris 10, resulting in compiler warnings.
type: compile error

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

From report at bugs.python.org  Tue Sep 18 17:32:48 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 18 Sep 2012 15:32:48 +0000
Subject: [New-bugs-announce] [issue15966] concurrent.futures:
	Executor.submit keyword arguments	may not be called 'fn' (or 'self')
Message-ID: <1347982368.75.0.56994107832.issue15966@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The submit methods of concurrent.futures.ThreadPoolExecutor and concurrent.futures.ProcessPoolExectutor raise TypeError when submitting a callable with a keyword argument named 'fn' or 'self':

    Python 3.3.0rc2+ (default:3a880d640981, Sep 18 2012, 16:29:28) 
    [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import concurrent.futures
    >>> def awkward(*, fn): return fn * 1729
    ... 
    >>> with concurrent.futures.ThreadPoolExecutor(1) as e:
    ...     e.submit(awkward, fn=3)
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
    TypeError: submit() got multiple values for argument 'fn'


An obvious solution is to change the declarations of the submit methods from:

    def submit(self, fn, *args, **kwargs):
        ...

to

    def submit(*args, **kwargs):
        self, fn, *args = args


I don't think this is quite good enough, since it'll introduce a regression for anyone who was doing executor.submit(fn=...).

----------
messages: 170650
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: concurrent.futures: Executor.submit keyword arguments may not be called 'fn' (or 'self')
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 18 20:57:09 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 18 Sep 2012 18:57:09 +0000
Subject: [New-bugs-announce] [issue15967] Slaves don't seem to clean up
	their /tmp mess if a step	fails.
Message-ID: <1347994629.04.0.316608804637.issue15967@psf.upfronthosting.co.za>


New submission from Trent Nelson:

All my slaves' /tmp's are polluted with regrtest fluff.  I haven't checked yet, but I presume no cleanup is done if a test/run fails.

nitrogen% find /tmp -user cpython 2> /dev/null | wc -l
197
netbsd51-x64-1$ find /tmp -user cpython 2> /dev/null | wc -l
     142
oxygen% find /tmp -user cpython 2> /dev/null | wc -l                
456

Placeholder issue until it annoys me enough to patch.

----------
assignee: trent
components: Build
messages: 170663
nosy: trent
priority: normal
severity: normal
status: open
title: Slaves don't seem to clean up their /tmp mess if a step fails.
type: behavior

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

From report at bugs.python.org  Tue Sep 18 21:36:23 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 18 Sep 2012 19:36:23 +0000
Subject: [New-bugs-announce] [issue15968] Incorporate Tcl/Tk/Tix into the
	Windows build process
Message-ID: <1347996983.92.0.069726969781.issue15968@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

This patch incorporates Tcl/Tk/Tix into the MSVC build in the same fashion as OpenSSL has been done.

Highlights:
- A new project, tcltk, is added that simply calls the Python script build_tkinter.py to build the externals.
- New helper module PCbuild/buildlib.py to parse and evaluate the MSBuild property files.
- build_tkinter.py is updated to use MSBuild properties for locating the sources.
- The tcltk output directory is now inside the PCbuild directory to enable different Tcl/Tk/Tix versions for different Python versions

----------
components: Build
hgrepos: 149
messages: 170668
nosy: jkloth
priority: normal
severity: normal
status: open
title: Incorporate Tcl/Tk/Tix into the Windows build process
versions: Python 3.4

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

From report at bugs.python.org  Tue Sep 18 22:57:05 2012
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Sep 2012 20:57:05 +0000
Subject: [New-bugs-announce] [issue15969] faulthandler: drop S from
	dump_tracebacks_later()	function name to have consistent names
Message-ID: <1348001825.94.0.454810241369.issue15969@psf.upfronthosting.co.za>


New submission from STINNER Victor:

If it is not too late, I would like to "fix" the name of two functions of the new faulthandler module before the release of Python 3.3 final. Changes:

 * dump_tracebacks_later() => dump_traceback_later()
 * cancel_dump_tracebacks_later() => cancel_dump_traceback_later()

The module has also a function dump_traceback() without S.

In an early version of the module (before it was integrated in Python 3.3), these functions only dumped the current thread. They are now dumping all threads by default, and I don't see the point of having an S anyway.

@Georg: Would you accept such change? The module is new in Python 3.3, and it is only a debug module, I don't expect anyone relying on its API right now.

----------
components: Library (Lib)
files: faulthandler_without_s.patch
keywords: patch
messages: 170677
nosy: georg.brandl, haypo
priority: release blocker
severity: normal
status: open
title: faulthandler: drop S from dump_tracebacks_later() function name to have consistent names
versions: Python 3.3
Added file: http://bugs.python.org/file27221/faulthandler_without_s.patch

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

From report at bugs.python.org  Wed Sep 19 05:46:20 2012
From: report at bugs.python.org (Joshua Biagio)
Date: Wed, 19 Sep 2012 03:46:20 +0000
Subject: [New-bugs-announce] [issue15970] ElementTree HTML serialization
	incorrect for <meta>, <param>
Message-ID: <1348026380.02.0.662051799593.issue15970@psf.upfronthosting.co.za>


New submission from Joshua Biagio:

There seems to be a very minor bug in the ElementTree.py file, for the so-called 'empty' elements that are serialized without a closing tag. The HTML_EMPTY tuple/set is used to lookup these tags.

In the Lib/xml/etree/ElementTree.py file, the HTML_EMPTY tuple is created like:

HTML_EMPTY = ("area", "base", "basefont", "br", "col", "frame", "hr",
              "img", "input", "isindex", "link", "meta" "param")

There is a missing comma between "meta" and "param". I'm not sure if this is intended behavior.

The line should be replaced with:

HTML_EMPTY = ("area", "base", "basefont", "br", "col", "frame", "hr",
              "img", "input", "isindex", "link", "meta", "param")

----------
components: Library (Lib), XML
messages: 170699
nosy: Joshua.Biagio
priority: normal
severity: normal
status: open
title: ElementTree HTML serialization incorrect for <meta>, <param>
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 19 05:47:45 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 19 Sep 2012 03:47:45 +0000
Subject: [New-bugs-announce] [issue15971] Sporadic failure in
	test_dump_tracebacks_later_file	(test_faulthandler)
Message-ID: <1348026465.86.0.879721154604.issue15971@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

Seen on http://buildbot.python.org/all/builders/AMD64%20Lion%203.x/builds/428/steps/test/logs/stdio

======================================================================
FAIL: test_dump_tracebacks_later_file (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 490, in test_dump_tracebacks_later_file
    self.check_dump_tracebacks_later(file=True)
  File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 476, in check_dump_tracebacks_later
    filename, loops)
  File "/Users/ambv/Buildbot/3.x.langa-lion/build/Lib/test/test_faulthandler.py", line 460, in _check_dump_tracebacks_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Timeout \\(0:00:00.500000\\)!\\nThread 0x[0-9a-f]+:\\n  File "<string>", line 9 in func\n  File "<string>", line 20 in <module>$' not found in 'Timeout (0:00:00.500000)!\nThread 0x00007fff77d85960:\n  File "<string>", line 10 in func\n  File "<string>", line 20 in <module>'

----------------------------------------------------------------------
Ran 30 tests in 126.504s

The regex expects the failure to be at "line 9 in func", but the failure happens at "line 10".

----------
assignee: haypo
components: Tests
messages: 170700
nosy: ezio.melotti, haypo, lukasz.langa
priority: normal
severity: normal
stage: needs patch
status: open
title: Sporadic failure in test_dump_tracebacks_later_file (test_faulthandler)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 19 18:12:02 2012
From: report at bugs.python.org (John Taylor)
Date: Wed, 19 Sep 2012 16:12:02 +0000
Subject: [New-bugs-announce] [issue15972] wrong error message for
	os.path.getsize
Message-ID: <1348071122.36.0.302681706423.issue15972@psf.upfronthosting.co.za>


New submission from John Taylor:

import os.path
a = [ r'c:\Windows\notepad.exe' ]
print( os.path.getsize(a) )

Under Python 3.2.3, this error message is returned:
  File "c:\python32\lib\genericpath.py", line 49, in getsize
    return os.stat(filename).st_size
TypeError: Can't convert 'list' object to str implicitly


Under Python 3.3.0rc2, this error message is returned:
  File "c:\Python33\lib\genericpath.py", line 49, in getsize
    return os.stat(filename).st_size
TypeError: an integer is required


I feel like the 3.2.3 behavior is more accurate and would like to propose that the 3.3 error message says something about a list instead of an integer.

----------
components: Extension Modules
messages: 170726
nosy: jftuga
priority: normal
severity: normal
status: open
title: wrong error message for os.path.getsize
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Sep 19 20:03:17 2012
From: report at bugs.python.org (Lance Helsten)
Date: Wed, 19 Sep 2012 18:03:17 +0000
Subject: [New-bugs-announce] [issue15973] Segmentation fault on timezone
	comparison
Message-ID: <1348077797.35.0.854267629086.issue15973@psf.upfronthosting.co.za>


New submission from Lance Helsten:

In the 3.2.3 interpreter execute the following line:
    `None == datetime.timezone(datetime.timedelta())`
The interpreter will crash with a `Segmentation fault: 11`.

----------
assignee: ronaldoussoren
components: Macintosh
files: CoreDump.txt
messages: 170732
nosy: lanhel, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segmentation fault on timezone comparison
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file27224/CoreDump.txt

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

From report at bugs.python.org  Wed Sep 19 20:05:38 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Sep 2012 18:05:38 +0000
Subject: [New-bugs-announce] [issue15974] Optional compact and colored
	output for regrest
Message-ID: <1348077938.27.0.260547344914.issue15974@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It would be nice to have something like sphinx's build output where the output is all kept on a single line except for failures.

The color would help when scrolling through current output looking for failures. Currently I just look until the failure count switches, but I can spot color more quickly and easily.

The reason for the compact output is that I simply don't typically care about passed tests, so why keep it visible? It also helps with noticing tests failures if those are the only tests that are kept in the terminal while the suite is running (obviously the output summary is still there).

This also suggests having an option to write out to a file the test results to make it easier to see the exact test execution order (and if passed tests are commented out then it's easier to pass the file to --fromfile to re-run the fail tests).

----------
components: Tests
messages: 170733
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Optional compact and colored output for regrest
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 19 20:23:27 2012
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 19 Sep 2012 18:23:27 +0000
Subject: [New-bugs-announce] [issue15975] Allow multiplying timedelta by
	Decimal
Message-ID: <1348079007.17.0.324309830936.issue15975@psf.upfronthosting.co.za>


New submission from Ram Rachum:

Please allow multiplying timedelta by a Decimal:

Python 3.3.0a1 (default, Mar  4 2012, 17:27:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> import decimal
>>> decimal.Decimal('0.1')*datetime.timedelta(seconds=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'Decimal' and 'datetime.timedelta'
>>>

----------
components: Library (Lib)
messages: 170737
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow multiplying timedelta by Decimal
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Sep 19 21:57:41 2012
From: report at bugs.python.org (Evangelos Foutras)
Date: Wed, 19 Sep 2012 19:57:41 +0000
Subject: [New-bugs-announce] [issue15976] Inconsistent behavior of
	search_for_exec_prefix()	results in startup failure in certain cases
Message-ID: <1348084661.36.0.682682476046.issue15976@psf.upfronthosting.co.za>


New submission from Evangelos Foutras:

On Arch Linux /lib is a symbolic link to /usr/lib. When the Python interpreter is provided with an argv[0] of e.g. '/python2.7' and the current working directory is /, it'll fail to start with the following error:

IOError: invalid Python installation: unable to open //include/python2.7/pyconfig.h (No such file or directory)


>From what I understand, what is happening inside Modules/getpath.c is:

1) search_for_exec_prefix() is given an empty `argv0_path`
2) PYTHONHOME is not set, and we're not in a build directory, so step three is executed:

 * Step 3. Try to find prefix and exec_prefix relative to argv0_path,
 * backtracking up the path until it is exhausted.  This is the most common
 * step to succeed.  Note that if prefix and exec_prefix are different,
 * exec_prefix is more likely to be found; however if exec_prefix is a
 * subdirectory of prefix, both will be found.

3) copy_absolute() sets `exec_prefix` to '/'
4) 'lib/python2.7' gets appended to `exec_prefix` using joinpath()
5) 'lib-dynload' gets appended to `exec_prefix` using joinpath()
6) '/lib/python2.7/lib-dynload' exists and the function returns 1 (success)
7) control is returned to calculate_path() which later reduces `exec_prefix` to '/'

During further initialization, sysconfig.py tries to open pyconfig.h, whose path is calculated as {exec_prefix}/include/python2.7/pyconfig.h; thus ending up with the nonexistent path //include/python2.7/pyconfig.h. The correct exec_prefix would be /usr.


Moreover, if argv[0] and/or the current working directory are one level deeper (or more), `exec_prefix` will not be reduced to '/' and search_for_exec_prefix() will proceed to step four:

 * Step 4. Search the directories pointed to by the preprocessor variables
 * PREFIX and EXEC_PREFIX.  These are supplied by the Makefile but can be
 * passed in as options to the configure script.

i.e.: If search_for_exec_prefix() is passed an `argv0_path` with the value '/mnt', step three will only check '/mnt' but not '/', because '/mnt' will be reduced to '' and the `while (exec_prefix[0])` condition will be false.


I see two problems with the behavior I describe above:

1) Step three will skip checking the root directory (/) if argv[0] or the current working directory are one or more levels below / (in other words, not directly under /). Its behavior in this regard is inconsistent.
2) When argv[0] is e.g. '/python2.7' and the current working directory is /, it'll use '/' as the exec_prefix and fail to start. The /lib -> /usr/lib symbolic link should get dereferenced and not used as is.


I'm not sure how this should be fixed, so I only tried to present the issue with as many details as I could. If something is unclear, let me know.


Lastly, search_for_prefix() has very similar code, so any fix will have to be applied there too.


(There is also a downstream bug report @ https://bugs.archlinux.org/task/30812.)

----------
components: Interpreter Core
messages: 170760
nosy: foutrelis
priority: normal
severity: normal
status: open
title: Inconsistent behavior of search_for_exec_prefix() results in startup failure in certain cases
type: crash
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Sep 20 00:02:00 2012
From: report at bugs.python.org (Daniel Sommermann)
Date: Wed, 19 Sep 2012 22:02:00 +0000
Subject: [New-bugs-announce] [issue15977] Memory leak in _ssl.c
Message-ID: <1348092120.32.0.751173728211.issue15977@psf.upfronthosting.co.za>


New submission from Daniel Sommermann:

I noticed that the function _set_npn_protocols() has the following line:

self->npn_protocols = PyMem_Malloc(protos.len);

There is no check to see if self->npn_protocols is already allocated. Thus, multiple calls to _set_npn_protocols() will leak memory. There should be a check to see if it is non-null and free the memory pointed to by self->npn_protocols before the malloc unless I am missing something.

----------
components: IO
messages: 170774
nosy: Daniel.Sommermann, pitrou
priority: normal
severity: normal
status: open
title: Memory leak in _ssl.c
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 20 04:59:44 2012
From: report at bugs.python.org (chrysn)
Date: Thu, 20 Sep 2012 02:59:44 +0000
Subject: [New-bugs-announce] [issue15978] asyncore: included batteries don't
	fit
Message-ID: <1348109984.23.0.963898980799.issue15978@psf.upfronthosting.co.za>


New submission from chrysn:

the asyncore module would be much more useful if it were well integrated in the standard library. in particular, it should be supported by:

* subprocess
* BaseHTTPServer / http.server (and thus, socketserver)
* urllib2 / urllib, http.client
* probably many other network libraries except smtpd, which already uses asyncore

without widespread asyncore support, it is not possible to easily integrate different servers and services with each other; with asyncore support, it's just a matter of creating the objects and entering the main loop. (eg, a http server for controlling a serial device, with a telnet-like debugging interface).

the socketserver even documents that it would like to have such a framework ("Future work: [...] Standard framework for select-based multiplexing"). it would be rather difficult to port in the generic case (as socketserver based code in general relies on blocking `read`s or `readline`s), but can be done in particular cases (i've ported SimpleHTTPServer, but it's a mess of monkey-patching). for subprocess, there's a bunch of recipies at [1]; pyserial (not standard library, but might as well become) can be ported quite easily [2].

[1] http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/
[2] http://sourceforge.net/tracker/?func=detail&aid=3559321&group_id=46487&atid=446305


this issue touches several modules, so for practical implementation, it might be split up for the different individual fixes to come and track them. some of them will bring incompatible changes -- it's easy to get SimpleHTTPServer to a state where it can run unmodified inside asyncore, and emulate its external interfaces (serve_forever just being a wrapper to asyncore.loop), but hard to say if it will work with what people built atop of it. how can we find a roadmap for that?

python already has batteries for nonblocking operation included -- let's just make sure they fit in the other gadgets!

----------
messages: 170782
nosy: chrysn
priority: normal
severity: normal
status: open
title: asyncore: included batteries don't fit

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

From report at bugs.python.org  Thu Sep 20 05:26:47 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 20 Sep 2012 03:26:47 +0000
Subject: [New-bugs-announce] [issue15979] Improve timeit documentation
Message-ID: <1348111607.58.0.268885940785.issue15979@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The documentation of timeit can be improved in several ways:
 * it should start with a couple of short and comprehensible examples that show the basic usage from the command-line and from the code;
 * the 3 convenience functions should be moved before the class documentation (and their order inverted);
 * the methods in the class should be reordered to show the important one first;
 * more comprehensive (but still comprehensible) examples should be added at the end;
 * sh syntax highlight should be used for the command-line usage examples;
 * the note about Python 2.3 can be removed from 3.x docs;

http://docs.python.org/dev/library/timeit.html

----------
assignee: docs at python
components: Documentation
messages: 170785
nosy: docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve timeit documentation
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 20 10:26:32 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2012 08:26:32 +0000
Subject: [New-bugs-announce] [issue15980] Non-escaped '\n' in docstrings
Message-ID: <1348129592.37.0.740321783262.issue15980@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are patches that escapes '\n' in docstrings of LWPCookieJar and (for 2.7 only) of email.

----------
assignee: docs at python
components: Documentation
files: escape_nl2.patch
keywords: patch
messages: 170794
nosy: docs at python, ezio.melotti, storchaka
priority: normal
severity: normal
status: open
title: Non-escaped '\n' in docstrings
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27229/escape_nl2.patch

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

From report at bugs.python.org  Thu Sep 20 13:00:24 2012
From: report at bugs.python.org (Max)
Date: Thu, 20 Sep 2012 11:00:24 +0000
Subject: [New-bugs-announce] [issue15981] improve documentation of __hash__
Message-ID: <1348138824.37.0.3310744827.issue15981@psf.upfronthosting.co.za>


New submission from Max:

In dev/reference/datamodel#object.__hash__, there are two paragraphs that seem inconsistent. The first paragraph seems to say that a class that overrides __eq__() *should* explicitly flag itself as unhashable. The next paragraph says that a class that overrides __eq__() *will be* flagged unhashable by default. Which one is it?

Here are the two paragraphs:

Classes which inherit a __hash__() method from a parent class but change the meaning of __eq__() such that the hash value returned is no longer appropriate (e.g. by switching to a value-based concept of equality instead of the default identity based equality) can explicitly flag themselves as being unhashable by setting __hash__ = None in the class definition. Doing so means that not only will instances of the class raise an appropriate TypeError when a program attempts to retrieve their hash value, but they will also be correctly identified as unhashable when checking isinstance(obj, collections.Hashable) (unlike classes which define their own __hash__() to explicitly raise TypeError).

If a class that overrides __eq__() needs to retain the implementation of __hash__() from a parent class, the interpreter must be told this explicitly by setting __hash__ = <ParentClass>.__hash__. Otherwise the inheritance of __hash__() will be blocked, just as if __hash__ had been explicitly set to None.

----------
assignee: docs at python
components: Documentation
messages: 170798
nosy: docs at python, max
priority: normal
severity: normal
status: open
title: improve documentation of __hash__
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 20 13:12:50 2012
From: report at bugs.python.org (Nicolai Ehemann)
Date: Thu, 20 Sep 2012 11:12:50 +0000
Subject: [New-bugs-announce] [issue15982] asyncore.dispatcher does not
	handle windows socket error	code correctly (namely
	WSAEWOULDBLOCK 10035)
Message-ID: <1348139570.15.0.496741951323.issue15982@psf.upfronthosting.co.za>


New submission from Nicolai Ehemann:

There are some differences between win32 and other os socket implementations. One specific I found is that in windows, non-blocking socket apis will return WSAEWOULDBLOCK or 10035 instead of EWOULDBLOCK.

This causes recv() in asyncore.dispatcher to raise an unhandled exception instead of continuing gracefully.

The fix could maybe be as simple as replacing line 384 in asyncore.py:
  data = self.socket.recv(buffer_size)
with
  try:
    data = self.socket.recv(buffer_size)
  except socket.error as e:
    if 10035 == e.errno:
      pass
    else:
      raise e

The differences between windows and unix non-blocking sockets are summarized quite nice here: http://itamarst.org/writings/win32sockets.html

The original documentation from microsoft can be found here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx

----------
components: Library (Lib)
messages: 170799
nosy: McNetic
priority: normal
severity: normal
status: open
title: asyncore.dispatcher does not handle windows socket error code correctly (namely WSAEWOULDBLOCK 10035)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Sep 20 15:29:52 2012
From: report at bugs.python.org (Karl Bicker)
Date: Thu, 20 Sep 2012 13:29:52 +0000
Subject: [New-bugs-announce] [issue15983] multiprocessing JoinableQueue's
	join function with	timeout
Message-ID: <1348147792.78.0.126354805475.issue15983@psf.upfronthosting.co.za>


New submission from Karl Bicker:

The multiprocessing.JoinableQueue's function join() should have a timeout argument so that one can check on other things while waiting for a queue to finish.

As join() uses a condition to wait anyway, a timeout is easily implemented and passed to the Condidition.wait(). Patch is attached.

----------
components: Library (Lib)
files: JoinableQueue_with_timeout.patch
keywords: patch
messages: 170812
nosy: legordian
priority: normal
severity: normal
status: open
title: multiprocessing JoinableQueue's join function with timeout
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27233/JoinableQueue_with_timeout.patch

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

From report at bugs.python.org  Thu Sep 20 18:18:27 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2012 16:18:27 +0000
Subject: [New-bugs-announce] [issue15984] Wrong documentation for
	PyUnicode_FromObject()
Message-ID: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In the documentation it is written that PyUnicode_FromObject() is a shortcut for PyUnicode_FromEncodedObject(). But PyUnicode_FromObject() is not call PyUnicode_FromEncodedObject() direct nor indirect. PyUnicode_FromObject() works only with unicode and unicode subclass objects, PyUnicode_FromEncodedObject() is not works with unicode objects.

----------
assignee: docs at python
components: Documentation
messages: 170821
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Wrong documentation for PyUnicode_FromObject()
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 20 18:47:53 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 20 Sep 2012 16:47:53 +0000
Subject: [New-bugs-announce] [issue15985] round() has wrong argument names
Message-ID: <1348159673.68.0.790286767208.issue15985@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation for round() says:

round(x[, n])
Return the floating point value x rounded to n digits after the decimal point. If n is omitted, it defaults to zero. Delegates to x.__round__(n).

(from http://docs.python.org/dev/library/functions.html#round )

However, we have the following:

Python 3.3.0rc2+ (default:1704deb7e6d7+, Sep 16 2012, 04:49:45) 
>>> round(x=4.7)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Required argument 'number' (pos 1) not found
>>> round(number=4.7)
5

The second argument is also affected:

>>> round(5.1234, n=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'n' is an invalid keyword argument for this function
>>> round(5.1234, ndigits=3)
5.123

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 170822
nosy: cjerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: round() has wrong argument names
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 20 19:57:18 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Sep 2012 17:57:18 +0000
Subject: [New-bugs-announce] [issue15986] memoryview: expose 'buf' attribute
Message-ID: <1348163838.24.0.972937834938.issue15986@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
components: Interpreter Core
nosy: dabeaz, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: expose 'buf' attribute
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 20 20:43:57 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 20 Sep 2012 18:43:57 +0000
Subject: [New-bugs-announce] [issue15987] Provide a way to compare AST nodes
	for equality	recursively
Message-ID: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za>


New submission from Julian Berman:

As is, as far as I can tell, there's no way to easily compare two AST nodes to see if they have the same children and same fields (recursively).

I'm writing some unit tests for a NodeTransformers, so I've settled for comparing `ast.dump()`s of each, which is kind of dirty, but 1) works and 2) produces reasonable failure messages. (As a side note of what else I've tried, comparing, say, a list of the `iter_child_nodes` is not a good alternative, since the tests I'm writing are making assertions that a given node was not modified, which means they deepcopy the node and then want to assert that the "transformed" node is unchanged.)

I don't know the global implications of changing ast.AST.__eq__ to know if that's feasible (hopefully someone will comment on that), but if it isn't, another provided way would be nice.

----------
components: Library (Lib)
messages: 170826
nosy: Julian
priority: normal
severity: normal
status: open
title: Provide a way to compare AST nodes for equality recursively
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Sep 20 20:51:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2012 18:51:10 +0000
Subject: [New-bugs-announce] [issue15988] Inconsistency in overflow error
	messages of integer	argument
Message-ID: <1348167070.37.0.305629822418.issue15988@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyArg_ParseTuple raises inconsistent overflow error messages for small integer formats. For example:

>>> import _testcapi
>>> _testcapi.getargs_b(100)
100
>>> _testcapi.getargs_b(1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: unsigned byte integer is greater than maximum
>>> _testcapi.getargs_b(-1000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: unsigned byte integer is less than minimum
>>> _testcapi.getargs_b(100000000000000000000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long
>>> _testcapi.getargs_b(-100000000000000000000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long

On platforms with 32-bit int and 64-bit long there will be more such cases.

----------
components: Interpreter Core
messages: 170827
nosy: storchaka
priority: low
severity: normal
status: open
title: Inconsistency in overflow error messages of integer argument
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 20 21:01:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2012 19:01:45 +0000
Subject: [New-bugs-announce] [issue15989] Possible integer overflow of
	PyLong_AsLong() results
Message-ID: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are several places where the result of PyLong_AsLong() assigned to variable of type int. It can cause unknown issues on platforms with sizeof(int) != sizeof(long). All 140 cases of PyLong_AsLong() usage should be checked.

----------
assignee: storchaka
components: Interpreter Core
messages: 170832
nosy: storchaka
priority: normal
severity: normal
status: open
title: Possible integer overflow of PyLong_AsLong() results
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 20 21:24:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 20 Sep 2012 19:24:17 +0000
Subject: [New-bugs-announce] [issue15990] solidify argument/parameter
	terminology
Message-ID: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

There is currently some ambiguity in our documentation around positional and keyword arguments (e.g. whether positional means "position-only" or "non-keyword" (roughly) and whether various terms and definitions should be for the calling syntax or the function definition syntax or both).  For example, see the python-dev thread starting here:

http://mail.python.org/pipermail/python-dev/2012-September/121760.html

It would be good to nail down the preferred terminology in a central place.  I would suggest that the glossary is a good place to start.

For example, when there is a question about what phrase an error message should use or how an error message should be interpreted, it would be good if (at least going forward) the glossary could be used as a definitive resource.

This issue may involve making a distinction in our terminology "between arguments (what you pass, call syntax) and parameters (what the function receives, function definition syntax)" (see http://mail.python.org/pipermail/python-dev/2012-September/121771.html ).

----------
assignee: docs at python
components: Documentation
messages: 170834
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: solidify argument/parameter terminology

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

From report at bugs.python.org  Thu Sep 20 22:03:01 2012
From: report at bugs.python.org (Mikhail Afanasyev)
Date: Thu, 20 Sep 2012 20:03:01 +0000
Subject: [New-bugs-announce] [issue15991] BaseHTTPServer with ThreadingMixIn
	serving wrong data	sometimes
Message-ID: <1348171381.08.0.748825821227.issue15991@psf.upfronthosting.co.za>


New submission from Mikhail Afanasyev:

When using BaseHTTPServer with ThreadingMixIn, sometimes the wrong data is served. 

The attached script requests normal URL and URLs which are not found in multiple threads using wget (which only saves pages if it gets 200 OK status).
Every once in a while responses are incorrect.
 - sometimes normal URL gets a '404 not found' content with '200 OK' status.
 - sometimes, a '404 not found' page gets '200 OK' status code

The problems become much, much less frequent if ThreadingMixIn is removed.

Python 2.7.3 on ubuntu 12.04 x86_64.

----------
components: Library (Lib)
files: http_server_bug.py
messages: 170840
nosy: theamk
priority: normal
severity: normal
status: open
title: BaseHTTPServer with ThreadingMixIn serving wrong data sometimes
versions: Python 2.7
Added file: http://bugs.python.org/file27237/http_server_bug.py

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

From report at bugs.python.org  Thu Sep 20 22:16:59 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Sep 2012 20:16:59 +0000
Subject: [New-bugs-announce] [issue15992] Strict aliasing violations in
	Objects/unicodeobject.c
Message-ID: <1348172219.51.0.84674051024.issue15992@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

[Broken out of the discussion in issue 15144]

Some of the newly-optimized code in Objects/unicodeobject.c contains strict aliasing violations;  under the C standards, this is undefined behaviour (C99 6.5p7).

An example occurs in ascii_decode:

    unsigned long value = *(const unsigned long *) _p;

Here the pointer dereference violates the strict aliasing rule.

I think these portions of Objects/unicodeobject.c should be rewritten to avoid the undefined behaviour.

This is not a purely theoretical problem: compilers are known to make optimizations based on the assumption that strict aliasing is not violated.  Early versions of David Gay's dtoa.c gave incorrect results as a result of strict aliasing violations, for example; see [1].

[2] gives a stackoverflow reference explaining strict aliasing.

[1] http://patrakov.blogspot.co.uk/2009/03/dont-use-old-dtoac.html
[2] http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule

----------
components: Interpreter Core
messages: 170841
nosy: mark.dickinson, storchaka
priority: normal
severity: normal
status: open
title: Strict aliasing violations in Objects/unicodeobject.c
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 20 22:31:50 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Sep 2012 20:31:50 +0000
Subject: [New-bugs-announce] [issue15993] Windows: 3.3.0-rc2.msi:
	test_buffer fails
Message-ID: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I've installed 3.3.0-rc2 on Windows-7 64-bit using the msi installer.
I'm getting these failures in test_buffer, but I can *not* reproduce
them when I build Win-32/pgo/python.exe from source:

======================================================================
FAIL: test_memoryview_assign (test.test_buffer.TestBufferProtocol)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Program Files (x86)\Python33\lib\test\test_buffer.py", line 2863,
    self.assertEqual(m[i], 8)
AssertionError: 34359738368 != 8

======================================================================
FAIL: test_memoryview_struct_module (test.test_buffer.TestBufferProtocol)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Program Files (x86)\Python33\lib\test\test_buffer.py", line 2476,
    self.assertEqual(m[0], nd[0])
AssertionError: 15080797365275624638 != 6838299039298601293

----------
components: Interpreter Core
messages: 170844
nosy: brian.curtin, loewis, skrah
priority: critical
severity: normal
status: open
title: Windows: 3.3.0-rc2.msi: test_buffer fails
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 20 22:37:21 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 20 Sep 2012 20:37:21 +0000
Subject: [New-bugs-announce] [issue15994] memoryview to freed memory can
	cause segfault
Message-ID: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

A memoryview which does not own a reference to its base object can point to freed or reallocated memory.  For instance the following segfaults for me on Windows and Linux.


import io

class File(io.RawIOBase):
    def readinto(self, buf):
        global view
        view = buf
    def readable(self):
        return True

f = io.BufferedReader(File())
f.read(1)                       # get view of buffer used by BufferedReader
del f                           # deallocate buffer
view = view.cast('P')
L = [None] * len(view)          # create list whose array has same size
                                # (this will probably coincide with view)
view[0] = 0                     # overwrite first item with NULL
print(L[0])                     # segfault: dereferencing NULL


I realize there are easier ways to make Python segfault, so maybe this should not be considered a serious issue.  But I think there should be some way of guaranteeing that a memoryview will not try to access memory which has already been freed.

In #15903 skrah proposed exposing memory_release() as PyBuffer_Release().  However, I don't think that would necessarily invalidate all exports of the buffer.

Alternatively, one could incref the buffered reader object and set mview->mbuf->obj to it.  Maybe we could have

    PyMemoryView_FromMemoryEx(char *mem, Py_ssize_t size, int flags, PyObject *obj)

which guarantees that if obj is non-NULL then it will not be garbage collected before the memoryview.  This should *not* expose obj as an attribute of the memoryview.

----------
messages: 170846
nosy: sbt, skrah
priority: normal
severity: normal
status: open
title: memoryview to freed memory can cause segfault
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep 20 23:34:41 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Sep 2012 21:34:41 +0000
Subject: [New-bugs-announce] [issue15995] Windows: 3.3.0-rc2.msi: test_lzma
	fails
Message-ID: <1348176881.28.0.847630849965.issue15995@psf.upfronthosting.co.za>


New submission from Stefan Krah:

This is similar to #15993: With the installed Python from the rc2-msi
test_lzma fails. I cannot reproduce the failure with python.exe (PGO)
compiled from source:


======================================================================                                   
ERROR: test__decode_filter_properties (test.test_lzma.MiscellaneousTestCase)                             
----------------------------------------------------------------------                                   
Traceback (most recent call last):                                                                       
  File "C:\Python33\lib\test\test_lzma.py", line 1105, in test__decode_filter_properties                 
    lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00")                                                             
ValueError: Invalid filter ID: 4611686018427387905                                                       
                                                                                                         
======================================================================                                   
ERROR: test_filter_properties_roundtrip (test.test_lzma.MiscellaneousTestCase)                           
----------------------------------------------------------------------                                   
Traceback (most recent call last):                                                                       
  File "C:\Python33\lib\test\test_lzma.py", line 1114, in test_filter_properties_roundtrip               
    lzma.FILTER_LZMA1, b"]\x00\x00\x80\x00")                                                             
ValueError: Invalid filter ID: 4611686018427387905                                                       
                                                                                                         
----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 170853
nosy: brian.curtin, loewis, skrah
priority: critical
severity: normal
status: open
title: Windows: 3.3.0-rc2.msi: test_lzma fails
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 21 00:00:28 2012
From: report at bugs.python.org (mattip)
Date: Thu, 20 Sep 2012 22:00:28 +0000
Subject: [New-bugs-announce] [issue15996] pow() for complex numbers is rough
	around the edges
Message-ID: <1348178428.15.0.517718755216.issue15996@psf.upfronthosting.co.za>


New submission from mattip:

complex(1., 0.) ** complex(float('inf'), 0.) raises a ZeroDivisionError. In general, complex_power() needs to handle more corner cases. Barring a clear standard for pow() in C99, the documentation for pow 3 in glibc
http://www.kernel.org/doc/man-pages/online/pages/man3/pow.3.html
seems solid for a start, however it only describes behaviour for float/double values.

Where would be an appropriate place to add tests? I propose adding a test-case file similar to cmath_testcases.txt (attached) and a test runner similar to test_cmath.py

----------
components: Interpreter Core
files: rcomplex_testcases2.txt
messages: 170856
nosy: mark.dickinson, mattip
priority: normal
severity: normal
status: open
title: pow() for complex numbers is rough around the edges
type: behavior
Added file: http://bugs.python.org/file27238/rcomplex_testcases2.txt

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

From report at bugs.python.org  Fri Sep 21 07:50:37 2012
From: report at bugs.python.org (Max)
Date: Fri, 21 Sep 2012 05:50:37 +0000
Subject: [New-bugs-announce] [issue15997] NotImplemented needs to be
	documented
Message-ID: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za>


New submission from Max:

Quoting from http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy:

NotImplemented
This type has a single value. There is a single object with this value. This object is accessed through the built-in name NotImplemented. Numeric methods and rich comparison methods may return this value if they do not implement the operation for the operands provided. (The interpreter will then try the reflected operation, or some other fallback, depending on the operator.) Its truth value is true.

This is not a sufficient description of NotImplemented behavior. What does it mean "reflected operation" (I assume it is other.__eq__(self), but it needs to be clarified), and what does it mean "or some other fallback" (wouldn't developers need to know?). It also doesn't state what happens if the reflected operation or the fallback again return NotImplemented.

The rest of the documentation doesn't seem to talk about this either, despite several mentions of NotImplemented, with references to other sections.

This is particularly serious problem because Python's behavior changed in this respect not that long ago.

----------
assignee: docs at python
components: Documentation
messages: 170860
nosy: docs at python, max
priority: normal
severity: normal
status: open
title: NotImplemented needs to be documented
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep 21 12:30:30 2012
From: report at bugs.python.org (Sreenivas)
Date: Fri, 21 Sep 2012 10:30:30 +0000
Subject: [New-bugs-announce] [issue15998] Python GUI idle not working
Message-ID: <1348223430.53.0.95377552699.issue15998@psf.upfronthosting.co.za>


New submission from Sreenivas:

Hi Everybody,

I have a problem where Python GUI IDLE is not working.I did go through the issues 15658,9925,4625.I did follow the steps given in these issues.I did unset the tcl and tk_library.I was able to open the python idle temporarily.But once i closed it I had to follow the same commands to open it again.instead of just clicking the application.I also tried this command --------- c:\>Python32\Lib\idlelib\idle.py

This command gave the following error message

"This probably means Tcl wasn#t properly installed"

I tried to uninstall and reinstall and Python32 but still unsuccessful.I have installed few libs such as cx_Freeze and serial.I do not want to lose them as serial lib was itself painstaking process for installation.Can you tell me stepwise as to what should I do to get the IDLE working.

regards,
Sreeni

----------
components: IDLE
messages: 170877
nosy: sreeni
priority: normal
severity: normal
status: open
title: Python GUI idle not working
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep 21 17:47:09 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2012 15:47:09 +0000
Subject: [New-bugs-announce] [issue15999] Using new 'bool' format character
Message-ID: <1348242429.94.0.662282558141.issue15999@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Issue14705 added 'bool' format character to PyArg_ParseTuple for using it for parsing multiple boolean arguments in os module. The proposed patch uses this format character for other boolean arguments. This makes the sources simpler, clearer and more reliable, improves error messages, gets rid of a few rare errors.

----------
components: Extension Modules, Interpreter Core
files: use_bool_parsing.diff
keywords: patch
messages: 170897
nosy: larry, storchaka
priority: normal
severity: normal
status: open
title: Using new 'bool' format character
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27244/use_bool_parsing.diff

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

From report at bugs.python.org  Fri Sep 21 23:31:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 21 Sep 2012 21:31:26 +0000
Subject: [New-bugs-announce] [issue16000] test_curses should use unittest
Message-ID: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to switch test_curses to using unittest.TestCase classes.

Currently, test_curses does not use unittest.TestCase.  It just calls a series of functions that exercise curses functionality and aborts if an exception occurs:

http://hg.python.org/cpython/file/3e677956eef4/Lib/test/test_curses.py#l314

Some consequences of this are that a single failure will cause remaining tests not to execute, there is no fine-grained reporting, and TestCase assertion methods are not available (e.g. assertRaisesRegexp()).

----------
components: Library (Lib)
messages: 170925
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: test_curses should use unittest
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep 22 02:11:20 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 22 Sep 2012 00:11:20 +0000
Subject: [New-bugs-announce] [issue16001] small ints: cache string
	representation
Message-ID: <1348272680.09.0.237238464287.issue16001@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Integers in range [-5; 256] are singleton. It is possible to cache their string representation (in base 10) to make str(int) faster, but also to reduce memory consumption (and memory fragmentation, Unicode strings don't use free list).

Attached patch implements this micro-optimization. It reuses singleton for latin1 characters (so digits 0..9): str(0) is chr(48).

-        /* Special-case boolean: we want 0/1 */
-        if (PyBool_Check(val))
-            result = PyNumber_ToBase(val, 10);
-        else
-            result = Py_TYPE(val)->tp_str(val);
+        result = PyNumber_ToBase(val, 10);

This change is required because Py_TYPE(val)->tp_str(val); may return a singleton, whereas formatlong() requires a "mutable" string (string not used yet).

See also issue #10044.

----------
components: Unicode
files: small_ints_cache_str.patch
keywords: patch
messages: 170938
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
status: open
title: small ints: cache string representation
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file27254/small_ints_cache_str.patch

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

From report at bugs.python.org  Sun Sep 23 00:16:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 22 Sep 2012 22:16:57 +0000
Subject: [New-bugs-announce] [issue16002] AIX buildbot compile errors
Message-ID: <1348352217.78.0.0013472169184.issue16002@psf.upfronthosting.co.za>


New submission from Stefan Krah:

According to issue #9799 configuring --without-computed-gotos might
solve the AIX compile error.

----------
components: Build
keywords: buildbot
messages: 171013
nosy: skrah, trent
priority: normal
severity: normal
status: open
title: AIX buildbot compile errors
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep 23 10:34:06 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 23 Sep 2012 08:34:06 +0000
Subject: [New-bugs-announce] [issue16003] thread_PyThread_start_new_thread
	fails with a generic	error
Message-ID: <1348389246.53.0.0663792895343.issue16003@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

If thread creation fails, for any reason, a ThreadError is returned with the error "can't start new thread".
No attempt is made to diagnose the issue.
In fact, for example, if we are out of resources, pthread_new() would have returned EAGAIN.  This should perhaps rather be classified as an OSError so that users can catch this and diagnose it.  ThreadError seems to be used otherwise exclusively to indicate problems with locking.

Can this be turned into an informative OSError, or is it to platform dependant for any sensible structured error handlng to be implemented?

----------
messages: 171017
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: thread_PyThread_start_new_thread fails with a generic error
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 23 11:04:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 23 Sep 2012 09:04:35 +0000
Subject: [New-bugs-announce] [issue16004] Add `make touch` to 2.7 Makefile
Message-ID: <1348391075.72.0.200262721096.issue16004@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add "make touch" to the 2.7 Makefile as suggested by Nick Coghlan in the following comment to issue 15964:

"We should be able to add the "make touch" target to the 2.7 Makefile without running afoul of the "no new features" rule."

(from http://bugs.python.org/issue15964#msg171001 )

This will make it easier to help people address certain build errors encountered when switching between 2.7 and 3.x branches.

----------
components: Build
messages: 171019
nosy: cjerdonek, ncoghlan
priority: normal
severity: normal
status: open
title: Add `make touch` to 2.7 Makefile
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 23 14:21:25 2012
From: report at bugs.python.org (DDarko)
Date: Sun, 23 Sep 2012 12:21:25 +0000
Subject: [New-bugs-announce] [issue16005] smtplib.SMTP().sendmail() and
	rset()
Message-ID: <1348402885.58.0.691449233826.issue16005@psf.upfronthosting.co.za>


New submission from DDarko:

I'm trying to send an email as follows:

smtp = smtplib.SMTP(host, port=25)
smtp.ehlo()
smtp.sendmail(from_mail, to_mail, data)

The last line / command calls the raise.
I would like to know the reason why SMTP did not accept my email?
In theory, enough to capture the exception.
However, the exception of the last line returns:
"smtplib.SMTPServerDisconnected: Connection unexpectedly closed"
This is because the smtplib get replies in:
http://hg.python.org/cpython/file/default/Lib/smtplib.py
   767         (code, resp) = self.data(msg)
Then performs:
   769             self.rset()
As a result, the SMTP server disconnects the client. And instead receive info with reason I have information about sudden disconnection.

I do not think it should be reset, and if it is wrapped in a try.

Working snippet:
(code, resp) = self.data(msg)
if code != 250:
    #self.rset()
    raise SMTPDataError(code, resp)
#if we got here then somebody got our mail
return senderrs


This happens on servers mx.google.com

----------
components: Library (Lib)
messages: 171029
nosy: DDarko
priority: normal
severity: normal
status: open
title: smtplib.SMTP().sendmail() and rset()
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep 23 18:03:54 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 23 Sep 2012 16:03:54 +0000
Subject: [New-bugs-announce] [issue16006] Spelling mistake in PEP 213
Message-ID: <1348416234.5.0.925899069315.issue16006@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In the first line of the "Justification" paragraph in PEP 213 "cenario" is used. It should be "Scenario".

----------
components: None
messages: 171050
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Spelling mistake in PEP 213
type: enhancement

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

From report at bugs.python.org  Sun Sep 23 18:14:28 2012
From: report at bugs.python.org (Ling Li)
Date: Sun, 23 Sep 2012 16:14:28 +0000
Subject: [New-bugs-announce] [issue16007] Improved Error message for failing
	re expressions
Message-ID: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za>


New submission from Ling Li:

Hi,

I would like to make a small improvement to the exception raised when _compile() function fails with exception on line 245. 

Please see attached amended file. The line of code is amended from: 

    raise error, v # invalid expression

to:

    raise error, r'%s with pattern: %s' % (v, pattern) # invalid expression

As this is my first contribution, please let me know if this is the correct procedure to submit changes.

Kind regards,
Ling

----------
components: Regular Expressions
files: re.py
messages: 171051
nosy: ezio.melotti, lingster, mrabarnett
priority: normal
severity: normal
status: open
title: Improved Error message for failing re expressions
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27266/re.py

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

From report at bugs.python.org  Sun Sep 23 18:17:26 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Sep 2012 16:17:26 +0000
Subject: [New-bugs-announce] [issue16008] [OS bug] DragonFly buildbot locale
	failures
Message-ID: <1348417046.98.0.868158442098.issue16008@psf.upfronthosting.co.za>


New submission from Stefan Krah:

The locale failures on the DragonFly buildbot are caused by an OS bug:

bugs.dragonflybsd.org/issues/2415


I'm opening an issue so that this is recorded and other people hopefully
won't waste time debugging the failures. I intend to close the issue
as invalid in a couple of days.

======================================================================
FAIL: test_wide_char_separator_decimal_point (test.test_decimal.CFormatTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/test/test_decimal.py", line 1149, in test_wide_char_separator_decimal_point
    '100\u066c000\u066c000\u066b123')
AssertionError: '100000000.123' != '100\u066c000\u066c000\u066b123'
- 100000000.123
?          ^
+ 100\u066c000\u066c000\u066b123
?    +   +   ^


======================================================================
ERROR: test_basic (test.test_strptime.getlang_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/test/test_strptime.py", line 16, in test_basic
    self.assertEqual(_strptime._getlang(), locale.getlocale(locale.LC_TIME))
  File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/_strptime.py", line 31, in _getlang
    return locale.getlocale(locale.LC_TIME)
  File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/locale.py", line 524, in getlocale
    return _parse_localename(localename)
  File "/home/cpython/buildslave/3.x.snakebite-dragonfly30-amd64-1/build/Lib/locale.py", line 433, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: ps_AF

----------
keywords: buildbot
messages: 171052
nosy: skrah, trent
priority: low
severity: normal
status: open
title: [OS bug] DragonFly buildbot locale failures
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Sep 23 19:14:25 2012
From: report at bugs.python.org (Luka Rahne)
Date: Sun, 23 Sep 2012 17:14:25 +0000
Subject: [New-bugs-announce] [issue16009] Json not handling errors correctly
Message-ID: <1348420465.53.0.405036591258.issue16009@psf.upfronthosting.co.za>


New submission from Luka Rahne:

Example:

import json
j = json.loads(
"""
{
    "phoneNumber": [
        {
            "type": "home",
            "number": "212 555-1234"
        },
}

""")
print(j)

Output>>
Traceback (most recent call last):
  File "<stdin>", line 13, in <module>
  File "/usr/lib/python2.7/json/__init__.py", line 326, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded


My comment:
It is annoying in case of manual json editing where you can't know where jeson typeing error is.

----------
components: Library (Lib)
messages: 171062
nosy: Luka.Rahne
priority: normal
severity: normal
status: open
title: Json not handling errors correctly
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Sep 24 01:45:22 2012
From: report at bugs.python.org (Joshua Landau)
Date: Sun, 23 Sep 2012 23:45:22 +0000
Subject: [New-bugs-announce] [issue16010] Some Unicode in identifiers
	improperly rejected
Message-ID: <1348443922.86.0.645371844145.issue16010@psf.upfronthosting.co.za>


New submission from Joshua Landau:

"a? = None" is not valid, even though unicodedata.normalize("NFKC", "?") == "1".

One would expect "a? = None" and "a1 = None" to be equivalent in this case, as with "a? = None" and "ai = None".

I am not sure how many other characters exhibit the same problem.

References:
http://docs.python.org/py3k/reference/lexical_analysis.html#identifiers
http://mail.python.org/pipermail/python-list/2012-September/631420.html

"?" === "\u00b9"
"?" === "\u2071"

----------
components: Interpreter Core
messages: 171082
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: Some Unicode in identifiers improperly rejected
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep 24 02:13:51 2012
From: report at bugs.python.org (Neal Parikh)
Date: Mon, 24 Sep 2012 00:13:51 +0000
Subject: [New-bugs-announce] [issue16011] "in" should be consistent with
	return value of	__contains__
Message-ID: <1348445631.47.0.961273834435.issue16011@psf.upfronthosting.co.za>


New submission from Neal Parikh:

The Python 2.7.3 documentation says the following about defining __contains__:

"Called to implement membership test operators. Should return true if item is in self, false otherwise. For mapping objects, this should consider the keys of the mapping rather than the values or the key-item pairs."

This suggests that while you should return True/False, you don't need to. Also, the documentation doesn't say that if you return a value other than True or False, it will silently coerce other values to be True or False when you use "in". For example:

>>> class Foo(object):
...     def __contains__(self, item): return 42
... 
>>> foo = Foo()
>>> 3 in foo
True
>>> foo.__contains__(3)
42

When __contains__ is defined, "in" should return whatever __contains__ returns, even if this value is neither True nor False. That would be consistent with, for example, the comparison operators: You can return anything from __lt__ and "x < 4" will correctly pass along that value regardless of what it is.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 171085
nosy: docs at python, nparikh
priority: normal
severity: normal
status: open
title: "in" should be consistent with return value of __contains__
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 24 12:10:05 2012
From: report at bugs.python.org (Erich Seifert)
Date: Mon, 24 Sep 2012 10:10:05 +0000
Subject: [New-bugs-announce] [issue16012] pyexpat: Argument for
	UseForeignDTD should be optional
Message-ID: <1348481405.23.0.796569447482.issue16012@psf.upfronthosting.co.za>


New submission from Erich Seifert:

It seems the recent changes to Modules/pyexpat.c made the boolean 'flag' for UseForeignDTD mandatory although it was optional in previous Python releases.

According to the docs the usage is UseForeignDTD([flag]), but calling UseForeignDTD without arguments leads to an error::

  >>> from xml.parsers import expat
  >>> parser = expat.ParserCreate('utf8')
  >>> parser.UseForeignDTD()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: UseForeignDTD() takes exactly 1 argument (0 given)

This was tested with version bfdf366a779a from hg repository.

----------
components: Extension Modules
messages: 171108
nosy: eseifert
priority: normal
severity: normal
status: open
title: pyexpat: Argument for UseForeignDTD should be optional
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 24 15:03:12 2012
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 24 Sep 2012 13:03:12 +0000
Subject: [New-bugs-announce] [issue16013] small csv reader bug
Message-ID: <1348491792.39.0.00618601585478.issue16013@psf.upfronthosting.co.za>


New submission from Armin Rigo:

A small bug of cvs.reader():

>>> list(csv.reader(['foo:"'], delimiter=':', quotechar='"'))
[]

Adding strict=True doesn't change anything.  This is caused by the opening quote not followed by anything, which causes the error to be silently ignored and the last line to be dropped.

----------
components: Library (Lib)
messages: 171122
nosy: arigo
priority: normal
severity: normal
status: open
title: small csv reader bug
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Sep 24 15:48:33 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 13:48:33 +0000
Subject: [New-bugs-announce] [issue16014] Incomplete link in docs
Message-ID: <1348494513.71.0.115486808135.issue16014@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/py3k/license.html#mersenne-twister, the link http://www.math.keio.ac.jp/ matumoto/MT2002/emt19937ar.html is not complete because there is a space in it.

----------
assignee: docs at python
components: Documentation
messages: 171125
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Incomplete link in docs

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

From report at bugs.python.org  Mon Sep 24 15:53:02 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 13:53:02 +0000
Subject: [New-bugs-announce] [issue16015] Incorrect startup header in
	tutorial
Message-ID: <1348494782.32.0.720891839928.issue16015@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/py3k/tutorial/interpreter.html#interactive-mode , the header shown is "Python 3.2 (py3k, Sep 12 2007, 12:21:02)". Python 3.2 was no made in Sep 12 2007, so it could not be compiled at that time.
It should be a correct date or the date of today.

----------
assignee: docs at python
components: Documentation
messages: 171126
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Incorrect startup header in tutorial

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

From report at bugs.python.org  Mon Sep 24 15:59:11 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 13:59:11 +0000
Subject: [New-bugs-announce] [issue16016] Maybe make one author in ipaddress
	HOWTO
Message-ID: <1348495151.31.0.0905378753903.issue16016@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/dev/howto/ipaddress.html, I think there should be one author field with "Peter Moody and Nick Coghlan" on the right side.

----------
assignee: docs at python
components: Documentation
messages: 171129
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Maybe make one author in ipaddress HOWTO
versions: Python 3.3

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

From report at bugs.python.org  Mon Sep 24 16:03:19 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:03:19 +0000
Subject: [New-bugs-announce] [issue16017] "urls" should be capital in
	tutorial
Message-ID: <1348495399.07.0.504496501292.issue16017@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/py3k/tutorial/stdlib.html#internet-access , "from urls" should be "from URLs".

----------
assignee: docs at python
components: Documentation
messages: 171130
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: "urls" should be capital in tutorial
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep 24 16:19:30 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:19:30 +0000
Subject: [New-bugs-announce] [issue16018] Impossible ... line in tutorial
Message-ID: <1348496370.31.0.7411232442.issue16018@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/dev/tutorial/introduction.html, there is an ... line which is impossible in that case:

Variables must be ?defined? (assigned a value) before they can be used, or an error will occur:

>>>
>>> # try to access an undefined variable
... n
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'n' is not defined

It should be:

>>> n # try to access an undefined variable
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'n' is not defined

----------
messages: 171138
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Impossible ... line in tutorial

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

From report at bugs.python.org  Mon Sep 24 16:23:57 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:23:57 +0000
Subject: [New-bugs-announce] [issue16019] Python highlighting in tutorial;
	should be text highlighting
Message-ID: <1348496637.1.0.121151069885.issue16019@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , a text output has Python highlighting; it should be text highlighting

This is incorrectly highlighted text:

WARNING:root:Warning:config file server.conf not found
ERROR:root:Error occurred
CRITICAL:root:Critical error -- shutting down

----------
assignee: docs at python
components: Documentation
messages: 171142
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Python highlighting in tutorial;should be text highlighting

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

From report at bugs.python.org  Mon Sep 24 16:27:11 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:27:11 +0000
Subject: [New-bugs-announce] [issue16020] Missing >>> in Python code example
Message-ID: <1348496831.82.0.497019065466.issue16020@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/py3k/tutorial/stdlib2.html#logging , some code in a code sample is missing ">>>".

The code is:

unsearched = deque([starting_node])
def breadth_first_search(unsearched):
    node = unsearched.popleft()
    for m in gen_moves(node):
        if is_goal(m):
            return m
        unsearched.append(m)


should be:
>>> unsearched = deque([starting_node])
>>> def breadth_first_search(unsearched):
>>>    node = unsearched.popleft()
>>>    for m in gen_moves(node):
>>>        if is_goal(m):
>>>            return m
>>>        unsearched.append(m)

----------
assignee: docs at python
components: Documentation
messages: 171143
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Missing >>> in Python code example

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

From report at bugs.python.org  Mon Sep 24 16:34:13 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:34:13 +0000
Subject: [New-bugs-announce] [issue16021] In a table in PEP 235,
	brrrrrrrr should be N/A
Message-ID: <1348497253.81.0.361762009812.issue16021@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In the table:

                  case-preserving     case-destroying
                     +-------------------+------------------+
    case-sensitive   | most Unix flavors | brrrrrrrrrr      |
                     +-------------------+------------------+
    case-insensitive | Windows           | some unfortunate |
                     | MacOSX HFS+       | network schemes  |
                     | Cygwin            |                  |
                     |                   | OpenVMS          |
                     +-------------------+------------------+

brrrrrrrrrrr (pardon me for not putting the correct amount of "r"s) should be replaced with N/A

----------
messages: 171148
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: In a table in PEP 235, brrrrrrrr should be N/A

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

From report at bugs.python.org  Mon Sep 24 16:46:55 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 24 Sep 2012 14:46:55 +0000
Subject: [New-bugs-announce] [issue16022] Mistake in "What's New in Python
	3.3"
Message-ID: <1348498015.65.0.0485764115741.issue16022@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In "What's New in Python 3.3", there is a note:

Note: Beta users should be aware that this document is currently in draft form. It will be updated substantially as Python 3.3 moves towards release, so it?s worth checking back even after reading earlier versions.

If it is still in a draft form, replace "Beta users" with "Pre-release users" or something similar.
Else, obviously remove the note.

----------
assignee: docs at python
components: Documentation
messages: 171150
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: Mistake in "What's New in Python 3.3"

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

From report at bugs.python.org  Mon Sep 24 17:21:55 2012
From: report at bugs.python.org (Zellmeyer)
Date: Mon, 24 Sep 2012 15:21:55 +0000
Subject: [New-bugs-announce] [issue16023] IDLE froze when typing ctrl-shift-5
Message-ID: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za>


New submission from Zellmeyer:

IDLE do not response and you have to force to quit when you type the bad combination ctrl-shift-5.

I find it on my macbook when i try do type a [ character and type the bad combination by mistake because the keyboard are not exactly the same as the iMac.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 171154
nosy: ronaldoussoren, szellmeyer
priority: normal
severity: normal
status: open
title: IDLE froze when typing ctrl-shift-5
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Sep 24 17:29:59 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 24 Sep 2012 15:29:59 +0000
Subject: [New-bugs-announce] [issue16024] Doc cleanup regarding path=fd,
	dir_fd, follow_symlinks, etc
Message-ID: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za>


New submission from Larry Hastings:

You know how you start pulling on a thread and before you notice you've unraveled the whole sweater?  I meant to do a simple *one line* fix on the docs and wound up with a nearly-300-line diff.  I claim it's all an improvement, though I'm willing to change it if there's something you don't like.

Definite improvements:
* supports_fd et al are :class:`set` objects, not :class:`~collections.Set`.  Those are different.
* Linked to the "specifying a file descriptor" section in os from the relevant discussion in what's new.
* "Availability: Unix" goes above :versionadded.

Avowed improvements:
* supports_* now explicitly mention what values are permitted for their parameters.
* Lots of rewriting/munging in an effort to improve readability and precision.
* A couple places where "it's" read better than "it is".

LGTU?

----------
assignee: larry
components: Documentation
files: lch.supports_set.doc.cleanup.1.diff
keywords: patch
messages: 171155
nosy: georg.brandl, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file27276/lch.supports_set.doc.cleanup.1.diff

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

From report at bugs.python.org  Mon Sep 24 18:08:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 24 Sep 2012 16:08:02 +0000
Subject: [New-bugs-announce] [issue16025] Minor corrections to the zipfile
	documentation
Message-ID: <1348502882.43.0.635160318129.issue16025@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch corrects a few markup errors in the zipfile documentation and adds a few relevant hyperlinks.

----------
assignee: docs at python
components: Documentation
files: doc_zipfile-3.3.patch
keywords: patch
messages: 171157
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Minor corrections to the zipfile documentation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27277/doc_zipfile-3.3.patch

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

From report at bugs.python.org  Mon Sep 24 18:53:03 2012
From: report at bugs.python.org (Peter Eisentraut)
Date: Mon, 24 Sep 2012 16:53:03 +0000
Subject: [New-bugs-announce] [issue16026] csv.DictReader argument names
	documented incorrectly
Message-ID: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>


New submission from Peter Eisentraut:

The documentation for the csv.DictReader constructor is

.. class:: DictReader(csvfile, fieldnames=None, restkey=None, restval=None, dialect='excel', *args, **kwds)

but the implementation is

def __init__(self, f, fieldnames=None, restkey=None, restval=None, dialect="excel", *args, **kwds):

The name of the first argument is documented incorrectly, leading to surprise errors when attempting to use key word arguments.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 171161
nosy: docs at python, petere
priority: normal
severity: normal
status: open
title: csv.DictReader argument names documented incorrectly
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep 24 19:02:41 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 24 Sep 2012 17:02:41 +0000
Subject: [New-bugs-announce] [issue16027] pkgutil doesn't support frozen
	modules
Message-ID: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

pkgutil is used by runpy to run Python modules that are loaded via the -m command line switch.

Unfortunately, this doesn't work for frozen modules, since pkgutil doesn't know how to load their code object (this can be had via imp.get_code_object() for frozen modules).

We found the problem while working on eGenix PyRun (see http://www.egenix.com/products/python/PyRun/) which uses frozen modules extensively. We currently only target Python 2.x, so will have work around the problem with a patch, but Python 3.x still has the same problem.

----------
components: Library (Lib)
messages: 171163
nosy: lemburg
priority: normal
severity: normal
status: open
title: pkgutil doesn't support frozen modules
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Sep 24 20:27:59 2012
From: report at bugs.python.org (Erik Allik)
Date: Mon, 24 Sep 2012 18:27:59 +0000
Subject: [New-bugs-announce] [issue16028] break in finally discards exception
Message-ID: <1348511279.94.0.440526778313.issue16028@psf.upfronthosting.co.za>


New submission from Erik Allik:

This is either a bug, or a very weird but undocumented feature/caveat.


def fn1():
    while True:
        try:
            raise Exception()
        finally:
            pass
def fn2():
    while True:
        try:
            raise Exception()
        finally:
            break  # <-----
fn1()  # exception, as expected
fn2()  # silence!

----------
messages: 171168
nosy: eallik
priority: normal
severity: normal
status: open
title: break in finally discards exception
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 24 22:29:00 2012
From: report at bugs.python.org (akira)
Date: Mon, 24 Sep 2012 20:29:00 +0000
Subject: [New-bugs-announce] [issue16029] pickle.dumps(xrange(sys.maxsize))
	produces xrange(0)
Message-ID: <1348518540.13.0.547483002596.issue16029@psf.upfronthosting.co.za>


New submission from akira:

>>> import sys
  >>> from pickle import dumps, loads
  >>> r = xrange(sys.maxsize)
  >>> len(r) == sys.maxsize
  True
  >>> pr = loads(dumps(r))
  >>> len(pr) == len(r)
  False
  >>> pr
  xrange(0)
  >>> r
  xrange(9223372036854775807)

It breaks multiprocessing module:
http://stackoverflow.com/questions/12569977/python-large-iterations-number-fail

It fails on 2.6.6, 2.7.3. It works correctly on 3.1-3.3, pypy 1.7-1.9  x86_64 Linux.

----------
components: Library (Lib)
files: test_pickle_dumps_xrange.py
messages: 171187
nosy: akira
priority: normal
severity: normal
status: open
title: pickle.dumps(xrange(sys.maxsize)) produces xrange(0)
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file27281/test_pickle_dumps_xrange.py

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

From report at bugs.python.org  Mon Sep 24 23:23:17 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Sep 2012 21:23:17 +0000
Subject: [New-bugs-announce] [issue16030] xrange repr broken for large
	arguments
Message-ID: <1348521797.77.0.407946912471.issue16030@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Python 2.7.3+ (2.7:f51d11405f1d+, Sep 24 2012, 21:39:19) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> xrange(0, sys.maxint, sys.maxint-1)
xrange(0, -4, 9223372036854775806)

See also issue #16029.  There should be a common solution to both these issues.  Suggestion is to write a 'range_safe_stop' utility function that returns r->start + r->len * r->step clipped to the range [LONG_MIN, LONG_MAX], and use that for the stop value in both the repr and the pickle.

----------
assignee: mark.dickinson
components: Library (Lib)
messages: 171193
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: xrange repr broken for large arguments
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 25 03:07:47 2012
From: report at bugs.python.org (James Hutchison)
Date: Tue, 25 Sep 2012 01:07:47 +0000
Subject: [New-bugs-announce] [issue16031] relative import headaches
Message-ID: <1348535267.9.0.55515174451.issue16031@psf.upfronthosting.co.za>


New submission from James Hutchison:

This might even be a bug I've stumbled upon but I'm listing it as an enhancement for now.

I really feel that relative imports in Python should just work. Regardless of the __name__, I should be able to import below me. Likewise, it should work even if I've already done an import into the symbol table. It adds additional work to us as a developer to have to do some pythonpath or code gymnastics to get something rather trivial working. Additionally, the import errors from circular imports add another challenge to work around. In C/C++ you can force it to import a file once and only once, why can't Python work the same way?

Take the following example set-up:
startPoint.py
subModule1
   /__init__.py
   /a.py
   /b.py
   /tests
      /__init__.py
      /test_a.py

a's code:
print("in a");
from subModule1 import b

b's code:
print("in b");
from subModule1 import a

test_a.py's code:
print("myname:",__name__);
from .. import a

startPoint.py is empty, and the __init__.py files are also empty.

If I run a PyDev unit test on test_a.py this is what I get:

Finding files... done.
Importing test modules ... myname: subModule1.tests.test_a
in a
in b
myname: test_a
Traceback (most recent call last):
  File "C:\eclipse\plugins\org.python.pydev_2.6.0.2012062818\pysrc\pydev_runfiles.py", line 432, in __get_module_from_str
    mod = __import__(modname)
  File "C:\myfolder/relativeImportTest/subModule1/tests\test_a.py", line 6, in <module>
    from .. import a
ValueError: Attempted relative import in non-package

Clearly in this case, the exception given doesn't make any sense. I have __init__.py, the error says the relative import line is failing, and the error says it's because I'm in a non-package. Except, I'm in a package. It seems to go through the a_test.py file twice, even though I never explicitly import it. The first time through, I'm clearly in a package. The second time through, my name is NOT __main__ but yet I'm apparently no longer a package, which is where it fails.

Now if I change:
"from subModule1 import b" to "import subModule1.b"
and
"from subModule1 import a" to "import subModule1.a"

then everything works. But then that means I have to reference everything by the full name in my submodules. In this example, there's clearly a circular reference between a and b that wouldn't work anyways.

So lets change some things.

Now:
a.py:
import subModule1.b

b.py:
from subModule1 import a

Now the circular reference is gone between a and b. I really don't like having to do this as a means to work around a circular reference because it forces me to vary the import style of one file to another.

If we try the test code again however, it gets the same problem. If I swap which file does the relative import, then it works.

So lets make one last change:

test_a.py:
import subModule1.b # added
from .. import a

This will work, seemingly magically. It only runs the code in test_a.py once. Recall that the code in a.py is "import subModule1.b"

So basically this brings up several issues:
1. "import a.b" isn't the same as "from a import b" by more than how you reference it in the code
2. submodules are re-imported as non-module without ever importing them if you import their parent module relatively. If this is documented I don't know where.
3. import order can matter drastically to if a code runs or not for seemingly magical reasons.

And back when I was a beginner Python user, the naming convention of the full path really threw a monkey wrench in my code when I would try to move a select number of files from one project to another, or would try relative imports. If relative imports cause such headaches with circular references then I should generally stick to the full module path when referencing things. But if the full module path isn't portable then I should use relative imports.

Likewise, if I run as a PyDev unitTest, my module name is NOT __main__, so special path checks for __main__ won't work

I think the bottom line is that the import system gave me headaches as a beginner user and as an advanced user it still does every now and then so it really should be changed to something more intuitive or forgiving. I really shouldn't have to sit and think "how do I reference a function in the file just one directory level below mine?"

If there is already some magic bullet for this then it should probably be more visible.

----------
components: Interpreter Core
messages: 171208
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: relative import headaches
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Tue Sep 25 05:44:57 2012
From: report at bugs.python.org (Omanand Jha Vatsa)
Date: Tue, 25 Sep 2012 03:44:57 +0000
Subject: [New-bugs-announce] [issue16032] IDLE 3.2 is crashing multiple times
Message-ID: <1348544697.27.0.843034170589.issue16032@psf.upfronthosting.co.za>


New submission from Omanand Jha Vatsa:

Crashed multiple times on clicking Preferences in IDLE menu. It is crashing while trying to copying things from the IDLE shell.

----------
assignee: ronaldoussoren
components: Macintosh
files: Python_2012-09-24-234004_BLMACPRO3137C.crash
messages: 171212
nosy: Omanand.Jha.Vatsa, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE 3.2 is crashing multiple times
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file27287/Python_2012-09-24-234004_BLMACPRO3137C.crash

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

From report at bugs.python.org  Tue Sep 25 06:15:14 2012
From: report at bugs.python.org (jimbo1qaz)
Date: Tue, 25 Sep 2012 04:15:14 +0000
Subject: [New-bugs-announce] [issue16033] IDLE crashes when debugging and
	saving
Message-ID: <1348546514.17.0.0573110140957.issue16033@psf.upfronthosting.co.za>


New submission from jimbo1qaz:

Have the debugger open, stopped on a breakpoint, and save the open file. The whole thing will bomb after the save finishes. Changes are not lost, but I have to reopen IDLE and lose history and breakpoints.

----------
components: IDLE
messages: 171214
nosy: jimbo1qaz
priority: normal
severity: normal
status: open
title: IDLE crashes when debugging and saving
versions: Python 3.2

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

From report at bugs.python.org  Tue Sep 25 06:39:33 2012
From: report at bugs.python.org (Victor Hooi)
Date: Tue, 25 Sep 2012 04:39:33 +0000
Subject: [New-bugs-announce] [issue16034] bz2 module appears slower in
	Python 3.x versus Python 2.x
Message-ID: <1348547973.67.0.489000428853.issue16034@psf.upfronthosting.co.za>


New submission from Victor Hooi:

Hi,

I was writing a script to parse BZ2 blogfiles under Python 2.6, and I noticed that bz2file (http://pypi.python.org/pypi/bz2file) seemed to perform much slower than with bz2 (native):

http://stackoverflow.com/questions/12575930/is-python-bz2file-slower-than-bz2

I wrote a dummy script that basically just reads through the file, one for bz2 and one for bz2file (attached):

[vichoo at dev_desktop_vm Desktop]$ time /opt/python3.3/bin/python3.3 testbz2.py > /dev/null

real    0m5.170s
user    0m5.009s
sys     0m0.030s
[vichoo at dev_desktop_vm Desktop]$ time /opt/python3.3/bin/python3.3 testbz2file.py > /dev/null

real    0m5.245s
user    0m4.979s
sys     0m0.060s
[vichoo at dev_desktop_vm Desktop]$ time /opt/python2.7/bin/python2.7 testbz2.py > /dev/null

real    0m0.500s
user    0m0.410s
sys     0m0.030s
[vichoo at dev_desktop_vm Desktop]$ time /opt/python2.7/bin/python2.7 testbz2file.py > /dev/null

real    0m5.801s
user    0m5.529s
sys     0m0.050s

I also executed "echo 3 > /proc/sys/vm/drop_cache" between each run.

>From this, it appears that Python 2.x's bz2 is fast, but bz2file is slow - and that Python 3.x's bz2 is slow.

Obviously, there could be an issue with the methdology above - however, if not, do you know if there are any performance regressions in bz2 from Python 2.x to 3.x?

Thanks,
Victor

----------
components: None
files: testbz2file.py
messages: 171216
nosy: victorhooi
priority: normal
severity: normal
status: open
title: bz2 module appears slower in Python 3.x versus Python 2.x
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file27288/testbz2file.py

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

From report at bugs.python.org  Tue Sep 25 11:40:44 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 25 Sep 2012 09:40:44 +0000
Subject: [New-bugs-announce] [issue16035] Segmentation fault in test suite
	of apsw
Message-ID: <1348566044.22.0.909419846865.issue16035@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

The fix for issue #13992 introduced segmentation fault in test suite of apsw (http://code.google.com/p/apsw/) (with Python 2.7, 3.2 and 3.3).

$ python2.7 setup.py build
running build
running build_ext
SQLite: Using system sqlite include/libraries
building 'apsw' extension
creating build
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/src
x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG -O2 -fPIC -DEXPERIMENTAL=1 -DNDEBUG=1 -DAPSW_FORK_CHECKER=1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -Isrc -I/usr/include/python2.7 -c src/apsw.c -o build/temp.linux-x86_64-2.7/src/apsw.o
In file included from /usr/include/python2.7/Python.h:8:0,
                 from src/apsw.c:73:
/usr/include/python2.7/pyconfig.h:1161:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default]
/usr/include/features.h:215:0: note: this is the location of the previous definition
creating build/lib.linux-x86_64-2.7
x86_64-pc-linux-gnu-gcc -pthread -shared -O2 build/temp.linux-x86_64-2.7/src/apsw.o -L/usr/lib64 -lsqlite3 -lpython2.7 -o build/lib.linux-x86_64-2.7/apsw.so
$ PYTHONPATH="build/lib.linux-x86_64-2.7" python2.7 tests.py -v
                Python /usr/bin/python2.7 sys.version_info(major=2, minor=7, micro=4, releaselevel='alpha', serial=0)
Testing with APSW file /tmp/apsw-3.7.14-r1/build/lib.linux-x86_64-2.7/apsw.so
          APSW version 3.7.14-r1
    SQLite lib version 3.7.14
SQLite headers version 3007014
    Using amalgamation False
testAggregateFunctions (__main__.APSW)
Verify aggregate functions ... Segmentation fault

----------
messages: 171236
nosy: Arfrever, benjamin.peterson, georg.brandl, pitrou
priority: release blocker
severity: normal
status: open
title: Segmentation fault in test suite of apsw
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:18:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 25 Sep 2012 10:18:30 +0000
Subject: [New-bugs-announce] [issue16036] simplify int() signature docs
Message-ID: <1348568310.1.0.968219969881.issue16036@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to simplify the documentation of the built-in function int()'s signature:

int([number | string[, base]])

and to make any needed changes to the text of the docs as a consequence.  Discussion around this issue began in the comments to issue 14783 about int() and str()'s docstrings.

[I copied the nosy list from that issue.]

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 171238
nosy: chris.jerdonek, cvrebert, docs at python, eric.araujo, ezio.melotti, georg.brandl, rhettinger, storchaka, terry.reedy, tshepang
priority: normal
severity: normal
status: open
title: simplify int() signature docs
type: enhancement
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:25:22 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:25:22 +0000
Subject: [New-bugs-announce] [issue16037] httplib: header parsing is not
	delimited
Message-ID: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The httplib module / package can read arbitrary amounts of data from its socket when it's parsing the HTTP header. This may lead to issues when a user connects to a broken HTTP server or something that isn't a HTTP at all. The issue can be broken up into two parts: parsing the HTTP status line parsing and parsing the remaining HTTP headers.

Reading and parsing of the HTTP status line is already limited in Python 3.x. Python 2.7 and lower may read arbitrary amounts of bytes from the socket until it finds a newline char. The small patch below is a backport of the Python 3.x behavior to 2.7:

--- a/Lib/httplib.py
+++ b/Lib/httplib.py
@@ -362,7 +362,9 @@

     def _read_status(self):
         # Initialize with Simple-Response defaults
-        line = self.fp.readline()
+        line = self.fp.readline(_MAXLINE + 1)
+        if len(line) > _MAXLINE:
+            raise LineTooLong("header line")
         if self.debuglevel > 0:
             print "reply:", repr(line)
         if not line:


Both Python 2 and Python 3 accept an unlimited count of HTTP headers with a maximum length of 64k each. As headers are accumulated in an list it may consume lots of memory. I suggest that we limit the maximum amount of HTTP header lines to a sane value. How does 100 sound to you?

----------
components: Library (Lib)
messages: 171240
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: httplib: header parsing is not delimited
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:32:55 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:32:55 +0000
Subject: [New-bugs-announce] [issue16038] ftplib: unlimited readline() from
	connection
Message-ID: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This bug is similar to #16037.

The ftplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious FTP server can trick the ftplib module to consume large amounts of memory.

Suggestion:
The ftplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

----------
components: Library (Lib)
messages: 171241
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: ftplib: unlimited readline() from connection
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:36:10 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:36:10 +0000
Subject: [New-bugs-announce] [issue16039] imaplib: unlimited readline() from
	connection
Message-ID: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This bug is similar to #16037 and a modified copy of #16038.

The imaplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious IMAP server can trick the imaplib module to consume large amounts of memory.

Suggestion:
The imaplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

----------
components: Library (Lib)
messages: 171242
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: imaplib: unlimited readline() from connection
type: resource usage

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

From report at bugs.python.org  Tue Sep 25 12:38:45 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:38:45 +0000
Subject: [New-bugs-announce] [issue16040] nntplib: unlimited readline() from
	connection
Message-ID: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This bug is similar to #16037 and a modified copy of #16038.

The nntplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious news server can trick the nntplib module to consume large amounts of memory.

Suggestion:
The nntplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

----------
components: Library (Lib)
messages: 171243
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: nntplib: unlimited readline() from connection
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:39:23 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:39:23 +0000
Subject: [New-bugs-announce] [issue16041] poplib: unlimited readline() from
	connection
Message-ID: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This bug is similar to #16037 and a modified copy of #16038.

The poplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious POP3 server can trick the poplib module to consume large amounts of memory.

Suggestion:
The poplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

----------
components: Library (Lib)
messages: 171244
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: poplib: unlimited readline() from connection
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:40:09 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:40:09 +0000
Subject: [New-bugs-announce] [issue16042] smtplib: unlimited readline() from
	connection
Message-ID: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This bug is similar to #16037 and a modified copy of #16038.

The smtplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious SMTP server can trick the smtplib module to consume large amounts of memory.

Suggestion:
The smtplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

----------
components: Library (Lib)
messages: 171245
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: smtplib: unlimited readline() from connection
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 12:52:06 2012
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 25 Sep 2012 10:52:06 +0000
Subject: [New-bugs-announce] [issue16043] xmlrpc: gzip_decode has unlimited
	read()
Message-ID: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The xmlrpc client library is the only stdlib module that has a gzip decompression handler for compressed HTTP streams. The gzip_decode() function decompresses HTTP bodies that are compressed and sent with Accept-Encoding: x-gzip.

A malicious server can send a specially prepared HTTP request that can consume lots of memory. For example 1 GB of \0 bytes is less than 1 MB of gzip data.

Suggestion:
The gzip_decode() should only decode a sane amount of bytes (for example 50 MB) and raise an exception when more data is to be read.

----------
components: Library (Lib)
messages: 171246
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: xmlrpc: gzip_decode has unlimited read()
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 25 14:06:05 2012
From: report at bugs.python.org (kirpit)
Date: Tue, 25 Sep 2012 12:06:05 +0000
Subject: [New-bugs-announce] [issue16044] xml.etree.ElementTree.Element:
	append method iterator	param is broken
Message-ID: <1348574765.38.0.275058753456.issue16044@psf.upfronthosting.co.za>


New submission from kirpit:

xml.etree.ElementTree.Element's append method doesn't support iterator/sequence parameters as it's supposed to, for the version 1.3.0.

Python 2.7.3 (default, Sep 14 2012, 09:52:31) 
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as et
>>> et.VERSION
'1.3.0'
>>> root = et.Element('root')
>>> sublist = [et.Element('sub'), et.Element('sub')]
>>> root.append(sublist)
>>> et.tostring(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1127, in tostring
    ElementTree(element).write(file, encoding, method=method)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 818, in write
    self._root, encoding, default_namespace
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 878, in _namespaces
    for elem in iterate():
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 477, in iter
    for e in e.iter(tag):
AttributeError: 'list' object has no attribute 'iter'

>>> root = et.Element('root')
>>> root.append(iter(sublist))
>>> et.tostring(root)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1127, in tostring
    ElementTree(element).write(file, encoding, method=method)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 818, in write
    self._root, encoding, default_namespace
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 878, in _namespaces
    for elem in iterate():
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 477, in iter
    for e in e.iter(tag):
AttributeError: 'listiterator' object has no attribute 'iter'

----------
assignee: ronaldoussoren
components: Macintosh, XML
messages: 171255
nosy: kirpit, ronaldoussoren
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element: append method iterator param is broken
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 25 15:28:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 25 Sep 2012 13:28:42 +0000
Subject: [New-bugs-announce] [issue16045] create some unit tests for
	built-in int()
Message-ID: <1348579722.08.0.96812684384.issue16045@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The built-in function int() does not seem to have any basic unit tests (e.g. in test_builtin).  It would be good to add some.

Some cases (including edge cases) for possible inclusion:

int()
int(base='foo')  # no exception; returns 0
int(x=5)
int(x=5, base=10)  # raises TypeError
int(5.8)  # test truncation towards zero
int(-5.8)  # ditto
int('5.8')  # raises ValueError

Both positional and keyword argument combinations should be tested.

----------
components: Library (Lib)
keywords: easy
messages: 171270
nosy: chris.jerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: create some unit tests for built-in int()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Sep 25 16:02:05 2012
From: report at bugs.python.org (Marco Buttu)
Date: Tue, 25 Sep 2012 14:02:05 +0000
Subject: [New-bugs-announce] [issue16046] python -O does not find *.pyo files
Message-ID: <1348581725.98.0.841014002753.issue16046@psf.upfronthosting.co.za>


New submission from Marco Buttu:

$ echo "print(__file__)" > foo.py
$ python3.3 -O -m foo
/home/marco/temp/foo.py
$ ls
foo.py  __pycache__
$ rm foo.py
$ mv __pycache__/foo.cpython-33.pyo foo.pyo
$ rm __pycache__ -r
$ ls
foo.pyo
# The following works in Python3.2, but not in Python 3.3.0rc3
$ python3.3 -O -m foo
/usr/local/bin/python3.3: No module named foo

----------
components: Interpreter Core
messages: 171276
nosy: mbuttu
priority: normal
severity: normal
status: open
title: python -O does not find *.pyo files
versions: Python 3.3

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

From report at bugs.python.org  Tue Sep 25 18:28:00 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 25 Sep 2012 16:28:00 +0000
Subject: [New-bugs-announce] [issue16047] Tools/freeze no longer works in
	Python 3
Message-ID: <1348590480.55.0.440432620482.issue16047@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The freeze tool used for compiling Python binaries with frozen modules no longer works with Python 3.x.

It looks like it was never updated to the various path and symbols changes introduced with PEP 3149 (ABI tags) in Python 3.2.

Even with lots of symlinks to restore the non-ABI flagged names, freezing fails with a linker error in Python 3.3:

Tools/freeze> python3 freeze.py hello.py
Tools/freeze> make
config.o:(.data+0x38): undefined reference to `PyInit__imp'
collect2: ld returned 1 exit status
make: *** [hello] Error 1

----------
components: Demos and Tools
messages: 171295
nosy: lemburg
priority: normal
severity: normal
status: open
title: Tools/freeze no longer works in Python 3
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep 25 22:06:02 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2012 20:06:02 +0000
Subject: [New-bugs-announce] [issue16048] Tutorial-classes-remarks: replace
	paragragh
Message-ID: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

(from python-list thread "data attributes override method attributes?")

"9.4. Random Remarks

Data attributes override method attributes with the same name; to avoid accidental name conflicts, which may cause hard-to-find bugs in large programs, it is wise to use some kind of convention that minimizes the chance of conflicts. Possible conventions include capitalizing method names, prefixing data attribute names with a small unique string (perhaps just an underscore), or using verbs for methods and nouns for data attributes."

The first semi-sentence is wrong. Within a class or instance attribute space, later assignments replace earlier ones. Between them, instance attributes (usually) override class attributes. The exceptions are (some? all?) special methods. One suggestion on the thread is to replace the clause with 'Instance attributes override class attributes', as that is the apparent intent, but the exception needs to be noted.

The suggested Method and _data conventions are wrong in that they contradict PEP8 style. Peter Otten suggested that the convention suggestion be shortened to "To avoid name conflicts consider using verbs for methods and nouns for data attributes".

----------
assignee: docs at python
components: Documentation
messages: 171316
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Tutorial-classes-remarks: replace paragragh
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 26 01:20:31 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 25 Sep 2012 23:20:31 +0000
Subject: [New-bugs-announce] [issue16049] Create abstract base classes by
	inheritance rather than	a direct invocation of __metaclass__
Message-ID: <1348615231.16.0.514985949274.issue16049@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Since inheritance is more commonplace and more easily understood than __metaclass__, the abc module would benefit from a simple helper class:

    class ABC(metaclass=ABCMeta):
        pass

>From a user's point-of-view, writing an abstract base call becomes simpler and clearer:

    from abc import ABC, abstractmethod

    class Vector(ABC):

        @abstractmethod
        def __iter__(self):
            pass

        def dot(self, other):
            'Compute a dot product'
            return sum(map(operator.mul, self, other))

Notice that this class seems less mysterious because it inherits from ABC rather than using __metaclass__=ABCMeta.

Also note, it has become a reasonably common practice for metaclass writers to put the __metaclass__ assignment in a class and have it get inherited rather than requiring users do the metaclass assignment themselves.

----------
components: Library (Lib)
messages: 171323
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Create abstract base classes by inheritance rather than a direct invocation of __metaclass__
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 26 02:22:35 2012
From: report at bugs.python.org (Pavel Maltsev)
Date: Wed, 26 Sep 2012 00:22:35 +0000
Subject: [New-bugs-announce] [issue16050] ctypes: callback from C++ to
	Python fails with Illegal	Instruction call
Message-ID: <1348618955.55.0.49066087682.issue16050@psf.upfronthosting.co.za>


New submission from Pavel Maltsev:

ppc_405, Linux 2.4, GCC 3.3.1

Python crashes on attempt to pass python callback function to custom C++ library under PowerPC 405. This happens because some versions of GCC (I guess below 4.1) doesn't raise __NO_FPRS__ flag if hard-floats is not supported, instead they use _SOFT_FLOAT. So we need to change

#ifndef __NO_FPRS__
to
#if (!defined(__NO_FPRS__) && !defined(_SOFT_FLOAT))

----------
components: ctypes
files: soft_float.patch
keywords: patch
messages: 171325
nosy: Opilki_Inside
priority: normal
severity: normal
status: open
title: ctypes: callback from C++ to Python fails with Illegal Instruction call
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file27309/soft_float.patch

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

From report at bugs.python.org  Wed Sep 26 03:09:47 2012
From: report at bugs.python.org (Barry Morrison)
Date: Wed, 26 Sep 2012 01:09:47 +0000
Subject: [New-bugs-announce] [issue16051] Documentation missing pipes.quote()
Message-ID: <1348621787.28.0.392137899077.issue16051@psf.upfronthosting.co.za>


New submission from Barry Morrison:

Documentation here: http://docs.python.org/library/pipes.html makes no mention of quote()

But the link to Source code: Lib/pipes.py http://hg.python.org/cpython/file/2.7/Lib/pipes.py has:


267 def quote(file):
268 """Return a shell-escaped version of the file string."""
269 for c in file:
270 if c not in _safechars:
271 break
272 else:
273 if not file:
274 return "''"
275 return file
276 # use single quotes, and put single quotes into double quotes
277 # the string $'b is then quoted as '$'"'"'b'
278 return "'" + file.replace("'", "'\"'\"'") + "'"

First _ever_ bug report, apologies if this is incorrect.

----------
assignee: docs at python
components: Documentation
messages: 171326
nosy: Barry.Morrison, docs at python
priority: normal
severity: normal
status: open
title: Documentation missing pipes.quote()
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 26 12:30:52 2012
From: report at bugs.python.org (Lars Buitinck)
Date: Wed, 26 Sep 2012 10:30:52 +0000
Subject: [New-bugs-announce] [issue16052] Typo in "What's new in 3.3"
Message-ID: <1348655452.61.0.28429874777.issue16052@psf.upfronthosting.co.za>


New submission from Lars Buitinck:

I spotted a minor typo in the "What's new" for Py 3.3, introduced yesterday. See attached patch.

----------
assignee: docs at python
components: Documentation
files: typo.hg
messages: 171333
nosy: docs at python, larsmans
priority: normal
severity: normal
status: open
title: Typo in "What's new in 3.3"
versions: Python 3.3
Added file: http://bugs.python.org/file27312/typo.hg

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

From report at bugs.python.org  Wed Sep 26 12:35:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2012 10:35:57 +0000
Subject: [New-bugs-announce] [issue16053] "strict" parameter is not
	documented in csv module
Message-ID: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

csv.Dialect.strict is not documented. However it is used in tests.

----------
messages: 171334
nosy: storchaka
priority: normal
severity: normal
status: open
title: "strict" parameter is not documented in csv module

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

From report at bugs.python.org  Wed Sep 26 16:27:33 2012
From: report at bugs.python.org (Fredy)
Date: Wed, 26 Sep 2012 14:27:33 +0000
Subject: [New-bugs-announce] [issue16054] Preferences Crashes on click
Message-ID: <1348669653.52.0.428448233738.issue16054@psf.upfronthosting.co.za>


New submission from Fredy:

Process:         Python [3627]
Path:            /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         3.2.3 (3.2.3)
Code Type:       X86-64 (Native)
Parent Process:  launchd [231]
User ID:         501

Date/Time:       2012-09-26 16:08:04.216 +0200
OS Version:      Mac OS X 10.8.2 (12C54)
Report Version:  10

Interval Since Last Report:          166823 sec
Crashes Since Last Report:           122
Per-App Interval Since Last Report:  465 sec
Per-App Crashes Since Last Report:   6
Anonymous UUID:                      622CF890-F6C9-E63C-05B2-5E66F969E543

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000024

VM Regions Near 0x24:
--> 
    __TEXT                 0000000100000000-0000000100001000 [    4K] r-x/rwx SM=COW  /Library/Frameworks/Python.framework/Versions/3.2/Resources/Python.app/Contents/MacOS/Python

Application Specific Information:
Performing @selector(preferences:) from sender NSMenuItem 0x1017a6d20

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   Tk                            	0x0000000101391e6c TkpConfigureMenuEntry + 1923
1   Tk                            	0x0000000101312ffe MenuWorldChanged + 61
2   Tk                            	0x00000001012eca99 RecomputeWidgets + 47
3   Tk                            	0x00000001012ecaa7 RecomputeWidgets + 61
4   Tk                            	0x00000001012ecaa7 RecomputeWidgets + 61
5   Tcl                           	0x000000010125ee81 TclServiceIdle + 76
6   Tcl                           	0x0000000101243432 Tcl_DoOneEvent + 329
7   Tk                            	0x000000010130d832 MapFrame + 42
8   Tcl                           	0x000000010125ee81 TclServiceIdle + 76
9   Tcl                           	0x0000000101243432 Tcl_DoOneEvent + 329
10  Tk                            	0x00000001012e3e26 Tk_TkwaitObjCmd + 555
11  Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
12  Tcl                           	0x00000001011dea9f Tcl_EvalObjv + 66
13  _tkinter.so                   	0x00000001011c268e Tkapp_Call + 190
14  org.python.python             	0x00000001000b4034 PyEval_EvalFrameEx + 29204
15  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
16  org.python.python             	0x00000001000b4167 PyEval_EvalFrameEx + 29511
17  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
18  org.python.python             	0x0000000100039d0a function_call + 186
19  org.python.python             	0x000000010000c828 PyObject_Call + 104
20  org.python.python             	0x00000001000261aa method_call + 138
21  org.python.python             	0x000000010000c828 PyObject_Call + 104
22  org.python.python             	0x000000010006dd81 slot_tp_init + 177
23  org.python.python             	0x0000000100060fe4 type_call + 212
24  org.python.python             	0x000000010000c828 PyObject_Call + 104
25  org.python.python             	0x00000001000ae0f2 PyEval_EvalFrameEx + 4818
26  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
27  org.python.python             	0x0000000100039d0a function_call + 186
28  org.python.python             	0x000000010000c828 PyObject_Call + 104
29  org.python.python             	0x00000001000ab5e7 PyEval_CallObjectWithKeywords + 87
30  _tkinter.so                   	0x00000001011c09c8 PythonCmd + 456
31  Tcl                           	0x00000001011da53b TclInvokeStringCommand + 105
32  Tcl                           	0x00000001011dd8ad TclEvalObjvInternal + 782
33  Tcl                           	0x00000001011de4bf TclEvalEx + 2183
34  Tcl                           	0x00000001011de8bd Tcl_Eval + 44
35  Tcl                           	0x00000001011de900 Tcl_GlobalEval + 45
36  Tk                            	0x000000010138c4c1 PrefsHandler + 79
37  com.apple.AppKit              	0x00007fff9a555a59 -[NSApplication sendAction:to:from:] + 342
38  com.apple.AppKit              	0x00007fff9a68b44c -[NSMenuItem _corePerformAction] + 406
39  com.apple.AppKit              	0x00007fff9a68b13a -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 133
40  com.apple.AppKit              	0x00007fff9a37846f -[NSMenu _internalPerformActionForItemAtIndex:] + 36
41  com.apple.AppKit              	0x00007fff9a3782f7 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 135
42  com.apple.AppKit              	0x00007fff9a684245 NSSLMMenuEventHandler + 342
43  com.apple.HIToolbox           	0x00007fff94e9bf0a DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1206
44  com.apple.HIToolbox           	0x00007fff94e9b3d9 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 410
45  com.apple.HIToolbox           	0x00007fff94eb11bd SendEventToEventTarget + 40
46  com.apple.HIToolbox           	0x00007fff94ee7e89 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 443
47  com.apple.HIToolbox           	0x00007fff94e8cc11 SendMenuCommandWithContextAndModifiers + 59
48  com.apple.HIToolbox           	0x00007fff94e8cbc3 SendMenuItemSelectedEvent + 254
49  com.apple.HIToolbox           	0x00007fff94e8ca4f FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 94
50  com.apple.HIToolbox           	0x00007fff94e68aab MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 605
51  com.apple.HIToolbox           	0x00007fff94e680b8 _HandleMenuSelection2 + 565
52  com.apple.AppKit              	0x00007fff9a5439c6 _NSHandleCarbonMenuEvent + 245
53  com.apple.AppKit              	0x00007fff9a465b7f _DPSNextEvent + 2073
54  com.apple.AppKit              	0x00007fff9a464ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
55  Tk                            	0x000000010139554f -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 169
56  Tk                            	0x0000000101395986 TkMacOSXEventsCheckProc + 271
57  Tcl                           	0x0000000101243412 Tcl_DoOneEvent + 297
58  _tkinter.so                   	0x00000001011bff71 Tkapp_MainLoop + 177
59  org.python.python             	0x00000001000b4034 PyEval_EvalFrameEx + 29204
60  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
61  org.python.python             	0x00000001000b4167 PyEval_EvalFrameEx + 29511
62  org.python.python             	0x00000001000b4321 PyEval_EvalFrameEx + 29953
63  org.python.python             	0x00000001000b4ffa PyEval_EvalCodeEx + 1770
64  org.python.python             	0x00000001000b530f PyEval_EvalCode + 63
65  org.python.python             	0x00000001000dc6ab PyRun_FileExFlags + 187
66  org.python.python             	0x00000001000dc979 PyRun_SimpleFileExFlags + 521
67  org.python.python             	0x00000001000f1e65 Py_Main + 3237
68  Python                        	0x0000000100000e0b 0x100000000 + 3595
69  Python                        	0x0000000100000c94 0x100000000 + 3220

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff93041d16 kevent + 10
1   libdispatch.dylib             	0x00007fff8fd30dea _dispatch_mgr_invoke + 883
2   libdispatch.dylib             	0x00007fff8fd309ee _dispatch_mgr_thread + 54

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 4:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 5:
0   libsystem_kernel.dylib        	0x00007fff93041322 __select + 10
1   Tcl                           	0x0000000101276d1e NotifierThreadProc + 558
2   libsystem_c.dylib             	0x00007fff9a1a3742 _pthread_start + 327
3   libsystem_c.dylib             	0x00007fff9a190181 thread_start + 13

Thread 6:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 7:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 8:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 9:
0   libsystem_kernel.dylib        	0x00007fff930416d6 __workq_kernreturn + 10
1   libsystem_c.dylib             	0x00007fff9a1a5eec _pthread_workq_return + 25
2   libsystem_c.dylib             	0x00007fff9a1a5cb3 _pthread_wqthread + 412
3   libsystem_c.dylib             	0x00007fff9a190171 start_wqthread + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000008  rcx: 0x0000000000000000  rdx: 0x0000000000000000
  rdi: 0x00000001017ca710  rsi: 0x0000000000000000  rbp: 0x00007fff5fbfc470  rsp: 0x00007fff5fbfc310
   r8: 0x0000000000000010   r9: 0x000000000000007f  r10: 0x0000000100440a50  r11: 0x00007fff7f98d0e0
  r12: 0x0000000000000001  r13: 0x0000000000000002  r14: 0x0000000000000001  r15: 0x00000001033c1790
  rip: 0x0000000101391e6c  rfl: 0x0000000000010246  cr2: 0x0000000000000024
Logical CPU: 0

Binary Images:
       0x100000000 -        0x100000ff7 +Python (???) <1768148D-C54D-CDEA-E308-66DD6F981E49> /Applications/Python 3.2/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x100184ff7 +org.python.python (3.2.3, [c] 2004-2012 Python Software Foundation. - 3.2.3) <C51CBDD9-D8AA-2CF6-8C0F-B3138193D6D0> /Library/Frameworks/Python.framework/Versions/3.2/Python
       0x100570000 -        0x100570fff +_bisect.so (???) <78CC2A47-24FF-F895-B747-95A8E082C933> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_bisect.so
       0x1005a1000 -        0x1005a2ff7 +_heapq.so (???) <9E377F57-15D4-FA5A-C33F-79EE16CEFFAE> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_heapq.so
       0x1005e6000 -        0x1005eefff +_socket.so (???) <139F676E-9155-AFC9-1AD3-A782BEAC8C6B> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_socket.so
       0x1005f8000 -        0x1005fafff +time.so (???) <FEFA964F-DEA4-AB47-3CDC-60ADC96AF0DF> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/time.so
       0x1007c0000 -        0x1007c3fff +select.so (???) <A93F61B7-A7BA-5EB0-A30C-BA764CD83797> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/select.so
       0x1007c9000 -        0x1007caff7 +fcntl.so (???) <56137A5B-9D40-321A-EA04-BA3BC276F687> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/fcntl.so
       0x1007cd000 -        0x1007d1fff +_struct.so (???) <4146D1DF-404C-17A5-91BD-4D0EA49CA1A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_struct.so
       0x1007d8000 -        0x1007e7fff +_pickle.so (???) <201C5209-AB7F-A512-307F-8D2F0B5BA7A9> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_pickle.so
       0x1007f1000 -        0x1007f2ff7 +_posixsubprocess.so (???) <D3BCDF7D-3760-8332-D574-6C385D481588> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_posixsubprocess.so
       0x1007f9000 -        0x1007fbff7 +_hashlib.so (???) <BA8F08DF-300B-1A18-AEE9-0FE0160ABF6E> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_hashlib.so
       0x1011bd000 -        0x1011c4ff7 +_tkinter.so (???) <885013A0-8BE8-E15A-1150-94172642D585> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_tkinter.so
       0x1011cd000 -        0x1012aafe7 +Tcl (8.5.12 - 8.5.12) <BEEA747D-37D2-E8A1-3F8A-89BFC1087A1E> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
       0x1012d6000 -        0x1013e4fef +Tk (8.5.12 - 8.5.12) <C6928E4B-8867-75D8-9E7C-2DF562FB6244> /Library/Frameworks/Tk.framework/Versions/8.5/Tk
       0x1014fc000 -        0x1014fdff7 +_random.so (???) <D676ED48-1790-C021-514E-A29775BF5CB0> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/_random.so
       0x101ac6000 -        0x101acbfe7 +math.so (???) <5EE93FAE-A0BF-5D9D-7B68-F1BA2D893EAC> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/math.so
       0x1039c1000 -        0x1039c7fe7 +array.so (???) <93D44AE8-82E4-1541-2172-0ECB419847E6> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/array.so
       0x1039ea000 -        0x1039f3fe7  libcldcpuengine.dylib (2.1.19) <50800DA2-7233-32E5-9553-A02171B68399> /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib
       0x1039fc000 -        0x1039fcff3 +cl_kernels (???) <146C2B7C-12A5-4BA2-A52F-B7A6462B8C4C> cl_kernels
       0x1065ec000 -        0x1065efff7  libCoreFSCache.dylib (24.4) <C375CAA0-F91F-3D9F-AF90-DB951BD86983> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
       0x107cc8000 -        0x107d63fef +unicodedata.so (???) <001D04E6-0D6B-34D3-1DD9-A33C55E86885> /Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/lib-dynload/unicodedata.so
       0x10a4e0000 -        0x10a57bff7  unorm8_bgra.dylib (2.1.19) <904EA51D-225A-38AF-B66C-84493C55C065> /System/Library/Frameworks/OpenCL.framework/Libraries/ImageFormats/unorm8_bgra.dylib
    0x7fff68dc4000 -     0x7fff68df893f  dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
    0x7fff8dfea000 -     0x7fff8dff0fff  libGFXShared.dylib (8.6.1) <CF55E720-1B9E-3E24-A1DA-7FA8B261CD8E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff8dff1000 -     0x7fff8dff2fff  liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib
    0x7fff8dff8000 -     0x7fff8e0cbff7  com.apple.DiscRecording (7.0 - 7000.2.4) <49FD2D2F-4F2C-39B6-877B-6E3172577D18> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
    0x7fff8e2c9000 -     0x7fff8e3c6fff  libsqlite3.dylib (138.1) <ADE9CB98-D77D-300C-A32A-556B7440769F> /usr/lib/libsqlite3.dylib
    0x7fff8e3c7000 -     0x7fff8ed57c67  com.apple.CoreGraphics (1.600.0 - 324.6) <DCC70C6E-AB6D-3457-A823-7569CB29B107> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff8f206000 -     0x7fff8f20eff7  libsystem_dnssd.dylib (379.32.1) <62AA0B84-188A-348B-8F9E-3E2DB08DB93C> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8f211000 -     0x7fff8f22efff  com.apple.openscripting (1.3.6 - 148.2) <33B87CFB-CACC-3EBC-893D-38AECB94FB8A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fff8f22f000 -     0x7fff8f4fffff  com.apple.security (7.0 - 55179.1) <639641EF-8156-3190-890C-1053658E044A> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff8f500000 -     0x7fff8f5c5ff7  com.apple.coreui (2.0 - 181.1) <83D2C92D-6842-3C9D-9289-39D5B4554C3A> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff8f724000 -     0x7fff8f75afff  libsystem_info.dylib (406.17) <4FFCA242-7F04-365F-87A6-D4EFB89503C1> /usr/lib/system/libsystem_info.dylib
    0x7fff8fa0a000 -     0x7fff8fa0cff7  libunc.dylib (25) <92805328-CD36-34FF-9436-571AB0485072> /usr/lib/system/libunc.dylib
    0x7fff8fa0d000 -     0x7fff8fa44ff7  libssl.0.9.8.dylib (47) <923945E6-C489-3406-903B-A362410753F8> /usr/lib/libssl.0.9.8.dylib
    0x7fff8fa71000 -     0x7fff8fa71fff  libOpenScriptingUtil.dylib (148.2) <B8061D13-C1B2-38D5-A723-9A98D64E67AC> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff8fa72000 -     0x7fff8fab1ff7  com.apple.QD (3.42 - 285) <8DF36FCA-C06B-30F4-A631-7BE2FF7E56D1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff8fab2000 -     0x7fff8fb1afff  libvDSP.dylib (380.6) <CD4C5EEB-9E63-30C4-8103-7A5EAEA0BE60> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff8fb1b000 -     0x7fff8fb1cff7  libSystem.B.dylib (169.3) <365477AB-D641-389D-B8F4-A1FAE9657EEE> /usr/lib/libSystem.B.dylib
    0x7fff8fb28000 -     0x7fff8fb3bff7  com.apple.LangAnalysis (1.7.0 - 1.7.0) <2F2694E9-A7BC-33C7-B4CF-8EC907DF0FEB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff8fbe5000 -     0x7fff8fc72ff7  com.apple.SearchKit (1.4.0 - 1.4.0) <C7F43889-F8BF-3CB9-AD66-11AEFCBCEDE7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff8fcbb000 -     0x7fff8fcbbfff  com.apple.ApplicationServices (45 - 45) <A3ABF20B-ED3A-32B5-830E-B37831A45A80> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff8fcbc000 -     0x7fff8fcc8fff  com.apple.CrashReporterSupport (10.8.2 - 414.3) <B1A904D2-1944-39AD-9F43-F589CEE3FCC3> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
    0x7fff8fcc9000 -     0x7fff8fcfeff7  libTrueTypeScaler.dylib (84.5) <DF2335F3-07BE-30BA-B73C-3204E95B42C3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
    0x7fff8fd2c000 -     0x7fff8fd41ff7  libdispatch.dylib (228.23) <D26996BF-FC57-39EB-8829-F63585561E09> /usr/lib/system/libdispatch.dylib
    0x7fff8fd6b000 -     0x7fff8fd6bfff  com.apple.CoreServices (57 - 57) <9DD44CB0-C644-35C3-8F57-0B41B3EC147D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff8fd6c000 -     0x7fff8fd83fff  com.apple.CFOpenDirectory (10.8 - 151.10) <FFBBA538-00B5-334E-BA5B-C8AD6CDCDA14> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff8fd84000 -     0x7fff8fe41ff7  com.apple.ColorSync (4.8.0 - 4.8.0) <6CE333AE-EDDB-3768-9598-9DB38041DC55> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff90424000 -     0x7fff90479ff7  libTIFF.dylib (845) <ADCB4683-69EB-318B-8BE7-5FDF38BCADAF> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff9047a000 -     0x7fff90487ff7  com.apple.NetAuth (4.0 - 4.0) <F5BC7D7D-AF28-3C83-A674-DADA48FF7810> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff90488000 -     0x7fff904cbfff  com.apple.RemoteViewServices (2.0 - 80.5) <F3A897C9-A277-3B56-8FB3-2BC2C10C33BF> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
    0x7fff90523000 -     0x7fff90625fff  libJP2.dylib (845) <405CAF25-0AA5-3C6B-A4A6-94471A1EDD2F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff90626000 -     0x7fff9067cfff  com.apple.HIServices (1.20 - 417) <A1129272-FEC8-350B-BA26-5A97F23C413D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff9067d000 -     0x7fff9079592f  libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib
    0x7fff9093b000 -     0x7fff90d58fff  FaceCoreLight (2.4.1) <A34C9575-C4C1-31B1-809B-7751070B4E8B> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
    0x7fff90d59000 -     0x7fff90da5ff7  libauto.dylib (185.1) <73CDC482-16E3-3FC7-9BB4-FBA2DA44DBC2> /usr/lib/libauto.dylib
    0x7fff90da9000 -     0x7fff90e03fff  com.apple.print.framework.PrintCore (8.1 - 387.1) <1FA17B75-33E6-35BD-9198-35F92E37B248> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff91735000 -     0x7fff917dbff7  com.apple.CoreServices.OSServices (557.4 - 557.4) <841878A8-6F3E-300D-8F01-444B3CC1F41D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff91ca4000 -     0x7fff91ea4fff  libicucore.A.dylib (491.11.1) <CC318A27-878A-38CE-9292-1B98353FA9C7> /usr/lib/libicucore.A.dylib
    0x7fff91ef1000 -     0x7fff91fe1ff7  com.apple.DiskImagesFramework (10.8 - 344) <3A30B9B5-5099-35E2-9DCD-C96764FA2D26> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
    0x7fff91fe2000 -     0x7fff92038ff7  com.apple.opencl (2.1.20 - 2.1.20) <AF142CA4-EA1D-31B0-A48F-AA2B75D4309E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff92039000 -     0x7fff92088ff7  libFontRegistry.dylib (100) <2E03D7DA-9B8F-31BB-8FB5-3D3B6272127F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff920bc000 -     0x7fff920d2fff  com.apple.MultitouchSupport.framework (235.28 - 235.28) <BD78B16E-9B5A-3E07-93B4-13AD1A538CAC> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff920d3000 -     0x7fff920e0fff  com.apple.AppleFSCompression (49 - 1.0) <5508344A-2A7E-3122-9562-6F363910A80E> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff920e3000 -     0x7fff9212dff7  libGLU.dylib (8.6.1) <DF45C1E3-3884-3991-B84F-F39B482E8BF8> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff92139000 -     0x7fff92173fff  com.apple.GSS (3.0 - 2.0) <0BDF8090-5EF4-3759-94DE-8521D74188AA> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff927a3000 -     0x7fff927e3fff  com.apple.MediaKit (13 - 659) <0C56D7FF-0430-3199-9952-CF8577519449> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
    0x7fff927f3000 -     0x7fff927f7ff7  com.apple.TCC (1.0 - 1) <F2F3B753-FC73-3543-8BBE-859FDBB4D6A6> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff927f8000 -     0x7fff9282efff  com.apple.DebugSymbols (98 - 98) <14E788B1-4EB2-3FD7-934B-849534DFC198> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
    0x7fff92f77000 -     0x7fff92fceff7  com.apple.ScalableUserInterface (1.0 - 1) <F1D43DFB-1796-361B-AD4B-39F1EED3BE19> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
    0x7fff9302f000 -     0x7fff9304aff7  libsystem_kernel.dylib (2050.18.24) <C0535565-35D1-31A7-A744-63D9F10F12A4> /usr/lib/system/libsystem_kernel.dylib
    0x7fff9304b000 -     0x7fff93056fff  com.apple.CommonAuth (3.0 - 2.0) <74A86DDD-57D0-3178-AB74-E1F31DBFFC39> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff93057000 -     0x7fff93131ff7  com.apple.backup.framework (1.4.1 - 1.4.1) <A3CFCA9E-717C-302D-821B-16FD35E6673F> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
    0x7fff93187000 -     0x7fff93199ff7  libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib
    0x7fff9319a000 -     0x7fff931bbff7  libCRFSuite.dylib (33) <736ABE58-8DED-3289-A042-C25AF7AE5B23> /usr/lib/libCRFSuite.dylib
    0x7fff9320c000 -     0x7fff9320ffff  com.apple.help (1.3.2 - 42) <343904FE-3022-3573-97D6-5FE17F8643BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff93210000 -     0x7fff93217fff  com.apple.NetFS (5.0 - 4.0) <82E24B9A-7742-3DA3-9E99-ED267D98C05E> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff9321a000 -     0x7fff93241fff  com.apple.framework.familycontrols (4.1 - 410) <AE49B2AB-7D2B-3D52-8E21-60EBEA1A38E6> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
    0x7fff93242000 -     0x7fff93261ff7  libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib
    0x7fff93262000 -     0x7fff932a6fff  libcups.2.dylib (327) <9B3F3321-D2BC-3195-BF20-4008FC52A390> /usr/lib/libcups.2.dylib
    0x7fff93302000 -     0x7fff93453fff  com.apple.audio.toolbox.AudioToolbox (1.8 - 1.8) <833DA682-A3C1-39E7-AEC3-9EDC734DE2A9> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff9440f000 -     0x7fff9450cff7  libxml2.2.dylib (22.3) <47B09CB2-C636-3024-8B55-6040F7829B4C> /usr/lib/libxml2.2.dylib
    0x7fff9450d000 -     0x7fff94535fff  libJPEG.dylib (845) <A32618D7-FB91-3EE2-A105-5407B2F3F8D8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff945b4000 -     0x7fff945b6fff  libquarantine.dylib (52) <4BE2E642-A14F-340A-B482-5BD2AEFD9C24> /usr/lib/system/libquarantine.dylib
    0x7fff94615000 -     0x7fff9470afff  libiconv.2.dylib (34) <FEE8B996-EB44-37FA-B96E-D379664DEFE1> /usr/lib/libiconv.2.dylib
    0x7fff94a68000 -     0x7fff94a96fff  com.apple.CoreServicesInternal (154.2 - 154.2) <3E6196E6-F3B4-316F-9E1F-13B6B9694C7E> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fff94e0d000 -     0x7fff94e4afe7  libGLImage.dylib (8.6.1) <7F31DD61-3110-3541-A9BB-035CD1262E50> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff94e54000 -     0x7fff94e62ff7  libsystem_network.dylib (77.10) <0D99F24E-56FE-380F-B81B-4A4C630EE587> /usr/lib/system/libsystem_network.dylib
    0x7fff94e63000 -     0x7fff95193ff7  com.apple.HIToolbox (2.0 - 625) <317F75F7-4B0F-35F5-89A7-F20BA60AC944> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff951d8000 -     0x7fff951ddfff  libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib
    0x7fff951fc000 -     0x7fff951fcffd  com.apple.audio.units.AudioUnit (1.8 - 1.8) <29E2C990-3617-3FA2-BDD7-DB7DF493E443> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fff9532c000 -     0x7fff95374fff  libcurl.4.dylib (69.2) <EBDBF42D-E4A6-3D05-A76B-2817D79D59E2> /usr/lib/libcurl.4.dylib
    0x7fff95375000 -     0x7fff9537ffff  com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <D803919C-3102-3515-A178-61E9C86C46A1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff95380000 -     0x7fff95380fff  com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff95381000 -     0x7fff95386fff  com.apple.OpenDirectory (10.8 - 151.10) <CF44120B-9B01-32DD-852E-C9C0E1243FC0> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff953cf000 -     0x7fff953d8fff  com.apple.CommerceCore (1.0 - 26) <997CD214-BC78-3C61-A1B8-813EA1CB9997> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
    0x7fff953d9000 -     0x7fff95400ff7  com.apple.PerformanceAnalysis (1.16 - 16) <E4888388-F41B-313E-9CBB-5807D077BDA9> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
    0x7fff958f7000 -     0x7fff95954ff7  com.apple.AE (645.3 - 645.3) <FF867ACA-8628-3E5A-8FA0-AF429B42C5D7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff95955000 -     0x7fff95959fff  com.apple.IOSurface (86.0.3 - 86.0.3) <C121DE83-ED12-3DC1-BDB3-4FCB29AB0571> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff9595a000 -     0x7fff959a9ff7  libcorecrypto.dylib (106.2) <CE0C29A3-C420-339B-ADAA-52F4683233CC> /usr/lib/system/libcorecrypto.dylib
    0x7fff959aa000 -     0x7fff95a44fff  libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff95d70000 -     0x7fff95d76fff  libmacho.dylib (829) <BF332AD9-E89F-387E-92A4-6E1AB74BD4D9> /usr/lib/system/libmacho.dylib
    0x7fff95d8e000 -     0x7fff95dbaff7  libRIP.A.dylib (324.6) <5A7EB5C2-BA60-36D7-BF41-9853F37837AA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
    0x7fff95dbb000 -     0x7fff960d2ff7  com.apple.CoreServices.CarbonCore (1037.3 - 1037.3) <DF7CABCA-F2CB-345B-8EFF-F0F4E937B7FF> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff960d3000 -     0x7fff960d3fff  com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <B5A18EE8-DF81-38DD-ACAF-7076B2A26225> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff9612c000 -     0x7fff9612efff  libCVMSPluginSupport.dylib (8.6.1) <7EFDA31E-E463-3897-A8DC-7FD266EB713E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff9612f000 -     0x7fff9613dff7  libkxld.dylib (2050.18.24) <7027CE49-007D-3553-8FFA-3E3B428B2316> /usr/lib/system/libkxld.dylib
    0x7fff9613e000 -     0x7fff96142fff  libGIF.dylib (845) <2690CE83-E934-3EF8-A30A-996EDADCE3E4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff96143000 -     0x7fff96149ff7  libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib
    0x7fff961ed000 -     0x7fff961eeff7  libsystem_sandbox.dylib (220) <3C3B03CF-C525-3CB3-8557-62E91B93AC95> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff961f0000 -     0x7fff9622bfff  com.apple.LDAPFramework (2.4.28 - 194.5) <0190B746-F684-3F43-B4D0-148EFE386CA4> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
    0x7fff9622c000 -     0x7fff9622cfff  libkeymgr.dylib (25) <CC9E3394-BE16-397F-926B-E579B60EE429> /usr/lib/system/libkeymgr.dylib
    0x7fff963b1000 -     0x7fff963e9fff  libtidy.A.dylib (15.10) <9009156B-84F5-3781-BFCB-B409B538CD18> /usr/lib/libtidy.A.dylib
    0x7fff9643a000 -     0x7fff9650cff7  com.apple.CoreText (260.0 - 275.16) <5BFC1D67-6A6F-38BC-9D90-9C712684EDAC> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff96590000 -     0x7fff965b2ff7  libxpc.dylib (140.41) <FAC04D8B-680E-325F-8F0C-DD69859D0E01> /usr/lib/system/libxpc.dylib
    0x7fff965b3000 -     0x7fff965e4ff7  com.apple.DictionaryServices (1.2 - 184.4) <054F2D6F-9CFF-3EF1-9778-25C551B616C1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff96671000 -     0x7fff969cdfff  com.apple.Foundation (6.8 - 945.11) <A5D41956-A354-3ACC-9355-BE200072223B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff969ce000 -     0x7fff969d0fff  com.apple.TrustEvaluationAgent (2.0 - 23) <A97D348B-32BF-3E52-8DF2-59BFAD21E1A3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
    0x7fff969d1000 -     0x7fff96a6bfff  com.apple.CoreSymbolication (3.0 - 87) <75F2C0DD-549A-36F6-BD9E-FB40A924344F> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
    0x7fff96a6c000 -     0x7fff96a74fff  liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib
    0x7fff96d81000 -     0x7fff96d8cff7  com.apple.bsd.ServiceManagement (2.0 - 2.0) <C12962D5-85FB-349E-AA56-64F4F487F219> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff96d8d000 -     0x7fff96e0bff7  com.apple.securityfoundation (6.0 - 55115.4) <C5461971-E455-31A6-99B8-AF80C4BC26DD> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff96e0c000 -     0x7fff96e11fff  libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib
    0x7fff96e12000 -     0x7fff96e3cff7  com.apple.CoreVideo (1.8 - 99.3) <C424838A-889C-39E5-8108-FD05C93D26A0> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff96e49000 -     0x7fff96fbdfff  com.apple.CFNetwork (596.2.3 - 596.2.3) <6A16C2BD-1035-30F9-AE96-D9E3BB54A976> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff96fc7000 -     0x7fff96fd5fff  com.apple.Librarian (1.1 - 1) <1635162F-239A-341E-83C7-710C55E254AF> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
    0x7fff96fea000 -     0x7fff96ff7fff  libbz2.1.0.dylib (29) <CE9785E8-B535-3504-B392-82F0064D9AF2> /usr/lib/libbz2.1.0.dylib
    0x7fff970ae000 -     0x7fff970c5fff  com.apple.GenerationalStorage (1.1 - 132.2) <3F5C87BD-D866-3732-8CB9-D23ED9784D6E> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
    0x7fff970c6000 -     0x7fff970c8fff  com.apple.securityhi (4.0 - 55002) <34E45C60-DC7E-3FCC-A1ED-EBF48B77C559> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff970c9000 -     0x7fff970caff7  libremovefile.dylib (23.1) <DBBFAF35-AC78-3856-92F6-6E4FD9DF14A2> /usr/lib/system/libremovefile.dylib
    0x7fff970cb000 -     0x7fff970f0ff7  libc++abi.dylib (24.4) <E7BD9363-1D25-3551-A68A-2E2FF6ABECD7> /usr/lib/libc++abi.dylib
    0x7fff970f1000 -     0x7fff9711cfff  libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib
    0x7fff9711d000 -     0x7fff9719dff7  com.apple.ApplicationServices.ATS (332 - 341.1) <BD83B039-AB25-3E3E-9975-A67DAE66988B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff97236000 -     0x7fff97258ff7  com.apple.Kerberos (2.0 - 1) <C49B8820-34ED-39D7-A407-A3E854153556> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff97259000 -     0x7fff9725bff7  com.apple.print.framework.Print (8.0 - 258) <34666CC2-B86D-3313-B3B6-A9977AD593DA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff9725c000 -     0x7fff97445fff  com.apple.CoreFoundation (6.8 - 744.12) <EF002794-DAEF-31C6-866C-E3E3AC387A9F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff97470000 -     0x7fff9749efff  com.apple.shortcut (2.2 - 2.2) <C573DB65-37FB-3DDC-AB19-525094346D9B> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
    0x7fff9749f000 -     0x7fff974a3fff  libCoreVMClient.dylib (24.4) <55F71158-ADEE-3863-92E9-4772DCEA8E31> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff975a3000 -     0x7fff975f4ff7  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <E095637C-457F-3D8F-AE32-A032F9D5A46C> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff975f5000 -     0x7fff97616fff  com.apple.Ubiquity (1.2 - 243.10) <F97D3A33-2C8B-3CFF-AF75-A74866D42853> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
    0x7fff9761c000 -     0x7fff9761dfff  libsystem_blocks.dylib (59) <D92DCBC3-541C-37BD-AADE-ACC75A0C59C8> /usr/lib/system/libsystem_blocks.dylib
    0x7fff9765b000 -     0x7fff976c8fff  com.apple.datadetectorscore (4.0 - 269.1) <C94C372B-3821-3A46-A8C2-091AB1CFF7F4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff976c9000 -     0x7fff97725ff7  com.apple.Symbolication (1.3 - 93) <F2C7E0B6-B241-3020-B30A-0636D0FA3378> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
    0x7fff97726000 -     0x7fff9772cfff  libCGXCoreImage.A.dylib (324.6) <45864BEA-B2EA-3F5F-9D04-F9832AB67A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
    0x7fff9777e000 -     0x7fff9778cfff  libcommonCrypto.dylib (60026) <2D6537F5-1B5E-305C-A1CF-D1FA80CA3939> /usr/lib/system/libcommonCrypto.dylib
    0x7fff9778d000 -     0x7fff978adfff  com.apple.desktopservices (1.7.2 - 1.7.2) <CDE8C2C2-C505-31B0-8C61-E40E4EA364A5> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fff98057000 -     0x7fff9805afff  libRadiance.dylib (845) <E8956A35-494E-3014-8B86-362D32576116> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff9805b000 -     0x7fff980dcfff  com.apple.Metadata (10.7.0 - 707.3) <A45D75C1-B311-39F0-AF4A-63FCCC098C1D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff980dd000 -     0x7fff981e8fff  libFontParser.dylib (84.5) <617A7D30-C7BC-39FC-A1FE-59367B4A5719> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff981e9000 -     0x7fff981e9fff  com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff981ea000 -     0x7fff98398fff  com.apple.QuartzCore (1.8 - 304.0) <BDC66714-F60C-386D-A773-F897D1E87AB6> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff98399000 -     0x7fff98406ff7  com.apple.framework.IOKit (2.0 - 755.18.10) <142E19DD-1C8D-3D61-ABC8-83994A73279F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff98407000 -     0x7fff98427fff  libPng.dylib (845) <C3CDD2B4-3CB0-3F6D-8411-DAAF267E952B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff98428000 -     0x7fff9852afff  libcrypto.0.9.8.dylib (47) <74F165AD-4572-3B26-B0E2-A97477FE59D0> /usr/lib/libcrypto.0.9.8.dylib
    0x7fff9852b000 -     0x7fff9853aff7  libxar.1.dylib (105) <370ED355-E516-311E-BAFD-D80633A84BE1> /usr/lib/libxar.1.dylib
    0x7fff987e3000 -     0x7fff987e4ff7  libdnsinfo.dylib (453.18) <E7595861-ECF9-336E-9901-BED2620FAA80> /usr/lib/system/libdnsinfo.dylib
    0x7fff987e5000 -     0x7fff987e9fff  libCGXType.A.dylib (324.6) <2FC25246-A69F-3F81-9AC6-0A1753E1C6A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
    0x7fff987ea000 -     0x7fff987f1fff  libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib
    0x7fff98834000 -     0x7fff98849fff  com.apple.ImageCapture (8.0 - 8.0) <17A45CE6-7DA3-36A5-B7EF-72BC136981AE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fff9884e000 -     0x7fff98851ff7  libdyld.dylib (210.2.3) <F59367C9-C110-382B-A695-9035A6DD387E> /usr/lib/system/libdyld.dylib
    0x7fff98852000 -     0x7fff9896bff7  com.apple.ImageIO.framework (3.2.0 - 845) <553B9828-A7D9-3AE4-A214-1C33417545FD> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff98a12000 -     0x7fff98a12fff  com.apple.Cocoa (6.7 - 19) <1F77945C-F37A-3171-B22E-F7AB0FCBB4D4> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff98a56000 -     0x7fff98a84ff7  libsystem_m.dylib (3022.6) <B434BE5C-25AB-3EBD-BAA7-5304B34E3441> /usr/lib/system/libsystem_m.dylib
    0x7fff98a85000 -     0x7fff98a85fff  com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff98a86000 -     0x7fff98a99ff7  libbsm.0.dylib (32) <F497D3CE-40D9-3551-84B4-3D5E39600737> /usr/lib/libbsm.0.dylib
    0x7fff98a9a000 -     0x7fff98b02ff7  libc++.1.dylib (65.1) <20E31B90-19B9-3C2A-A9EB-474E08F9FE05> /usr/lib/libc++.1.dylib
    0x7fff98b49000 -     0x7fff98b4ffff  com.apple.DiskArbitration (2.5.1 - 2.5.1) <F7DAF7CC-5893-3F06-9168-3B0192B66D15> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff98b50000 -     0x7fff98b5fff7  com.apple.opengl (1.8.6 - 1.8.6) <720CC06C-0D01-37AE-BB3D-D7F0242B262A> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff98b60000 -     0x7fff98f57fff  libLAPACK.dylib (1073.4) <D632EC8B-2BA0-3853-800A-20DA00A1091C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff98f58000 -     0x7fff9918dff7  com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff9918e000 -     0x7fff9919fff7  libsasl2.2.dylib (166) <649CAE0E-8FFE-3C60-A849-BE6300E4B726> /usr/lib/libsasl2.2.dylib
    0x7fff991a0000 -     0x7fff991abfff  libsystem_notify.dylib (98.5) <C49275CC-835A-3207-AFBA-8C01374927B6> /usr/lib/system/libsystem_notify.dylib
    0x7fff991ac000 -     0x7fff991b0fff  libpam.2.dylib (20) <C8F45864-5B58-3237-87E1-2C258A1D73B8> /usr/lib/libpam.2.dylib
    0x7fff991b1000 -     0x7fff9920efff  com.apple.audio.CoreAudio (4.1.0 - 4.1.0) <B3198BD6-EA1D-3E5E-ADD4-37D8E6B72678> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff9920f000 -     0x7fff993aafef  com.apple.vImage (6.0 - 6.0) <FAE13169-295A-33A5-8E6B-7C2CC1407FA7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff9947a000 -     0x7fff9971efff  com.apple.CoreImage (8.2.2 - 1.0.1) <930B0B23-DD84-3B0C-B5A9-C09B7068A6F0> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fff9971f000 -     0x7fff99723ff7  com.apple.CommonPanels (1.2.5 - 94) <AAC003DE-2D6E-38B7-B66B-1F3DA91E7245> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
    0x7fff99724000 -     0x7fff99731ff7  com.apple.HelpData (2.1.4 - 85) <EE68BDCC-AF2E-34D3-8E4F-87379E3A4D8E> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
    0x7fff9975b000 -     0x7fff998e1fff  libBLAS.dylib (1073.4) <C102C0F6-8CB6-3B49-BA6B-2EB61F0B2784> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff998e4000 -     0x7fff998f8fff  com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <94EDF2AB-809C-3D15-BED5-7AD45B2A7C16> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff998f9000 -     0x7fff9997bfff  com.apple.Heimdal (3.0 - 2.0) <660A6C64-4912-32C8-A332-B64164032A2D> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff9997c000 -     0x7fff9997dfff  libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff9998a000 -     0x7fff99c0dfff  com.apple.RawCamera.bundle (4.00 - 658) <6786E9E0-3197-30A3-A0F4-22A6064B3EF2> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
    0x7fff99d00000 -     0x7fff99d69fff  libstdc++.6.dylib (56) <EAA2B53E-EADE-39CF-A0EF-FB9D4940672A> /usr/lib/libstdc++.6.dylib
    0x7fff99d6a000 -     0x7fff99d89ff7  com.apple.ChunkingLibrary (2.0 - 133.2) <D2A746DE-002A-3C6C-961E-BE94E71DB835> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
    0x7fff9a025000 -     0x7fff9a0c3ff7  com.apple.ink.framework (10.8.2 - 150) <84B9825C-3822-375F-BE58-A753444FBDE2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fff9a0c4000 -     0x7fff9a175fff  com.apple.LaunchServices (539.7 - 539.7) <DA7C602E-5E01-31B8-925D-B45360CA089F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff9a182000 -     0x7fff9a18efff  libCSync.A.dylib (324.6) <2033247A-CABC-3E20-8498-7367A8F44A08> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
    0x7fff9a18f000 -     0x7fff9a25bfe7  libsystem_c.dylib (825.25) <8CBCF9B9-EBB7-365E-A3FF-2F3850763C6B> /usr/lib/system/libsystem_c.dylib
    0x7fff9a2b7000 -     0x7fff9a2faff7  com.apple.bom (12.0 - 192) <0BF1F2D2-3648-36B7-BE4B-551A0173209B> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
    0x7fff9a2fb000 -     0x7fff9a30ffff  libGL.dylib (8.6.1) <2E00615F-97F5-34EB-BE07-75A24F3C18D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff9a310000 -     0x7fff9af3dff7  com.apple.AppKit (6.8 - 1187.34) <1FF64844-EB62-3F96-AED7-6525B7CCEC23> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 2
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 3429
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=156.9M resident=114.9M(73%) swapped_out_or_unallocated=42.0M(27%)
Writable regions: Total=124.0M written=17.3M(14%) resident=24.7M(20%) swapped_out=0K(0%) unallocated=99.3M(80%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  1296K
CG image                            136K
CG shared images                   1216K
CoreImage                             4K
CoreServices                       3972K
MALLOC                             92.2M
MALLOC guard page                    48K
MALLOC_LARGE (reserved)             384K        reserved VM address space (unallocated)
Memory tag=240                        4K
Memory tag=242                       12K
OpenCL                                8K
STACK GUARD                        56.0M
Stack                              12.1M
VM_ALLOCATE                        16.1M
__DATA                             11.8M
__IMAGE                             528K
__LINKEDIT                         54.3M
__TEXT                            102.6M
__UNICODE                           544K
mapped file                        42.2M
shared memory                       308K
===========                      =======
TOTAL                             395.6M
TOTAL, minus reserved VM space    395.3M

Model: MacBookPro9,1, BootROM MBP91.00D3.B08, 4 processors, Intel Core i7, 2.6 GHz, 8 GB, SMC 2.1f170
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB
Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334448302D434B302020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (5.106.98.81.22)
Bluetooth: Version 4.0.9f33 10885, 2 service, 11 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: TOSHIBA MK7559GSXF, 750.16 GB
Serial ATA Device: OPTIARC DVD RW AD-5970H
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1a100000 / 2
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0x1a110000 / 3
USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1d100000 / 2
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0x1d180000 / 3
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0252, 0x1d183000 / 6
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x1d182000 / 5
USB Device: BRCM20702 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1d181000 / 4
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821d, 0x1d181300 / 7

----------
components: IDLE
messages: 171342
nosy: senshy11 at gmail.com
priority: normal
severity: normal
status: open
title: Preferences Crashes on click
type: crash

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

From report at bugs.python.org  Wed Sep 26 21:41:01 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 26 Sep 2012 19:41:01 +0000
Subject: [New-bugs-announce] [issue16055] incorrect error text for
	int(base=1000, x='1')
Message-ID: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The following error text is incorrect in at least one way:

>>> int(base=1000, x='1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: int() arg 2 must be >= 2 and <= 36

The *base* argument can also be 0.  Secondly, the text should probably say "base arg" instead of "arg 2" since 1000 is not in position 2.

The 2.7 code does not have the second issue:

>>> int(base=1000, x='1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: int() base must be >= 2 and <= 36

----------
components: Library (Lib)
keywords: easy
messages: 171357
nosy: chris.jerdonek, ezio.melotti
priority: normal
severity: normal
stage: test needed
status: open
title: incorrect error text for int(base=1000, x='1')
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 26 22:34:17 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Sep 2012 20:34:17 +0000
Subject: [New-bugs-announce] [issue16056] shadowed test names in std lib
	regression tests
Message-ID: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The attached script, named find_duplicate_test_names.py, prints
duplicate regression test method names in a given directory tree.
Running this script on the standard library test suite shows few
duplicates, see below.  It means that some of those tests are not
run while they are probably meant to be.

Here is find_duplicate_test_names.py output on the default branch:

$ ./python find_duplicate_test_names.py Lib/test
Duplicate test method names:
Lib/test/test_types.py: <module>.ClassCreationTests.test_new_class_exec_body
Lib/test/test_heapq.py: <module>.TestErrorHandling.test_get_only
Lib/test/test_complex.py: <module>.ComplexTest.test_truediv
Lib/test/test_webbrowser.py: <module>.OperaCommandTest.test_open_new
Lib/test/test_dis.py: <module>.DisTests.test_big_linenos
Lib/test/test_dis.py: <module>.DisTests.test_dis_object
Lib/test/test_import.py: <module>.ImportTests.test_import_name_binding
Lib/test/test_email/test_email.py: <module>.TestQuopri.test_encode_one_long_line
Lib/test/test_email/test_email.py: <module>.TestLongHeaders.test_splitter_split_on_punctuation_only_if_fws

----------
components: Library (Lib)
files: find_duplicate_test_names.py
messages: 171361
nosy: xdegaye
priority: normal
severity: normal
status: open
title: shadowed test names in std lib regression tests
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27315/find_duplicate_test_names.py

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

From report at bugs.python.org  Wed Sep 26 23:40:43 2012
From: report at bugs.python.org (Justin Lebar)
Date: Wed, 26 Sep 2012 21:40:43 +0000
Subject: [New-bugs-announce] [issue16057] Subclasses of JSONEncoder should
	not be insturcted to	call JSONEncoder.decode
Message-ID: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za>


New submission from Justin Lebar:

The JSONEncoder documentation says we can implement our own encoder as:

  >>> class ComplexEncoder(json.JSONEncoder):
  ...     def default(self, obj):
  ...         if isinstance(obj, complex):
  ...             return [obj.real, obj.imag]
  ...         return json.JSONEncoder.default(self, obj)

Later on, we give the following example of how to implement the default method in a subclass of json.JSONEncoder:

  def default(self, o):
  try:
      iterable = iter(o)
  except TypeError:
      pass
  else:
      return list(iterable)
  return JSONEncoder.default(self, o)

These are both incorrect, as a quick reading of the source will reveal.  JSONEncoder.default() throws for all input values.  We should s/JSONEncoder.default/JSONEncoder.encode/ here, I think.

----------
assignee: docs at python
components: Documentation
messages: 171363
nosy: Justin.Lebar, docs at python
priority: normal
severity: normal
status: open
title: Subclasses of JSONEncoder should not be insturcted to call JSONEncoder.decode
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 02:18:53 2012
From: report at bugs.python.org (Robert Collins)
Date: Thu, 27 Sep 2012 00:18:53 +0000
Subject: [New-bugs-announce] [issue16058] ConfigParser no longer deepcopy
	compatible in 2.7
Message-ID: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za>


New submission from Robert Collins:

In 2.6 deepcopy(ConfigParser) worked, in 2.7 it doesn't due to the _optcre variable which is a compiled regex pattern.

----------
components: Library (Lib)
messages: 171364
nosy: rbcollins
priority: normal
severity: normal
status: open
title: ConfigParser no longer deepcopy compatible in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 06:37:07 2012
From: report at bugs.python.org (Ye Yuan)
Date: Thu, 27 Sep 2012 04:37:07 +0000
Subject: [New-bugs-announce] [issue16059] Serialize MD5 computation-state
	and resume later
Message-ID: <1348720627.28.0.14858065839.issue16059@psf.upfronthosting.co.za>


New submission from Ye Yuan:

Serialize/deserialize md5 context. Pseudocode:

import md5
# Start hash generation
m = md5.new()
m.update("Content")

# Serialize m
serialized_m = serialize(m)

# In another function/machine, deserialize m
# and continue hash generation
m2 = deserialize(serialized_m)
m2.update("More content")
m2.digest() 

There are C++ lib but no Python one.

----------
components: Library (Lib)
messages: 171367
nosy: Ye.Yuan
priority: normal
severity: normal
status: open
title: Serialize MD5 computation-state and resume later
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 10:46:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2012 08:46:58 +0000
Subject: [New-bugs-announce] [issue16060] Double decref and dereferencing
	after decref in int()
Message-ID: <1348735618.32.0.1069610095.issue16060@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In function convert_integral_to_int() in file Objects/abstract.c integral double decrefed and dereferenced after decrefing if returned value of __int__() is not int. Python 3.3 only affected.

Here is a patch.

----------
components: Interpreter Core
files: float2int_dbl_decref.patch
keywords: patch
messages: 171371
nosy: benjamin.peterson, storchaka
priority: normal
severity: normal
status: open
title: Double decref and dereferencing after decref in int()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file27316/float2int_dbl_decref.patch

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

From report at bugs.python.org  Thu Sep 27 18:03:07 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 27 Sep 2012 16:03:07 +0000
Subject: [New-bugs-announce] [issue16061] performance regression in string
	replace for 3.3
Message-ID: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

Quoting Steven D'Aprano on c.l.p.

"But add a call to replace, and things are very different:

[steve at ando ~]$ python2.7 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 9.3 usec per loop
[steve at ando ~]$ python3.2 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 5.43 usec per loop
[steve at ando ~]$ python3.3 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 18.3 usec per loop


Three times slower, even for pure-ASCII strings. I get comparable results for Unicode. Notice how slow Python 2.7 is:

[steve at ando ~]$ python2.7 -m timeit -s "s = u'?'*1000" "s.replace(u'?', u'a')"
10000 loops, best of 3: 65.6 usec per loop
[steve at ando ~]$ python3.2 -m timeit -s "s = '?'*1000" "s.replace('?', 'a')"
100000 loops, best of 3: 2.79 usec per loop
[steve at ando ~]$ python3.3 -m timeit -s "s = '?'*1000" "s.replace('?', 'a')"
10000 loops, best of 3: 23.7 usec per loop

Even with the performance regression, it is still over twice as fast as
Python 2.7.

Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not.

If anyone else can confirm similar results, I think this should be raised as a performance regression.

Quoting Serhiy Storchaka in response.

"Yes, I confirm, it's a performance regression. It should be avoidable.
Almost any PEP393 performance regression can be avoided. At least for
such corner case. Just no one has yet optimized this case."

----------
messages: 171378
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: performance regression in string replace for 3.3
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 27 18:08:14 2012
From: report at bugs.python.org (ABR)
Date: Thu, 27 Sep 2012 16:08:14 +0000
Subject: [New-bugs-announce] [issue16062] Socket closed prematurely in
	httplib for https
Message-ID: <1348762094.47.0.227336838763.issue16062@psf.upfronthosting.co.za>


New submission from ABR:

When attempting to use basic auth over https with a server that sends 401 and closes the connection as soon as the headers missing auth are received, the process aborts with a broken pipe when (presumably) trying to send the POST body.

session = requests.session(auth=(USER, PASSWORD), verify=False)
resp = session.post('https://foo.com/something')
  --> requests.exceptions.ConnectionError: [Errno 32] Broken pipe

----------
components: Library (Lib)
messages: 171379
nosy: ABR
priority: normal
severity: normal
status: open
title: Socket closed prematurely in httplib for https
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 19:21:13 2012
From: report at bugs.python.org (Adam Glenn)
Date: Thu, 27 Sep 2012 17:21:13 +0000
Subject: [New-bugs-announce] [issue16063] HMAC trans_5C is a string,
	causing a TypeError
Message-ID: <1348766473.89.0.982631739774.issue16063@psf.upfronthosting.co.za>


New submission from Adam Glenn:

When passing 2 unicode objects to hmac.new() I'm getting "TypeError: character mapping must return integer, None or unicode" I've tried this using hashlib.sha1 and hashlib.md5 and the behavior is the same. What I think is happening is that the trans_5C join at the top of this module is a string so it's causing the type error when I try to generate the new hmac object at line 72.

----------
components: None
messages: 171384
nosy: Adam.Glenn
priority: normal
severity: normal
status: open
title: HMAC trans_5C is a string, causing a TypeError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 20:41:20 2012
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 27 Sep 2012 18:41:20 +0000
Subject: [New-bugs-announce] [issue16064] unittest -m claims executable is
	"python", not "python3"
Message-ID: <1348771280.27.0.553005427274.issue16064@psf.upfronthosting.co.za>


New submission from Larry Hastings:

I wrote the following script called "bonkers.py":
--
    import sys
    print(sys.argv[0])
--

then ran
    % python3 -m unittest bonkers

It printed
--
    ['python -m unittest', 'bonkers']
--

Shouldn't it say "python3", not "python"?  Maybe it should use sys.executable?  (Though that gets tricky if there are spaces in the filename.)

----------
assignee: michael.foord
components: Library (Lib)
messages: 171387
nosy: larry, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest -m claims executable is "python", not "python3"
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep 27 21:15:19 2012
From: report at bugs.python.org (Ron Hubbard)
Date: Thu, 27 Sep 2012 19:15:19 +0000
Subject: [New-bugs-announce] [issue16065] Python/distutils setup.py: passing
	--prefix / makes	--root ignored
Message-ID: <1348773319.59.0.614057803377.issue16065@psf.upfronthosting.co.za>


New submission from Ron Hubbard:

setup.py loses the DESTDIR aka --root iff "/" is passed as prefix


http://seclists.org/nmap-dev/2012/q3/1025

I can reproduce this now, but only with a prefix of "/". For example,
this works:

$ python setup.py install --prefix "/a" --root "/home/david/destdir"
copying build/scripts-2.7/ndiff -> /home/david/destdir/a/bin

But this doesn't:

$ python setup.py install --prefix "/" --root "/home/david/destdir"
copying build/scripts-2.7/ndiff -> /bin

This looks like a Python/distutils bug.


the same seems to happen on python install:
when installing python 2.7.2, "2to3", "idle", "pydoc" and "smptd.py" are installed into /bin rather than into the chosen destdir

./python -E ./setup.py install \
        --prefix=/ \
        --install-scripts=//bin \
        --install-platlib=//lib/python2.7/lib-dynload \
        --root=//opt/python/
[...]
running install
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers


running install_scripts
copying build/scripts-2.7/smtpd.py -> /bin
copying build/scripts-2.7/idle -> /bin
copying build/scripts-2.7/pydoc -> /bin
copying build/scripts-2.7/2to3 -> /bin
changing mode of /bin/smtpd.py to 755
changing mode of /bin/idle to 755
changing mode of /bin/pydoc to 755
changing mode of /bin/2to3 to 755
running install_egg_info
Writing /lib/python2.7/lib-dynload/Python-2.7.2-py2.7.egg-info
if test -f //opt/python//bin/python -o -h //opt/python//bin/python; \
then rm -f //opt/python//bin/python; \
else true; \
fi
(cd //opt/python//bin; ln python2.7 python)
rm -f //opt/python//bin/python-config
(cd //opt/python//bin; ln -s python2.7-config python-config)
test -d //opt/python//lib/pkgconfig || /bin/install -c -d -m 755 //opt/python//lib/pkgconfig
rm -f //opt/python//lib/pkgconfig/python.pc
[snip]

----------
components: Build
messages: 171389
nosy: arschficker
priority: normal
severity: normal
status: open
title: Python/distutils setup.py: passing --prefix / makes --root ignored
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 23:50:48 2012
From: report at bugs.python.org (Alexander Martin)
Date: Thu, 27 Sep 2012 21:50:48 +0000
Subject: [New-bugs-announce] [issue16066] Truncated POST data in CGI script
	on Windows 7
Message-ID: <1348782648.4.0.8522398728.issue16066@psf.upfronthosting.co.za>


New submission from Alexander Martin:

POST data is truncated randomly when sent to a python script running on a simple python CGI server on Windows 7 with Python 3.2.3.

The same server and script files run successfully on MAC OSX 10.8 with Python 3.2.3. A similar server (adapted for lower Python version) and the same script file do work fine on Windows 7 with Python 2.7.2. 

Steps to reproduce: Attached zip contains server script, HTML file and Python script, that receives an uploaded file and saves it to disk. Upload an image file and submit the form inside the HTML file to Python script. Repeat form submission multiple times. In more than 50% of test cases, the uploaded file will not be completely available inside the Python script. That means size of the same uploaded file varies with each POST request. Additionally, the Python server will reset the HTTP connection sometimes.

----------
components: Windows
files: Truncated_POST_data_in_CGI_script_on_Win7.zip
messages: 171394
nosy: Alexander.Martin, brian.curtin, tim.golden
priority: normal
severity: normal
status: open
title: Truncated POST data in CGI script on Windows 7
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file27322/Truncated_POST_data_in_CGI_script_on_Win7.zip

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

From report at bugs.python.org  Fri Sep 28 03:49:50 2012
From: report at bugs.python.org (Edward Brey)
Date: Fri, 28 Sep 2012 01:49:50 +0000
Subject: [New-bugs-announce] [issue16067] UAC prompt for installation shows
	temporary file name
Message-ID: <1348796990.29.0.204354546612.issue16067@psf.upfronthosting.co.za>


New submission from Edward Brey:

When installing on Windows, the UAC prompt shows a temporary random file name for the MSI file. To solve this, use the /d switch with  signtool when signing the MSI file.

Cf. http://stackoverflow.com/q/4315840

----------
components: Installation
messages: 171398
nosy: breyed
priority: normal
severity: normal
status: open
title: UAC prompt for installation shows temporary file name
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep 28 05:02:34 2012
From: report at bugs.python.org (Paul Wiseman)
Date: Fri, 28 Sep 2012 03:02:34 +0000
Subject: [New-bugs-announce] [issue16068] with statement executes
	type(obj).__exit__ rather than	getattr(obj, "__exit__")
Message-ID: <1348801354.79.0.991137546164.issue16068@psf.upfronthosting.co.za>


New submission from Paul Wiseman:

I found this behaviour today and thought it was weird so asked the question on SO here http://stackoverflow.com/questions/12632894/why-doesnt-getattr-work-with-exit/12632972#12632972

basically if I attributes are returned dynamically, they seem to get overlooked by the code that runs the with statements.

>>> class FileHolder(object):
...    def __init__(self,*args,**kwargs):
...        self.f= file(*args,**kwargs)
...    def __getattr__(self,item):
...        return getattr(self.f,item)
...
>>> a= FileHolder("a","w")
>>> a.write
<built-in method write of file object at 0x018D75F8>
>>> with a as f:
...   print f
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__
>>> a.__exit__
<built-in method __exit__ of file object at 0x018D75F8>

----------
components: Library (Lib)
messages: 171399
nosy: Paul.Wiseman
priority: normal
severity: normal
status: open
title: with statement executes type(obj).__exit__ rather than getattr(obj,"__exit__")
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 05:08:13 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 03:08:13 +0000
Subject: [New-bugs-announce] [issue16069] packaging shows up on
	docs.python.org/dev
Message-ID: <1348801693.29.0.778297350134.issue16069@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Date: Tue, 11 Sep 2012 16:20:54 +0200
To: docs at python.org
Subject: [docs] packaging documentation should be removed

docs.python.org/dev still carries documentation for packaging, despite the package
having been removed. http://docs.python.org/dev/library/packaging.html has
"3.3.0a4 Documentation" in the footer, so I presume that the page is a leftover.
Google returns results which point to the obsolete page, which is misleading.

(from http://mail.python.org/pipermail/docs/2012-September/010519.html )

----------
assignee: docs at python
components: Documentation
messages: 171400
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
status: open
title: packaging shows up on docs.python.org/dev
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 28 05:19:04 2012
From: report at bugs.python.org (HCT)
Date: Fri, 28 Sep 2012 03:19:04 +0000
Subject: [New-bugs-announce] [issue16070] Structure and native Structure
	(LittleEndianStructure on	Windows) supports __slots__,
	but BigEndianStructure doesn't
Message-ID: <1348802344.39.0.86334855376.issue16070@psf.upfronthosting.co.za>


New submission from HCT:

using official CPython 3.2.3 with a simple demonstration script (attached) to demonstrate inconsistency between ctypes structures

from ctypes import *

class cbs( BigEndianStructure ):
    __slots__ = tuple()
    def __init__( self, *args, **kw ):
        super().__init__( *args, **kw )
        self.a = 11

class cls( LittleEndianStructure ):
    __slots__ = tuple()
    def __init__( self, *args, **kw ):
        super().__init__( *args, **kw )
        self.a = 11

class cs( Structure ):
    __slots__ = tuple()
    def __init__( self, *args, **kw ):
        super().__init__( *args, **kw )
        self.a = 11

try :
    cbs1=cbs()
except AttributeError as e:
    print(e)

try :
    cls1=cls()
except AttributeError as e:
    print(e)

try :
    cs=cs()
except AttributeError as e:
    print(e)



yields

'cls' object has no attribute 'a'
'cs' object has no attribute 'a'



I expect cbs to throw error too, but itwent through the initalization and silently ignored the __slots__ defined in the class

----------
components: ctypes
files: slots_test.py
messages: 171402
nosy: hct
priority: normal
severity: normal
status: open
title: Structure and native Structure (LittleEndianStructure on Windows) supports __slots__, but BigEndianStructure doesn't
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file27323/slots_test.py

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

From report at bugs.python.org  Fri Sep 28 05:21:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 03:21:28 +0000
Subject: [New-bugs-announce] [issue16071] fix link to email.message.Message
	in mailbox docs
Message-ID: <1348802488.29.0.674477031086.issue16071@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

> Date: Thu, 13 Sep 2012 00:28:20 -0700
> To: docs at python.org
> Subject: [docs] Bug in documentation for mailbox module
>
> I think I may have found a minor bug in the documentation for the
> mailbox module, at:
>
> http://docs.python.org/library/mailbox.html
>
> Right at the beginning of section 18.4.2. ("Message objects"), when
> describing the mailbox.Message class, is the following:
>
> "A subclass of the email.Message module?s *Message*. Subclasses of
> mailbox.Message add mailbox-format-specific state and behavior."
>
> The word "Message" indicated above with asterisks is a hyperlink to:
>
> http://docs.python.org/library/mailbox.html#mailbox.Message
>
> I think it should instead link to:
>
> http://docs.python.org/library/email.message.html#email.message.Message

(from: http://mail.python.org/pipermail/docs/2012-September/010520.html )

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 171403
nosy: barry, chris.jerdonek, docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: fix link to email.message.Message in mailbox docs
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 05:28:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 03:28:48 +0000
Subject: [New-bugs-announce] [issue16072] fix documentation of
	string.replace() signature
Message-ID: <1348802928.91.0.483315900162.issue16072@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

> Date: Thu, 13 Sep 2012 09:42:47 -0400
> To: <docs at python.org>
> Subject: [docs] Problem with the documentation for string.replace
>
> >From http://docs.python.org/library/string.html
>
> string.replace(str, old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace>
> Return a copy of string str with all occurrences of substring old replaced by new. If the optional argument maxreplace is given, the first maxreplace occurrences are replaced.
>
> it would appear this needs to be
> string.replace(old, new[, maxreplace])?<http://docs.python.org/library/string.html#string.replace>

(from: http://mail.python.org/pipermail/docs/2012-September/010521.html )

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 171404
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: fix documentation of string.replace() signature
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 05:50:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 03:50:24 +0000
Subject: [New-bugs-announce] [issue16073] fix map() statement in list
	comprehension example
Message-ID: <1348804224.11.0.798375217467.issue16073@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

> Date: Thu, 20 Sep 2012 15:14:36 -0400
> To: docs at python.org
> Subject: [docs] map objects are not lists
>
> 5.1.3. List Comprehensions<http://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions>
>
> List comprehensions provide a concise way to create lists. Common
> applications are to make new lists where each element is the result of some
> operations applied to each member of another sequence or iterable, or to
> create a subsequence of those elements that satisfy a certain condition.
>
> For example, assume we want to create a list of squares, like:
>>>>
>
>>>> squares = []>>> for x in range(10):...     squares.append(x**2)...>>> squares[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>
> We can obtain the same result with:
>
> squares = [x**2 for x in range(10)]
>
> This is also equivalent to squares = map(lambda x: x**2, range(10)), but
> it?s more concise and readable.
>
>
> I think that the last sentence above should read:
>
> squares = list(map(lambda x: x**2, range(10)))
>
> In other words, the map function returns a map object, not a list object,
> so the list() function needs to be used to convert it to something that is
> truly equivalent to the previous definitions of "squares".  (In case it
> matters, I am using Python-3.3.0rc2 on RHEL 6.3.)

(from http://mail.python.org/pipermail/docs/2012-September/010525.html )

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 171405
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: fix map() statement in list comprehension example
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 28 10:13:20 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 28 Sep 2012 08:13:20 +0000
Subject: [New-bugs-announce] [issue16074] bad error in rename
Message-ID: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>


New submission from Glenn Linderman:

I've been using 3.3.0b1 for development, with mostly no problems, but today I was surprised and confused by an error message. It is an attempt to be an improvement over 3.2, giving the filename that os.rename cannot find... but instead, it gives the one it is renaming to.

So I quickly upgraded to 3.3.0rc3, and it contains the same error.

----------
components: Windows
files: test93.py
messages: 171410
nosy: v+python
priority: normal
severity: normal
status: open
title: bad error in rename
versions: Python 3.3
Added file: http://bugs.python.org/file27324/test93.py

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

From report at bugs.python.org  Fri Sep 28 10:33:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 08:33:11 +0000
Subject: [New-bugs-announce] [issue16075] incoming.cia hook error when
	pushing commits
Message-ID: <1348821191.61.0.603440976272.issue16075@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

When pushing commits to hg.python.org, I got the following error re: the "incoming.cia" hook:

$ hg push ssh://hg at hg.python.org/cpython
pushing to ssh://hg at hg.python.org/cpython
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 2 changesets with 4 changes to 2 files
remote: buildbot: change(s) sent successfully
remote: sent email to roundup at report at bugs.python.org
remote: notified python-checkins at python.org of incoming changeset 9205277bc008
remote: error: incoming.cia hook raised an exception: <ProtocolError for cia.vc/RPC2: 404 Not Found>
remote: notified python-checkins at python.org of incoming changeset 6ccb04c4cbae
remote: error: incoming.cia hook raised an exception: <ProtocolError for cia.vc/RPC2: 404 Not Found>

----------
messages: 171414
nosy: chris.jerdonek, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: incoming.cia hook error when pushing commits

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

From report at bugs.python.org  Fri Sep 28 10:54:59 2012
From: report at bugs.python.org (=?utf-8?q?Einar_Fl=C3=B8ystad_D=C3=B8rum?=)
Date: Fri, 28 Sep 2012 08:54:59 +0000
Subject: [New-bugs-announce] [issue16076] xml.etree.ElementTree.Element is
	no longer pickleable
Message-ID: <1348822499.83.0.756048401766.issue16076@psf.upfronthosting.co.za>


New submission from Einar Fl?ystad D?rum:

The xml.etree.ElementTree.Element class is no longer pickleable in Python 3.3.0rc3 . 

This is a regression from Python 3.2 where the Element class was pickleable, while the xml.etree.cElementTree.Element was not. So this is probably related to switching the ElementTree implementation in Python 3.3.

I've looked at the "what's new" documentation in Python 3.3, and there was nothing that indicated that the ElemenTree switchover would give this kind of issues.  

I've run into this issues because I use the multiprocessing module to pass parsed XML documents between processes, and when I can't pickle Element objects. This stops working. 

You can reproduce the issue with the following code:
import pickle
from xml.etree.ElementTree import Element

print(pickle.dumps(Element("foo")))

----------
components: Library (Lib)
messages: 171418
nosy: einarfd
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.Element is no longer pickleable
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 28 10:55:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 28 Sep 2012 08:55:52 +0000
Subject: [New-bugs-announce] [issue16077] fix code example in docs for
	built-in reduce()
Message-ID: <1348822552.23.0.324199631114.issue16077@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

> Date: Thu, 6 Sep 2012 20:38:21 +0800
> To: docs at python.org
> Subject: [docs] There is bug about the built-in function reduce in the
>         document
>
> I found a bug in the document about reduce :
> http://docs.python.org/library/functions.html#reduce
>
> Here is the patch:
> def reduce(function, iterable, initializer=None):
>     it = iter(iterable)
>     if initializer is None:
>         try:
>             initializer = next(it)
>         except StopIteration:
>             raise TypeError('reduce() of empty sequence with no initial
> value')
>     accum_value = initializer
> -    for x in iterable:
> +   for x in it:
>         accum_value = function(accum_value, x)
>     return accum_value
>
> It duplicated the first element of iterable
>
> For example:
> In [4]: reduce(lambda x,y:x+y, [1,2,3,4])
> Out[4]: 10
>
> In [5]: docreduce.reduce(lambda x,y:x+y ,[1,2,3,4])
> Out[5]: 11

(from: http://mail.python.org/pipermail/docs/2012-September/010513.html and
  http://mail.python.org/pipermail/docs/2012-September/010526.html )

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 171419
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: fix code example in docs for built-in reduce()
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 12:11:15 2012
From: report at bugs.python.org (Sasa Banjac)
Date: Fri, 28 Sep 2012 10:11:15 +0000
Subject: [New-bugs-announce] [issue16078] Calendar.leapdays(y1,y2) bug
Message-ID: <1348827075.77.0.28788504227.issue16078@psf.upfronthosting.co.za>


New submission from Sasa Banjac:

Hello!
I am using the calendar.leapdays(y1,y2) function. It should return the number of leap years betwwen y1 and y2 (exclusive). However the function still cant process mutliple centuries.
Example: between 1900 and 2000 we have 24 leap years:
1904,08,12,16,20,24,28,32,36,40,44,48,52,56,60,64,68,72,76,80,84,88,92,96
leapdays(1900,2000) returns 24 -> OK
however
leapdays(1899,2000) returns also 24 NOT OK
leapdays(1899,2001) returns 25 NOT OK
leapdays(1900,2001) returns 25 OK

This means that the function has a problem with the lower boundary
If I try to calculate the number of leap days in a larger interval of years, the error is considerable:
leapdays(1,2001) returns 485
But 485 * 4 = 1940

----------
components: Library (Lib)
messages: 171427
nosy: sbanjac
priority: normal
severity: normal
status: open
title: Calendar.leapdays(y1,y2) bug
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 12:15:38 2012
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 28 Sep 2012 10:15:38 +0000
Subject: [New-bugs-announce] [issue16079] list duplicate test names with
	patchcheck
Message-ID: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

See also issue 16056 for the current list of duplicate test names in
the std lib.

The attached patch improves patchcheck.py to list duplicate test
names when running 'make patchcheck'. This patch to the default
branch can also be applied asis to the 2.7 branch.

An example of patchcheck output with the patch applied:

==================
$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 1 file
Fixing whitespace ... 0 files
Fixing C file whitespace ... 0 files
Fixing docs whitespace ... 0 files
Duplicate test names ... 1 test:
  TestErrorHandling.test_get_only in file Lib/test/test_heapq.py
Docs modified ... NO
Misc/ACKS updated ... NO
Misc/NEWS updated ... NO
configure regenerated ... not needed
pyconfig.h.in regenerated ... not needed

Did you run the test suite?

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

----------
components: Library (Lib)
files: duplicate_test_names.patch
keywords: patch
messages: 171428
nosy: chris.jerdonek, ezio.melotti, xdegaye
priority: normal
severity: normal
status: open
title: list duplicate test names with patchcheck
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27326/duplicate_test_names.patch

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

From report at bugs.python.org  Fri Sep 28 12:36:26 2012
From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=)
Date: Fri, 28 Sep 2012 10:36:26 +0000
Subject: [New-bugs-announce] [issue16080] test_decimal causes other tests to
	fail with LC_ALL=fr_FR
Message-ID: <1348828586.78.0.854198311775.issue16080@psf.upfronthosting.co.za>


New submission from Manuel P?gouri?-Gonnard:

Some tests, namely test_email, test_locale and test_mailbox, normally pass, but fail if both of the following conditions are met:
- the local is fr_FR (or probably any other non-C locale)
- test_decimal is run before them

Steps to repoduce:

% LC_ALL=fr_FR ./python -m test test_email test_locale test_mailbox test_decimal
[1/4] test_email
[2/4] test_locale
[3/4] test_mailbox
[4/4] test_decimal
All 4 tests OK.

% LC_ALL=C ./python -m test test_decimal test_email test_locale test_mailbox              
[1/4] test_decimal
[2/4] test_email
[3/4] test_locale
[4/4] test_mailbox
All 4 tests OK.

% LC_ALL=fr_FR ./python -m test test_decimal test_email test_locale test_mailbox                                                       
[1/4] test_decimal
[2/4] test_email
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
  File "/home/mpg/src/cpython/Lib/test/test_email/test_email.py", line 2716, in test_formatdate_usegmt
    time.strftime('%a, %d %b %Y %H:%M:%S -0000', time.gmtime(now)))
AssertionError: 'Fri, 28 Sep 2012 10:05:26 -0000' != 'ven., 28 sept. 2012 10:05:26 -0000'
- Fri, 28 Sep 2012 10:05:26 -0000
? ^^^     ^
+ ven., 28 sept. 2012 10:05:26 -0000
? ^^^^     ^  ++


[3/4/1] test_locale
test test_locale failed -- Traceback (most recent call last):
  File "/home/mpg/src/cpython/Lib/test/test_locale.py", line 246, in test_percent_escape
    self.assertEqual(locale.format_string('%f%%', 1.0), '%f%%' % 1.0)
AssertionError: '1,000000%' != '1.000000%'
- 1,000000%
?  ^
+ 1.000000%
?  ^


[4/4/2] test_mailbox
test test_mailbox failed -- Traceback (most recent call last):
  File "/home/mpg/src/cpython/Lib/test/test_mailbox.py", line 1754, in test_mboxmmdf_to_maildir
    self.assertEqual(msg.get_date(), 0.0)
AssertionError: 1348826768.3964105 != 0.0

1 test OK.
3 tests failed:
    test_email test_locale test_mailbox

----------
components: Tests
messages: 171431
nosy: mpg
priority: normal
severity: normal
status: open
title: test_decimal causes other tests to fail with LC_ALL=fr_FR
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 28 12:49:17 2012
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 28 Sep 2012 10:49:17 +0000
Subject: [New-bugs-announce] [issue16081] Fix compile warnings in
	thread_pthread.h
Message-ID: <1348829357.7.0.760845781586.issue16081@psf.upfronthosting.co.za>


New submission from Brian Brazil:

Please see attached patch to fix warnings about error being set but not used, I've eliminated error except for the one function that was using it.

----------
components: Interpreter Core
files: pthread-warnings.patch
keywords: patch
messages: 171432
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix compile warnings in thread_pthread.h
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file27327/pthread-warnings.patch

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

From report at bugs.python.org  Fri Sep 28 12:51:27 2012
From: report at bugs.python.org (=?utf-8?q?Einar_Fl=C3=B8ystad_D=C3=B8rum?=)
Date: Fri, 28 Sep 2012 10:51:27 +0000
Subject: [New-bugs-announce] [issue16082] xml.etree.ElementTree.tostringlist
	does conform to it's	documentation
Message-ID: <1348829487.02.0.837389148596.issue16082@psf.upfronthosting.co.za>


New submission from Einar Fl?ystad D?rum:

The tostringlist documentation says "Returns a list of (optionally) encoded strings containing the XML data. It does not guarantee any specific sequence, except that "".join(tostringlist(element)) == tostring(element).". 
But in reality it is possible to get tostringlist to return a string and not a list. 
The following code will demonstrates problem, by failing with a TypeError:

from xml.etree.ElementTree import Element, tostringlist, tostring

element = Element("foo")
print ("".join(tostringlist(element)) == tostring(element))

----------
components: XML
messages: 171434
nosy: einarfd
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.tostringlist does conform to it's documentation
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep 28 12:54:02 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 28 Sep 2012 10:54:02 +0000
Subject: [New-bugs-announce] [issue16083] HTTPServer does not correctly
	handle bad headers
Message-ID: <1348829642.54.0.0563748954245.issue16083@psf.upfronthosting.co.za>


New submission from Michele Orr?:

Sending a "GET /\0" causes a TypeEror to be raised and the connection to be unexpectedly closed. 

$ python -m SimpleHTTPServer 8000
$ printf "GET /\00" | nc localhost 8000

TypeError: must be encoded string without NULL bytes, not str
----------------------------------------

I think raising a 400 error should be fine. Also, shouldn't the error message contain a repr(string)?

[From http://corte.si/posts/code/pathod/pythonservers/index.html]

----------
components: Library (Lib)
messages: 171435
nosy: maker
priority: normal
severity: normal
status: open
title: HTTPServer does not correctly handle bad headers
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Sep 29 15:13:34 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 29 Sep 2012 13:13:34 +0000
Subject: [New-bugs-announce] [issue16084] couple of code examples not
	highlighted in "What's new	in Python 3"
Message-ID: <1348924414.8.0.371561507125.issue16084@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

A couple of code examples are not highlighted in http://docs.python.org/py3k/whatsnew/3.3.html#pep-380-syntax-for-delegating-to-a-subgenerator

They should be highlighted with Python highlighting.

----------
assignee: docs at python
components: Documentation
messages: 171570
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: couple of code examples not highlighted in "What's new in Python 3"
versions: Python 3.3

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

From report at bugs.python.org  Sat Sep 29 15:43:43 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 29 Sep 2012 13:43:43 +0000
Subject: [New-bugs-announce] [issue16085] Minor config parser doc change
Message-ID: <1348926223.26.0.285259885807.issue16085@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

>From http://docs.python.org/library/configparser.html#examples

float = config.getfloat('Section1', 'float')
int = config.getint('Section1', 'int')
print float + int

It's not a good idea to have float or int used like this in examples.  Maybe my_float and my_int or sec1_float and sec_int?

----------
assignee: docs at python
components: Documentation
messages: 171573
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Minor config parser doc change
type: enhancement

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

From report at bugs.python.org  Sat Sep 29 18:04:15 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Sep 2012 16:04:15 +0000
Subject: [New-bugs-announce] [issue16086] tp_flags: Undefined behaviour with
	32 bits long
Message-ID: <1348934655.6.0.704339106877.issue16086@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"1L << 31" is undefined if long is 32 bits long. We should use unsigned long for PyTypeObject.tp_flags.

Attached patch implements this fix. I don't know if it breaks somehow the backward compatibility.

See also issues #1621 and #7406.

----------
components: Interpreter Core
files: unsigned_tp_flags.patch
keywords: patch
messages: 171574
nosy: ezio.melotti, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: tp_flags: Undefined behaviour with 32 bits long
versions: Python 3.4
Added file: http://bugs.python.org/file27347/unsigned_tp_flags.patch

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

From report at bugs.python.org  Sat Sep 29 19:31:59 2012
From: report at bugs.python.org (Kason)
Date: Sat, 29 Sep 2012 17:31:59 +0000
Subject: [New-bugs-announce] [issue16087] How to open a csv file in
	universal new line mode?
Message-ID: <1348939919.11.0.991356894827.issue16087@psf.upfronthosting.co.za>


New submission from Kason:

I am trying to follow the tutorial at http://www.slideshare.net/niloyghosh1984/qgis-tutorial-1
and I got to slide 24 of 47 whereupon I tried to use the mmqgis plugin to open the csv file, but I got this error:
Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode?
After searching for solutions to this error it indeed appears that I need to open this file in universal-newline mode...rU
How do I do that?

----------
assignee: ronaldoussoren
components: Macintosh
messages: 171580
nosy: kason561, ronaldoussoren
priority: normal
severity: normal
status: open
title: How to open a csv file in universal new line mode?
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 30 01:02:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Sep 2012 23:02:31 +0000
Subject: [New-bugs-announce] [issue16088] http.server's send_error could set
	the content-length of	the error body
Message-ID: <1348959751.44.0.331357335713.issue16088@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

BaseHTTPRequestHandler.send_error() sets "connection: close", so the client shouldn't need a content-length, but it can still be nicer to send it (e.g. it seems to solve an issue with wget, see issue15991).

----------
components: Library (Lib)
messages: 171597
nosy: orsenthil, pitrou
priority: low
severity: normal
status: open
title: http.server's send_error could set the content-length of the error body
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 30 04:07:42 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 30 Sep 2012 02:07:42 +0000
Subject: [New-bugs-announce] [issue16089] _elementtree causes segfault in GC
Message-ID: <1348970862.81.0.736695242293.issue16089@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The issue was reported by Arfrever on #python-dev. The test suite of simpletal [1] was segfaulting with Python 3.3. It doesn't segfault without the _elementtree C extension.

I'm able to reproduce the issue. It may take a couple of runs with a debug build of Python but eventually Python segfaults. So far segfaults occur inside a GC collection run. Benjamin suspects the issue is related to the new GC code in _elementtree.

    #0  visit_decref (op=<unknown at remote 0x7fea64fc8ca8>, data=0x0) at Modules/gcmodule.c:361
    #1  0x00000000004bccd5 in subtract_refs (containers=<optimized out>) at Modules/gcmodule.c:386
    #2  collect (generation=0, n_collected=0x7fffe3eedb70, n_uncollectable=0x7fffe3eedb78) at Modules/gcmodule.c:891
    #3  0x00000000004bd7e6 in collect_with_callback (generation=0) at Modules/gcmodule.c:1048
    #4  collect_generations () at Modules/gcmodule.c:1071
    #5  _PyObject_GC_Malloc (basicsize=<optimized out>) at Modules/gcmodule.c:1580
    #6  0x00000000004bddcc in _PyObject_GC_Malloc (basicsize=<optimized out>) at Modules/gcmodule.c:1567
    #7  _PyObject_GC_New (tp=0x8322a0) at Modules/gcmodule.c:1590
    #8  0x0000000000548a3a in new_dict (values=0x0, keys=0xd02e60) at Objects/dictobject.c:395
    #9  _PyDict_NewPresized (minused=<optimized out>) at Objects/dictobject.c:1044
    #10 0x000000000047a449 in PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2245
    #11 0x0000000000480b03 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7fffe3eede40, func=
        <function at remote 0x7fea653ff9e0>) at Python/ceval.c:4150


[1] http://www.owlfish.com/software/simpleTAL/downloads/SimpleTAL-5.1.tar.gz

----------
components: Extension Modules
keywords: 3.3regression
messages: 171603
nosy: christian.heimes
priority: critical
severity: normal
stage: needs patch
status: open
title: _elementtree causes segfault in GC
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Sep 30 05:23:20 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 30 Sep 2012 03:23:20 +0000
Subject: [New-bugs-announce] [issue16090] but is needed somewhere
	in	http://www.python.org/dev/peps/pep-3138/
Message-ID: <1348975400.05.0.784015887596.issue16090@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

subject
I can't remember where the but is needed but I am sure a but is missing somewhere there.

----------
assignee: docs at python
components: Documentation
messages: 171607
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: but is needed somewhere in http://www.python.org/dev/peps/pep-3138/
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep 30 05:31:04 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 30 Sep 2012 03:31:04 +0000
Subject: [New-bugs-announce] [issue16091] changing sidebar links in
	http://docs.python.org/
Message-ID: <1348975864.27.0.424310551967.issue16091@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/ the "Python 3.3 (in development)" link goes to the Python 3.4 docs. It should be renamed to "Python 3.3". A new link should be added for the Python 3.4 docs and the Python 3.2 link may be removed.

----------
assignee: docs at python
components: Documentation
messages: 171609
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: changing sidebar links in http://docs.python.org/

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

From report at bugs.python.org  Sun Sep 30 08:53:46 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 30 Sep 2012 06:53:46 +0000
Subject: [New-bugs-announce] [issue16092] test_recursion_limit in
	test_threading fails on Mac OS X	in 3.2
Message-ID: <1348988026.7.0.663169616771.issue16092@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The test_threading.ThreadingExceptionTests.test_recursion_limit test fails on Mac OS X with the standard compilation command:

$ ./configure --with-pydebug && make -j2

Python 3.2.3+ (3.2:247d3e3c08ca, Sep 29 2012, 23:45:43) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)] on darwin
Mac OS X Lion 10.7.5

======================================================================
FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File ".../cpython/Lib/test/test_threading.py", line 774, in test_recursion_limit
    self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode())
AssertionError: -10 != 0 : Unexpected error: 

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

This seems very similar to issue 14184 (copying the nosy list).

----------
components: Library (Lib)
messages: 171613
nosy: chris.jerdonek, dk, meador.inge, ned.deily
priority: normal
severity: normal
status: open
title: test_recursion_limit in test_threading fails on Mac OS X in 3.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Sep 30 09:00:34 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 30 Sep 2012 07:00:34 +0000
Subject: [New-bugs-announce] [issue16093] Documentation: links to 3.3
Message-ID: <1348988434.58.0.811959538249.issue16093@psf.upfronthosting.co.za>


New submission from Stefan Krah:

A couple of links still need to be updated:

http://docs.python.org/

   Python 3.3 says "in development" and points to 3.4.


http://docs.python.org/dev/

   Python 3.3 is missing.

----------
assignee: docs at python
components: Documentation
messages: 171615
nosy: docs at python, skrah
priority: normal
severity: normal
status: open
title: Documentation: links to 3.3
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Sep 30 13:07:12 2012
From: report at bugs.python.org (GlitchMr)
Date: Sun, 30 Sep 2012 11:07:12 +0000
Subject: [New-bugs-announce] [issue16094] Tuple extraction in lambda isn't
	supported with more	than one argument
Message-ID: <1349003232.56.0.742514252911.issue16094@psf.upfronthosting.co.za>


New submission from GlitchMr:

Tuple extraction in lambda isn't supported with more than one argument.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: lambda.py
messages: 171627
nosy: GlitchMr
priority: normal
severity: normal
status: open
title: Tuple extraction in lambda isn't supported with more than one argument
versions: Python 2.7
Added file: http://bugs.python.org/file27354/lambda.py

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

From report at bugs.python.org  Sun Sep 30 18:41:31 2012
From: report at bugs.python.org (Pietro Battiston)
Date: Sun, 30 Sep 2012 16:41:31 +0000
Subject: [New-bugs-announce] [issue16095] urllib2 failing with squid proxy
	and digest	authentication
Message-ID: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za>


New submission from Pietro Battiston:

If you run the following code:

#! /usr/bin/python
import urllib2

MyHTTPPasswordMgr = urllib2.HTTPPasswordMgr
proxy = urllib2.ProxyHandler({'http': 'http://proxybiblio2.si.unimib.it:8080'})
auth = urllib2.ProxyDigestAuthHandler(MyHTTPPasswordMgr())
auth.add_password(None, "proxybiblio2.si.unimib.it", "a", "b" )
opener = urllib2.build_opener(proxy, auth, urllib2.HTTPHandler)
urllib2.install_opener(opener)
conn = urllib2.urlopen('http://webofknowledge.com')

an "HTTP Error 407: Proxy Authentication Required" is raised, and under the hood here's what's happening:
- the request is made without authentication
- the server replies it must be made with digest authentication, and gives the nonce
- the error is raised.

Instead, urllib2 should now try to connect with the username and password, and do so up to 5 times (as hardcoded in urllib2.http_error_auth_reqed), and then raise a "HTTP Error 401: digest auth failed". And it's indeed what it does if you replace the line "MyHTTPPasswordMgr = urllib2.HTTPPasswordMgr" with


class MyHTTPPasswordMgr(urllib2.HTTPPasswordMgr):
    def find_user_password(self, realm, authuri):
        return "a", "b"


So the problem is in HTTPPasswordMgr, which is apparently unable to match the authentication data with the realm. Some tests? suggest that this can vary according to the proxy engine and to the proxy address format (works with apache, but doesn't if then you add "http://" in front of the proxy address).

This reminds a bit bug 680577, and in particular I noticed that (possibly unrelated) the behaviour reported in the following message:
http://bugs.python.org/msg14444
has not changed:

In [1]: import urllib2

In [2]: urllib2.HTTPPasswordMgr().is_suburi("/foo/spam", "/foo/eggs")Out[2]: True


This affects also python 3.2, you can try the following:

#! /usr/bin/python
from urllib import request
MyHTTPPasswordMgr = request.HTTPPasswordMgr
proxy = request.ProxyHandler({'http': 'http://proxybiblio2.si.unimib.it:8080'})
auth = request.ProxyDigestAuthHandler(MyHTTPPasswordMgr())
auth.add_password(None, "proxybiblio2.si.unimib.it", "a", "b" )
opener = request.build_opener(proxy, auth, request.HTTPHandler)
request.install_opener(opener)
conn = request.urlopen('http://webofknowledge.com')


? http://lists.python.it/pipermail/python/2012-September/013309.html (in Italian)

----------
components: Library (Lib)
messages: 171650
nosy: toobaz
priority: normal
severity: normal
status: open
title: urllib2 failing with squid proxy and digest authentication
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 30 20:34:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2012 18:34:11 +0000
Subject: [New-bugs-announce] [issue16096] Get rid of dangerous integer
	overflow tricks
Message-ID: <1349030051.26.0.323672452753.issue16096@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In several places such dungerous code used to check the integer overflow:

  size = n *?itemsize;
  if (size / itemsize != n) raise exception...

Because these values are signed, this results in undefined behavior.

The proposed patches replace similar unsafe code to safe one. Note that the patches for the different versions are substantially different.

----------
components: Extension Modules, Interpreter Core
files: size_overflow-3.3.patch
keywords: patch
messages: 171657
nosy: mark.dickinson, storchaka
priority: normal
severity: normal
status: open
title: Get rid of dangerous integer overflow tricks
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27360/size_overflow-3.3.patch

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