From report at bugs.python.org  Fri Jun  1 00:05:14 2012
From: report at bugs.python.org (rurpy the second)
Date: Thu, 31 May 2012 22:05:14 +0000
Subject: [New-bugs-announce] [issue14973] restore python2 unicode literals
	in "ru" strings
Message-ID: <1338501914.01.0.738324818375.issue14973@psf.upfronthosting.co.za>


New submission from rurpy the second <rurpy at yahoo.com>:

PEP 414 proposes restoring the "u" string prefix (semantically as a "noop") to make porting from Python2 easier.  I would like to propose that "ru"-strings also interpret embedded "\uxxxx" unicode literals in the python2 fashion (as a single unicode character) rather than in the python 3.2 fashion (as 6 characters).

Many Python2 programs use unicode literals in strings because they can be represented and displayed in source code with the ascii character set.  For example, I often write ur" \u3000\u3042\t" rather than ur" ??    " because the former is much clearer in source code than the latter and does not require the viewer to have a Japanese font installed.

However such a string must be manually converted for Python3 because the former string has a very different meaning in Python3 than Python2.  The equivalent in Python3 is " \u3000\u3042\\t".  AFAIK, 2to3 does not fix this.  Because there are no longer unicode literals in Python3 raw strings, any string with a unicode literal *has* to be a non-raw string (AFAICT).  This means that strings used as regexes, that have a lot of backslashes and have unicode literals, must have the backslashes doubled.  Doubling the backslashes in the above example is trivial but it is not trival in more realistic regexes.  This was one of the main reasons for having raw strings in Python2 I thought.  It is unfortunate that one looses this ability (in the presence of unicode literals) in Python3.

When I raised this issue on the Python user's list [*1], Terry Reedy made the suggestion that since the "u" string prefix was being reintroduced for python 3.3, that having the prefix also restore the python2 unicode literal handling would not introduce any incompatibilties and would greatly increase the ease of porting to Python3 for some programs.[*2]  He subsequently raised the issue on the dev list.[*3]

An argument might be made that this is an extra feature that would encourage the use of the "u"-prefix beyond that of easing porting from Python2.  Perhaps so but there is currently a hole in Python's capability that is difficult to work around, and I've seen no other proposals to fix it.  So it seems to me that the benefits of this proposal greatly outweigh that somewhat purist argument.
----
[*1] http://mail.python.org/pipermail/python-list/2012-May/1292870.html
[*2] http://mail.python.org/pipermail/python-list/2012-May/1292887.html
[*3] http://mail.python.org/pipermail/python-dev/2012-May/119760.html

----------
components: Unicode
messages: 162025
nosy: ezio.melotti, rurpy2
priority: normal
severity: normal
status: open
title: restore python2 unicode literals in "ru" strings
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  1 00:14:22 2012
From: report at bugs.python.org (Alexis Metaireau)
Date: Thu, 31 May 2012 22:14:22 +0000
Subject: [New-bugs-announce] [issue14974] rename packaging.pypi to
	packaging.index
Message-ID: <1338502462.41.0.230255399861.issue14974@psf.upfronthosting.co.za>


New submission from Alexis Metaireau <alexis at notmyidea.org>:

PyPI is the name of a particular index, whereas "index" is a generic term.

So ISTM that it would be better to use the latter, semantically-wise.

----------
assignee: alexis
components: Distutils2
messages: 162027
nosy: alexis, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: rename packaging.pypi to packaging.index
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  1 00:42:25 2012
From: report at bugs.python.org (YF)
Date: Thu, 31 May 2012 22:42:25 +0000
Subject: [New-bugs-announce] [issue14975] import unicodedata,
	DLL load failed on Python 2.7.3
Message-ID: <1338504145.87.0.920765614951.issue14975@psf.upfronthosting.co.za>


New submission from YF <yfdyh000 at gmail.com>:

Before I use the Python 2.7.2 on Windows XP, today I tried to upgrade to the Python 2.7.3, but encountered a problem.
When running any .py file encountered "import unicodedata" or directly run the command always returns:
Traceback (most recent call last):
......
    import unicodedata
ImportError: DLL load failed: ?????????
"????????" corresponding English is "Cannot find the specified program".

I unable provide more information because I am only a user rather than developer.

After that, I manually delete "C:\Python27\DLLs\unicodedata.pyd" file (this step must be, otherwise no effect), then reinstall (Repair) Python 2.7.2 the problem disappeared.

----------
components: Unicode
messages: 162030
nosy: ezio.melotti, yfdyh000
priority: normal
severity: normal
status: open
title: import unicodedata, DLL load failed on Python 2.7.3
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  1 10:43:06 2012
From: report at bugs.python.org (=?utf-8?q?Johan_Aires_Rast=C3=A9n?=)
Date: Fri, 01 Jun 2012 08:43:06 +0000
Subject: [New-bugs-announce] [issue14976] Queue.PriorityQueue() is not
	interrupt safe
Message-ID: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>


New submission from Johan Aires Rast?n <johan at oljud.se>:

Python 2.7.3 (default, Apr 20 2012, 22:39:59) 
[GCC 4.6.3] on linux2

If a signal handler calls Queue.PriorityQueue.put and a second signal is received while one is already being processed, neither of the calls to put will terminate.

Highly dependent on timing so it might be difficult to reproduce.

----------
components: Library (Lib)
messages: 162062
nosy: JohanAR
priority: normal
severity: normal
status: open
title: Queue.PriorityQueue() is not interrupt safe
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  1 11:28:53 2012
From: report at bugs.python.org (Emmanuel Beffara)
Date: Fri, 01 Jun 2012 09:28:53 +0000
Subject: [New-bugs-announce] [issue14977] mailcap does not respect
	precedence in the presence of	wildcards
Message-ID: <1338542933.25.0.233529643572.issue14977@psf.upfronthosting.co.za>


New submission from Emmanuel Beffara <manu at beffara.org>:

According to RFC 1542, the first matching entry in mailcap files should be used for handling a given type. The mailcap module does not respect this rule when wildcards are used in some rules, because the "lookup" function always checks entries for a specific type (say image/jpeg) before checking the generic ones (image/*). As a consequence, if a user overrides system defaults using a generic type, this choice is not satisfied, and the behaviour is inconsistent with other tools using mailcap (including the standard "run-mailcap").

----------
components: Library (Lib)
messages: 162064
nosy: manu-beffara
priority: normal
severity: normal
status: open
title: mailcap does not respect precedence in the presence of wildcards
type: behavior

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

From report at bugs.python.org  Fri Jun  1 12:09:45 2012
From: report at bugs.python.org (guyomes)
Date: Fri, 01 Jun 2012 10:09:45 +0000
Subject: [New-bugs-announce] [issue14978] distutils Extension fails to be
	created with unicode	package names
Message-ID: <1338545385.38.0.440171490662.issue14978@psf.upfronthosting.co.za>


New submission from guyomes <gmoroz at gmail.com>:

This issue appeared initially in:

http://groups.google.com/group/cython-users/browse_thread/thread/f9e7018bb12a66d2

Note that this is also an issue in distutils2/compiler/extension.py, where arguments of Extension are also tested against str only.

----------
assignee: eric.araujo
components: Distutils
files: patch-distutils-extension_py.diff
keywords: patch
messages: 162067
nosy: eric.araujo, guyomes, patrick.andrew, tarek
priority: normal
severity: normal
status: open
title: distutils Extension fails to be created with unicode package names
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file25788/patch-distutils-extension_py.diff

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

From report at bugs.python.org  Fri Jun  1 15:03:26 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 01 Jun 2012 13:03:26 +0000
Subject: [New-bugs-announce] [issue14979] pdb: Link to source
Message-ID: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/pdb.html#pdb.Pdb

Documentation for pdb says: "The debugger is extensible ? it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source."

There should a link to the source.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 162074
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: pdb: Link to source

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

From report at bugs.python.org  Fri Jun  1 17:40:56 2012
From: report at bugs.python.org (Samuel John)
Date: Fri, 01 Jun 2012 15:40:56 +0000
Subject: [New-bugs-announce] [issue14980] ranlib: file:
	libpython2.7.a(pymath.o) has no symbols
Message-ID: <1338565256.1.0.622493856416.issue14980@psf.upfronthosting.co.za>


New submission from Samuel John <python at samueljohn.de>:

Building python on the Mac (10.7.4) with latest Xcode shows

```
[...]
ranlib: file: libpython2.7.a(pymath.o) has no symbols
```

Is that okay or a bug?

----------
assignee: ronaldoussoren
components: Macintosh
messages: 162078
nosy: ronaldoussoren, samueljohn
priority: normal
severity: normal
status: open
title: ranlib: file: libpython2.7.a(pymath.o) has no symbols
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun  1 19:27:31 2012
From: report at bugs.python.org (Andreas Jung)
Date: Fri, 01 Jun 2012 17:27:31 +0000
Subject: [New-bugs-announce] [issue14981] 3.3.0a4 compilation fails von
	MacOS Lion /10.7.4
Message-ID: <1338571651.03.0.551687770789.issue14981@psf.upfronthosting.co.za>


New submission from Andreas Jung <ajung at users.sourceforge.net>:

ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols
ranlib: file: libpython3.3m.a(pymath.o) has no symbols
gcc   -framework CoreFoundation -o python.exe Modules/python.o libpython3.3m.a -ldl  -framework CoreFoundation     
gcc   -framework CoreFoundation -o Modules/_testembed Modules/_testembed.o libpython3.3m.a -ldl  -framework CoreFoundation     
./python.exe -SE -m sysconfig --generate-posix-vars
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
python.exe(41191) malloc: *** mmap(size=7310873954244194304) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Could not import runpy module
make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11

----------
components: Build
messages: 162082
nosy: ajung
priority: normal
severity: normal
status: open
title: 3.3.0a4 compilation fails von MacOS Lion /10.7.4
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun  2 01:00:34 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Fri, 01 Jun 2012 23:00:34 +0000
Subject: [New-bugs-announce] [issue14982] pkgutil.walk_packages seems to not
	work properly on	Python 3.3a
Message-ID: <1338591634.81.0.610642450441.issue14982@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

I noticed that pip wasn't working properly on Python 3.3a - notably, it wasn't able to load any of its own VCS modules -- it does this by using pkgutil.walk_packages

I think the problem is that the behavior of pkgutil.walk_packages changed in some incompatible way in 3.3 -- take a look at the following:

[last: 0] marca at scml-marca:~/dev/git-repos/lexicon$ ../lexicon/.tox/py32/bin/python
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
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkgutil import walk_packages
>>> list(walk_packages('/Users/marca/dev/git-repos/lexicon/.tox/py33/lib/python3.3/site-packages/pip-1.1-py3.3.egg/pip/vcs'))
[(<pkgutil.ImpImporter object at 0x1005bc710>, 'lexicon', True), (<pkgutil.ImpImporter object at 0x100649410>, 'lexicon.alias_dict', False), (<pkgutil.ImpImporter object at 0x100649410>, 'lexicon.attribute_dict', False), (<pkgutil.ImpImporter object at 0x1005bc710>, 'reg_settings', False), (<pkgutil.ImpImporter object at 0x1005bc710>, 'setup', False)]
>>> ^D

[last: 10] marca at scml-marca:~/dev/git-repos/lexicon$ ../lexicon/.tox/py33/bin/python
Python 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May  1 2012, 11:39:35) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkgutil import walk_packages
>>> list(walk_packages('/Users/marca/dev/git-repos/lexicon/.tox/py33/lib/python3.3/site-packages/pip-1.1-py3.3.egg/pip/vcs'))
[]

----------
components: Library (Lib)
messages: 162110
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: pkgutil.walk_packages seems to not work properly on Python 3.3a
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun  2 08:52:22 2012
From: report at bugs.python.org (Dmitry Shachnev)
Date: Sat, 02 Jun 2012 06:52:22 +0000
Subject: [New-bugs-announce] [issue14983] [patch] email.generator should
	always add newlines after	closing boundaries
Message-ID: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev <Mitya57 at gmail.com>:

Trying to write a email-sending script with PGP-signing functionality, I stumbled upon a problem (see [1]): it was impossible to sign mutlipart emails (actually the signing was performed, but the verifying programs thought that the signature is bad).

After comparing messages produced by email.generator and popular mail clients (Evolution, KMail), I've found out that the mail clients always add line breaks after ending boundaries.

The attached patch makes email.generator behave like all email clients. After applying it, it's possible to sign even complicated mails like "multipart/alternate with attachments".

An illustration:

 --====1==     # Part 1 (base message) begin
 ...
 --====2==     # Part 1.1 begin
 ...
 --====2==     # Part 1.2 begin
 ...
 --====2==--   # Part 1 end
               # There should be empty line here
 --====1==     # Part 2 (signature) begin
 ...
 --====1==--   # End of the message

[1]: http://stackoverflow.com/questions/10496902/pgp-signing-multipart-e-mails-with-python

----------
components: email
files: always_add_newlines.patch
keywords: patch
messages: 162126
nosy: barry, mitya57, r.david.murray
priority: normal
severity: normal
status: open
title: [patch] email.generator should always add newlines after closing boundaries
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file25798/always_add_newlines.patch

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

From report at bugs.python.org  Sat Jun  2 14:53:41 2012
From: report at bugs.python.org (bruno Piguet)
Date: Sat, 02 Jun 2012 12:53:41 +0000
Subject: [New-bugs-announce] [issue14984] netrc module alows read of
	non-secured .netrc file
Message-ID: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>


New submission from bruno Piguet <bruno.piguet at gmail.com>:

Most FTP clients require that the .netrc file be owned by the user and readable/writable by nobody other than the user (ie. permissions set to 0400 or 0600).
The netrc module doesn't do this kind of checking, allowing the use a .netrc file written or modified by somebody else.

----------
messages: 162132
nosy: bruno.Piguet
priority: normal
severity: normal
status: open
title: netrc module alows read of non-secured .netrc file
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun  2 15:06:53 2012
From: report at bugs.python.org (Adrian Bastholm)
Date: Sat, 02 Jun 2012 13:06:53 +0000
Subject: [New-bugs-announce] [issue14985] os.path.isfile and os.path.isdir
	inconsistent on OSX Lion
Message-ID: <1338642413.05.0.366116403314.issue14985@psf.upfronthosting.co.za>


New submission from Adrian Bastholm <javahaxxor at gmail.com>:

os.path.isfile doesn't reckognize a .picasa.ini file as a file
and os.path.isdir doesn't reckognize a directory as a directory

code:

def traverse (targetDir):
    currentDir = targetDir
    dirs = os.listdir(targetDir)
#    dirs = [x for x in os.listdir('.') if x.endswith('.JPG')]
    for entry in dirs:
        if os.path.isdir(entry):
            print("Traversing " + entry)
            traverse(entry)
        else:
            print("Not dir: " + entry)
            if os.path.isfile(entry):
                print("Processing " + " " + currentDir + " " + entry)
            else:
                print("Not file: " + entry)
    print("\n")
    return True

The test directory contains jpg files and a folder with some other jpgs and a subfolder containing jpgs

----------
assignee: ronaldoussoren
components: Macintosh
messages: 162133
nosy: javahaxxor, ronaldoussoren
priority: normal
severity: normal
status: open
title: os.path.isfile and os.path.isdir  inconsistent on OSX Lion
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jun  2 15:18:24 2012
From: report at bugs.python.org (Adrian Bastholm)
Date: Sat, 02 Jun 2012 13:18:24 +0000
Subject: [New-bugs-announce] [issue14986] print() fails on latin1 characters
	on OSX
Message-ID: <1338643104.3.0.636595551565.issue14986@psf.upfronthosting.co.za>


New submission from Adrian Bastholm <javahaxxor at gmail.com>:

print(listentry) fails on folder name with swedish (latin1) characters
Error:

 File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/encodings/mac_roman.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u030a' in position 33: character maps to <undefined>

----------
assignee: ronaldoussoren
components: Macintosh
messages: 162134
nosy: javahaxxor, ronaldoussoren
priority: normal
severity: normal
status: open
title: print() fails on latin1 characters on OSX
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  3 00:00:07 2012
From: report at bugs.python.org (Paul Nasrat)
Date: Sat, 02 Jun 2012 22:00:07 +0000
Subject: [New-bugs-announce] [issue14987] inspect missing warnings import
Message-ID: <1338674407.28.0.70502641007.issue14987@psf.upfronthosting.co.za>


New submission from Paul Nasrat <pnasrat at gmail.com>:

Whilst looking for workarounds to http://bugs.python.org/issue14982 I came across this, which is due to inspect using warnings without having importing it.

Fix is trivial but can upload a patch

Traceback (most recent call last):
  File "t.py", line 7, in <module>
    print(list(iter_modules(path=vcs.__path__, prefix=vcs.__name__+'.')))
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pkgutil.py", line 144, in iter_modules
    for name, ispkg in iter_importer_modules(i, prefix):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pkgutil.py", line 202, in iter_modules
    modname = inspect.getmodulename(fn)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 448, in getmodulename
    info = getmoduleinfo(path)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/inspect.py", line 436, in getmoduleinfo
    warnings.warn('inspect.getmoduleinfo() is deprecated', DeprecationWarning,
NameError: global name 'warnings' is not defined

----------
components: Library (Lib)
messages: 162184
nosy: pnasrat
priority: normal
severity: normal
status: open
title: inspect missing warnings import
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun  3 09:21:55 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Jun 2012 07:21:55 +0000
Subject: [New-bugs-announce] [issue14988] _elementtree: Raise ImportError
	when importing of	pyexpat fails
Message-ID: <1338708115.99.0.275881966348.issue14988@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

If, after building of Python, libexpat.so (library used by pyexpat module) has been broken/removed or pyexpat module has been broken/removed, then attempt of import of _elementtree module, which requires pyexpat module, will raise strange exceptions in Python 3.

These exceptions can be simulated by setting sys.modules["pyexpat"] = None.

$ python2.6 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named pyexpat
$ python2.7 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: PyCapsule_Import could not import module "pyexpat"
$ python3.1 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: initialization of _elementtree raised unreported exception
$ python3.2 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: initialization of _elementtree raised unreported exception
$ python3.3 -c 'import sys; sys.modules["pyexpat"] = None; import _elementtree'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1286, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1253, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 347, in set_package_wrapper
  File "<frozen importlib._bootstrap>", line 360, in set_loader_wrapper
  File "<frozen importlib._bootstrap>", line 870, in load_module
RuntimeError: cannot load dispatch table from pyexpat

I suggest to raise ImportError instead of SystemError or RuntimeError.
Third-party modules would rather use only 'except ImportError: pass' instead of 'except (ImportError, SystemError, RuntimeError): pass' when trying to optionally use e.g. xml.etree.cElementTree.
xml.etree.ElementTree in Python 3.3 also ignores only ImportError when trying to import _elementtree.

----------
messages: 162198
nosy: Arfrever, eli.bendersky, flox
priority: normal
severity: normal
status: open
title: _elementtree: Raise ImportError when importing of pyexpat fails
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun  3 10:03:04 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Jun 2012 08:03:04 +0000
Subject: [New-bugs-announce] [issue14989] http.server option to run
	CGIHTTPRequestHandler
Message-ID: <1338710584.57.0.336351054508.issue14989@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

python3 -m http.server enables you to serve with SimpleHTTPRequestHandler serving as http server. If the cgi-bin paths are present those are *not treated as cgi paths*.  Previously in Python2, python -m CGIHTTPServer enabled the sever to run it as CGI enabled HTTP Server.

Since in Python3, both SimpleHTTPServer and CGIHTTPServer are combined into http/server.py, I think having a option to serve cgi server from command like invocation is a good idea.

This is not a new feature, just an enabler in command line execution of http.server module and I think, it should be made available in 3.2 as well as it already available in 2.7 ( via CGIHTTPServer).

----------
assignee: orsenthil
messages: 162199
nosy: orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: http.server option to run CGIHTTPRequestHandler
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun  3 12:29:02 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 03 Jun 2012 10:29:02 +0000
Subject: [New-bugs-announce] [issue14990] detect_encoding should fail with
	SyntaxError on invalid	encoding
Message-ID: <1338719342.67.0.917704298784.issue14990@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

I've hit this issue while playing with tokenize for the pep8.py module.

The tokenize detect_encoding() should report SyntaxError when the encoding is improperly declared.

However it raises a LookupError in some cases.

$ ./python -m tokenize Lib/test/bad_coding2.py 
unexpected error: unknown encoding: utf8-sig
Traceback (most recent call last):
  File "./Lib/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "./Lib/runpy.py", line 75, in _run_code
    exec(code, run_globals)
  File "./Lib/tokenize.py", line 686, in <module>
    main()
  File "./Lib/tokenize.py", line 656, in main
    tokens = list(tokenize(f.readline))
  File "./Lib/tokenize.py", line 489, in _tokenize
    line = line.decode(encoding)
LookupError: unknown encoding: utf8-sig

----------
components: Library (Lib)
messages: 162205
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: detect_encoding should fail with SyntaxError on invalid encoding
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun  3 19:01:01 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Jun 2012 17:01:01 +0000
Subject: [New-bugs-announce] [issue14991] Option for regex groupdict() to
	show only matching names
Message-ID: <1338742861.24.0.324062376049.issue14991@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently, mo.groupdict() always inserts a default value for unmatched named groups.   This is helpful in some use cases and awkward in others.

I propose adding an option to suppress default entries:

>>> # CURRENT WAY
>>> pattern = r'(?P<TITLE>Mrs |Mr |Dr )?(?P<LASTNAME>\w+)(?P<SUFFIX> Phd| JD)?'
>>> print re.match(pattern, 'Dr Who').groupdict()
{'LASTNAME': 'Who', 'SUFFIX': None, 'TITLE': 'Dr '}

>>> # PROPOSED WAY
>>> print re.match(pattern, 'Dr Who').groupdict(nodefault=True)
{'LASTNAME': 'Who', 'TITLE': 'Dr '}

>>> # UPSTREAM VARIANT
>>> print re.match(pattern, 'Dr Who', re.NODEFAULT).groupdict()
{'LASTNAME': 'Who', 'TITLE': 'Dr '}

There is probably a better name than "nodefault", but I would like to see someway to improve the usability of groupdict().

----------
messages: 162223
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Option for regex groupdict() to show only matching names
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  3 21:16:34 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Jun 2012 19:16:34 +0000
Subject: [New-bugs-announce] [issue14992] os.makedirs expect_ok=True test_os
	failure when	directory has S_ISGID bit set
Message-ID: <1338750994.84.0.984038556909.issue14992@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

======================================================================
ERROR: test_exist_ok_existing_directory (__main__.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_os.py", line 842, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/home/greg/sandbox/python/cpython/default/Lib/os.py", line 161, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists (mode 0o2755 != desired mode 0o755): '@test_4027_tmp/dir1'

(I modified os.makedirs to add the info on the mode differences above to highlight the source of the problem)

0o2000 is the S_ISGID bit on a directory which is a "contagious" bit that is automatically copied onto subdirectories.  os.makedirs is not expecting to find it so exist_ok does not work as desired.

Workaround: Don't run the Python test suite from a directory with that bit set.

I think the os.makedirs() behavior should be to ignore bits that can appear regardless of the umask as it makes exist_ok=True useless in that situation.

----------
messages: 162228
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: os.makedirs expect_ok=True test_os failure when directory has S_ISGID bit set
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun  3 21:25:23 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=)
Date: Sun, 03 Jun 2012 19:25:23 +0000
Subject: [New-bugs-announce] [issue14993] GCC error when using
	unicodeobject.h
Message-ID: <1338751523.03.0.870704033637.issue14993@psf.upfronthosting.co.za>


New submission from Andr? Malo <nd at perlig.de>:

GCC error when using unicodeobject.h

This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball.

I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89).

Including Python.h includes unicodeobject.h which emits:

/usr/include/python3.3/unicodeobject.h:905: error: type of bit-field 'overallocate' is a GCC extension
/usr/include/python3.3/unicodeobject.h:908: error: type of bit-field 'readonly' is a GCC extension

Maybe these should just be (unsigned) ints or something?

----------
components: Extension Modules, Interpreter Core
messages: 162229
nosy: ndparker
priority: normal
severity: normal
status: open
title: GCC error when using unicodeobject.h
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun  3 21:31:09 2012
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=)
Date: Sun, 03 Jun 2012 19:31:09 +0000
Subject: [New-bugs-announce] [issue14994] GCC error when using pyerrors.h
Message-ID: <1338751869.08.0.200680664927.issue14994@psf.upfronthosting.co.za>


New submission from Andr? Malo <nd at perlig.de>:

GCC error when using pyerrors.h

This ist my first attempt to test an extension with python 3.3. I've been using the 3.3.0a4 tarball.

I'm using very strict compiler settings when compiling my extension modules, especially -Wall -Werror (along with a lot more flags, like -pedantic, -std=c89).

Including Python.h includes pyerrors.h which emits:

/usr/include/python3.3/pyerrors.h:91:8: error: "__GNUC_MAJOR__" is not defined
/usr/include/python3.3/pyerrors.h:92:8: error: "__GNUC_MAJOR__" is not defined

I'm not sure, which of the compiler flags is responsible for dropping those macros. Simple defined() checks should fix that problem though.

----------
components: Extension Modules, Interpreter Core
messages: 162230
nosy: ndparker
priority: normal
severity: normal
status: open
title: GCC error when using pyerrors.h
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun  4 02:32:53 2012
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 04 Jun 2012 00:32:53 +0000
Subject: [New-bugs-announce] [issue14995] PyLong_FromString documentation
	should state that the	string must be null-terminated
Message-ID: <1338769973.67.0.784454345332.issue14995@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

PyLong_FromString will raise a ValueError if the given string doesn't contain a null byte after the digits.  For example, this will result in a ValueError

   char *pend;
   PyLong_FromString("1234 extra", &pend, 10)

While this will successfully read the number and set the pointer to the extra data:

   char *pend;
   PyLong_FromString("1234\0extra", &pend, 10)

The requirement for a null-terminated string of digits is not clear from the docs.  Suggested re-wording attached.

----------
assignee: docs at python
components: Documentation
files: PyLong_FromString-doc.patch
keywords: patch
messages: 162242
nosy: docs at python, rfk
priority: normal
severity: normal
status: open
title: PyLong_FromString documentation should state that the string must be null-terminated
Added file: http://bugs.python.org/file25812/PyLong_FromString-doc.patch

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

From report at bugs.python.org  Mon Jun  4 03:14:55 2012
From: report at bugs.python.org (Maureen Cuomo)
Date: Mon, 04 Jun 2012 01:14:55 +0000
Subject: [New-bugs-announce] [issue14996] pthon 3.2.3 freezes when saving a
	.py program
Message-ID: <1338772495.05.0.429589904089.issue14996@psf.upfronthosting.co.za>


New submission from Maureen Cuomo <mcuomo at prestonhs.org>:

I have been using ver 3.2.1 without a problem. Downloaded 3.2.3 nd cannot save any file in idle.

----------
components: IDLE
messages: 162243
nosy: mcuomo at prestonhs.org
priority: normal
severity: normal
status: open
title: pthon 3.2.3 freezes when saving a .py program
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun  4 03:30:08 2012
From: report at bugs.python.org (cuulblu)
Date: Mon, 04 Jun 2012 01:30:08 +0000
Subject: [New-bugs-announce] [issue14997] Syntax Error in Python Version
	Number
Message-ID: <1338773408.15.0.466172747854.issue14997@psf.upfronthosting.co.za>


New submission from cuulblu <ken at fivefingerdesigns.com>:

When using Idle any code I attempt to test I get a syntax error in the version number of the software. Please see the attached image. I have python installed on three machines and get the same error on all three. 
All three machines are Windows 7, 64 bit. Two have Intel CPU's. One is an AMD. I have tried reinstalling. Same results.

----------
components: IDLE
files: python_error.jpg
messages: 162246
nosy: cuulblu
priority: normal
severity: normal
status: open
title: Syntax Error in Python Version Number
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file25813/python_error.jpg

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

From report at bugs.python.org  Mon Jun  4 05:32:15 2012
From: report at bugs.python.org (Shawn Brown)
Date: Mon, 04 Jun 2012 03:32:15 +0000
Subject: [New-bugs-announce] [issue14998] pprint._safe_key is not always
	safe enough
Message-ID: <1338780735.82.0.957035826982.issue14998@psf.upfronthosting.co.za>


New submission from Shawn Brown <03sjbrown at gmail.com>:

This is related to resolved issue 3976 and, to a lesser extent, issue 10017.

I've run across another instance where pprint throws an exception (but works fine in 2.7 and earlier):

Python 3.2 (r32:88445, Mar 25 2011, 19:28:28) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pprint import pprint
>>> pprint({(0,): 1, (None,): 2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/pprint.py", line 55, in pprint
    printer.pprint(object)
  File "/usr/lib/python3.2/pprint.py", line 132, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/usr/lib/python3.2/pprint.py", line 155, in _format
    rep = self._repr(object, context, level - 1)
  File "/usr/lib/python3.2/pprint.py", line 245, in _repr
    self._depth, level)
  File "/usr/lib/python3.2/pprint.py", line 257, in format
    return _safe_repr(object, context, maxlevels, level)
  File "/usr/lib/python3.2/pprint.py", line 299, in _safe_repr
    items = sorted(object.items(), key=_safe_tuple)
  File "/usr/lib/python3.2/pprint.py", line 89, in __lt__
    rv = self.obj.__lt__(other.obj)
TypeError: unorderable types: int() < NoneType()

The above example might seem contrived but I stumbled across the issue quite naturally. Honest!

In working with multiple lists and computing results using combinations of these lists' values.  I _could_ organize the results as a dictionary of dictionaries of dictionaries but that would get confusing very quickly.  Instead, I'm using a single dictionary with a composite key ("flat is better than nested"). So I've got code like this...

>>> combinations = itertools.product(lst_x, lst_y, lst_z)
>>> results = {(x,y,z): compute(x,y,z) for x,y,z in combinations}

... and it is not uncommon for one or more of the values to be None -- resulting in the above exception should anyone (including unittest) attempt to pprint the dictionary.

----------
components: Library (Lib)
messages: 162249
nosy: Shawn.Brown
priority: normal
severity: normal
status: open
title: pprint._safe_key is not always safe enough
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun  4 07:50:05 2012
From: report at bugs.python.org (Timothy Pederick)
Date: Mon, 04 Jun 2012 05:50:05 +0000
Subject: [New-bugs-announce] [issue14999] ctypes ArgumentError lists
	arguments from 1, not 0
Message-ID: <1338789005.54.0.744601187049.issue14999@psf.upfronthosting.co.za>


New submission from Timothy Pederick <pederick at gmail.com>:

The ctypes ArgumentError exception indicates the location of the problem by argument number. It counts arguments starting from 1, not 0 as is typical in Python.

Observed
--------
An example (anonymised) traceback:
    Traceback (most recent call last):
        ...
        foreign_function(a, b, c, d)
    ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type

The error here was with the argument "b".

Expected
--------
Standard, zero-indexed Python counting would suggest that argument 2 should mean "c", and "b" would be argument 1.

Rationale
---------
This may be as intended, but for me it violates the principle of least surprise.

I *think* this is the vicinity of the bug:
http://hg.python.org/cpython/file/696d3631a4a1/Modules/_ctypes/callproc.c#l1103

    _ctypes_extend_error(PyExc_ArgError, "argument %d: ", i+1);

If I'm right and the "i+1" (here and/or in subsequent lines) is the cause, that definitely makes it look intentional.

----------
components: ctypes
messages: 162251
nosy: perey
priority: normal
severity: normal
status: open
title: ctypes ArgumentError lists arguments from 1, not 0
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jun  4 20:07:37 2012
From: report at bugs.python.org (Mike Frysinger)
Date: Mon, 04 Jun 2012 18:07:37 +0000
Subject: [New-bugs-announce] [issue15000] posixsubprocess module broken on
	x32
Message-ID: <1338833257.79.0.47743387553.issue15000@psf.upfronthosting.co.za>


New submission from Mike Frysinger <vapier at users.sourceforge.net>:

the direct call to the getdents syscall is broken on x32.  there, the first two args are not unsigned long, but unsigned long long.  patch attached to fix the issue.

----------
components: Extension Modules
files: python-3.2.3-x32.patch
keywords: patch
messages: 162281
nosy: vapier
priority: normal
severity: normal
status: open
title: posixsubprocess module broken on x32
versions: Python 3.2
Added file: http://bugs.python.org/file25819/python-3.2.3-x32.patch

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

From report at bugs.python.org  Mon Jun  4 21:49:25 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 Jun 2012 19:49:25 +0000
Subject: [New-bugs-announce] [issue15001] segmentation fault with del
	sys.module['__main__']
Message-ID: <1338839365.76.0.631007627601.issue15001@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

This simple script segfaults the interpreter (all versions), at least when run with "./python myscript.py"

myscript.py::
    import sys
    del sys.module['__main__']

----------
messages: 162284
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: segmentation fault with del sys.module['__main__']
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun  4 22:14:41 2012
From: report at bugs.python.org (sspapilin)
Date: Mon, 04 Jun 2012 20:14:41 +0000
Subject: [New-bugs-announce] [issue15002] urllib2 does not download 4 MB
	file fully using ftp
Message-ID: <1338840881.84.0.164546182047.issue15002@psf.upfronthosting.co.za>


New submission from sspapilin <sspapilin at gmail.com>:

File test.py is

#!/usr/bin/env python
import urllib2
print urllib2.urlopen('ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest').read()

When I issue

python test.py > out.txt

, I get file about 100KB in size, the beginning of the actual file. I repeated it a hundred times, and almost every time I get 98305 byte file, and a couple of times a 49153 bytes or 188417 bytes file.

When I replace urllib2 with urllib in test.py, I get full (4 MB) file.

I have Ubuntu 12.04 64-bit, Python 2.7.3 (from default Ubuntu repository, up-to-date as of 4-june-2012) and slow, 64KB/s, Internet connection.

However, I asked my friend with Windows and faster connection to check it, and he got partial download as well, while he had another size of partial file (50109 bytes). I do not know his OS ant Python versions.

----------
components: Library (Lib)
files: test.py
messages: 162287
nosy: sspapilin
priority: normal
severity: normal
status: open
title: urllib2 does not download 4 MB file fully using ftp
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25821/test.py

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

From report at bugs.python.org  Tue Jun  5 04:53:40 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Jun 2012 02:53:40 +0000
Subject: [New-bugs-announce] [issue15003] make PyNamespace_New() public
Message-ID: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The type is available as types.SimpleNamespace, and there's no reason to hold PyNamespace_New() back.

----------
components: Library (Lib)
messages: 162322
nosy: amaury.forgeotdarc, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: make PyNamespace_New() public
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun  5 04:58:52 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Jun 2012 02:58:52 +0000
Subject: [New-bugs-announce] [issue15004] add weakref support to
	types.SimpleNamespace
Message-ID: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Currently types.SimpleNamespace does not support weak references.  Amaury asked for this in #14673, but I'd like to see more discussion.  What are the use cases for weak references in this case?

The type is a simple wrapper around dict, which does not support weak references.  In fact most of the builtin types do not support them.  However, I freely admit that I haven't used weak references very much and am not familiar with the use cases.

----------
messages: 162323
nosy: amaury.forgeotdarc, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: add weakref support to types.SimpleNamespace
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun  5 16:40:11 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 05 Jun 2012 14:40:11 +0000
Subject: [New-bugs-announce] [issue15005] trace corrupts return result on
	chained execution
Message-ID: <1338907211.87.0.323271147876.issue15005@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

This code dumps a lot of internal source code info when executed with trace as:

python -m trace --trace file2.py


---[file2.py]
import subprocess

def ret():
  output = subprocess.check_output(['hg', 'id', '-nib'])
  print( output )
  print( output )
  print( output.strip() )
  print( output.strip().split() )

ret()
---

Normally, the last line of the output is:
['e67793ec2995+', '2162+', 'default']

But during trace call it is:
['subprocess.py(1180):', '_dup2(errwrite,', '2)', '---', 'modulename:', 'subprocess,', 'funcname:', '_dup2', 'subprocess.py(1174):', 'if', 'a', '==', 'b:', 'subprocess.py(1176):', 'elif', 'a', 'is', 'not', 'None:', 'subprocess.py(1184):', 'closed', '=', '{', 'None', '}',
...
etc.

----------
files: file2.py
messages: 162347
nosy: techtonik
priority: normal
severity: normal
status: open
title: trace corrupts return result on chained execution
versions: Python 2.7
Added file: http://bugs.python.org/file25832/file2.py

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

From report at bugs.python.org  Tue Jun  5 21:29:50 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Jun 2012 19:29:50 +0000
Subject: [New-bugs-announce] [issue15006] Allow equality comparison between
	naive and aware	datetime objects
Message-ID: <1338924590.08.0.24472755883.issue15006@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Guido: Let's make it so. / python-dev

----------
components: Extension Modules, Library (Lib)
messages: 162368
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Allow equality comparison between naive and aware datetime objects
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun  5 23:20:29 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Jun 2012 21:20:29 +0000
Subject: [New-bugs-announce] [issue15007] Unittest CLI does not support test
	packages very well
Message-ID: <1338931229.09.0.80724559879.issue15007@psf.upfronthosting.co.za>


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

Suppose you have a test package:

  test_pkg
     __init__.py
     test_mytest.py

If __init__.py is empty and you run

   python -m unittest test_pk

no tests are found.

You can get this to work by adding the following boiler plate to __init__.py:

  def load_tests(loader, standard_tests, pattern):
    this_dir = os.path.dirname(__file__)
    if pattern is None:
        pattern = "test*"
    package_tests = loader.discover(start_dir=this_dir,
                                    pattern=pattern,
                                    top_level_dir=this_dir)
    standard_tests.addTests(package_tests)
    return standard_tests

Note that top_level_dir is required to handle specifying more than one test package at a time on the unittest command line.  Otherwise the second package gets a loader that already has _top_level_dir set, and so it fails to default to start_dir.  I suspect this is also a bug.

This works; it uses discovery to find the tests and returns them using the load test protocol.  Other methods could be used to construct the test to add as well.  But all have the serious disadvantage that the package name does not appear in the output.  Running the above test_pkg command line give results like this with -v:

  test_something (test_mytest.Test) ... ok

test_pkg is not mentioned.  This is merely annoying when running a single test package, but if you
do something like:

  python -m unittest -v test_pkg test_pkg2

You can't tell in the verbose output or the test failure output which
test package the tests are from.

In summary, unittest needs better support for test packages.

----------
messages: 162374
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Unittest CLI does not support test packages very well
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun  6 00:06:43 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 05 Jun 2012 22:06:43 +0000
Subject: [New-bugs-announce] [issue15008] PEP 362 reference implementation
	for 3.3
Message-ID: <1338934003.74.0.407210035969.issue15008@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

This issue will track implementation of PEP 362 functionality.

----------
components: Library (Lib)
files: pep362.1.patch
hgrepos: 131
keywords: patch
messages: 162377
nosy: Yury.Selivanov, brett.cannon, larry
priority: normal
severity: normal
status: open
title: PEP 362 reference implementation for 3.3
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25838/pep362.1.patch

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

From report at bugs.python.org  Wed Jun  6 00:28:27 2012
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 05 Jun 2012 22:28:27 +0000
Subject: [New-bugs-announce] [issue15009] urlsplit can't round-trip
	relative-host urls.
Message-ID: <1338935307.83.0.455725477737.issue15009@psf.upfronthosting.co.za>


New submission from Buck Golemon <buck at yelp.com>:

1) As long as x is valid, I expect that urlunsplit(urlsplit(x)) == x
2) yelp:///foo is a well-formed (albeit odd) url. It it similar to file:///tmp: it specifies the /foo resource, on the "current" host, using the yelp protocol (defined on mobile devices).

>>> from urlparse import urlsplit, urlunsplit
>>> urlunsplit(urlsplit('yelp:///foo'))
'yelp:/foo'

Urlparse / unparse has the same bug:

>>> urlunparse(urlparse('yelp:///foo'))
'yelp:/foo'

The file: protocol seems to be special-case, in an inappropriate manner:

>>> urlunsplit(urlsplit('file:///tmp'))
'file:///tmp'

----------
components: Library (Lib)
messages: 162378
nosy: Buck.Golemon
priority: normal
severity: normal
status: open
title: urlsplit can't round-trip relative-host urls.
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun  6 03:20:43 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jun 2012 01:20:43 +0000
Subject: [New-bugs-announce] [issue15010] unittest: _top_level_dir is
	incorrectly persisted	between calls to different load_test methods
Message-ID: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za>


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

During the execution of the load tests protocol, the loader instance will set its _top_level_dir attribute, and this will persist if the loader is passed on to another load_tests method.  If that method does not specify a top_level_dir in a discovery call, the wrong top_level_dir may be used, and loading will fail.

You can reproduce this by having two test *packages* with a load_tests method that calls discover in their __init__.py, and specify both package names to the unittest CLI.

----------
components: Library (Lib)
keywords: easy
messages: 162387
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  6 05:23:15 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jun 2012 03:23:15 +0000
Subject: [New-bugs-announce] [issue15011] Change Scripts to bin on Windows
Message-ID: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

Attached is a patch, originally written by Van Lindberg*, which changes Python's layout on Windows to more match all of the other operating systems we support. This patch starts by changing the layout of virtual environments, so the venv module creates an environment with the same layout you'd find on Linux. The most visible change is the Scripts folder becoming bin, and there are changes to capitalization of folders to match that of Linux as well.

If this is acceptable I can do the Windows installer change to have the installed layout follow what's in this patch.


* Van asked me to take this on for him. I will make sure he has a contributor agreement on file.

----------
components: Library (Lib), Windows
files: bin_directory.diff
keywords: patch
messages: 162391
nosy: brian.curtin, carljm, loewis, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Change Scripts to bin on Windows
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25841/bin_directory.diff

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

From report at bugs.python.org  Wed Jun  6 05:43:42 2012
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Jun 2012 03:43:42 +0000
Subject: [New-bugs-announce] [issue15012] test issue
Message-ID: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

IGNORE THIS ISSUE

This is a test of a newer bitbucket mirror setup by Atlassian. I just want to get a feel for how it works before I post about it on the dev blog.

----------
hgrepos: 132
messages: 162392
nosy: brian.curtin
priority: normal
severity: normal
status: open
title: test issue

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

From report at bugs.python.org  Wed Jun  6 09:44:23 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 06 Jun 2012 07:44:23 +0000
Subject: [New-bugs-announce] [issue15013] smtplib: add low-level APIs to doc?
Message-ID: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za>


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

In the smtplib doc I read:

  Low-level methods corresponding to the standard SMTP/ESMTP commands HELP, RSET, NOOP, MAIL, RCPT, and DATA are also supported. Normally these do not need to be called directly, so they are not documented here. For details, consult the module code.

Well, I think the documentation should include also those low-level apis (maybe in a separate subsection).

>From my POV, smtplib should implement the protocol, and give the programmers the tools to use the protocol as they prefers, and as a plus some companion methods to easy the most common operations.

I'm in need to use the low-level apis, and not finding them in the doc is a disservice to me (with my user hat on ;)) and just say "go read the source" is kinda rude and unexpected.

What do you think?

----------
assignee: docs at python
components: Documentation
messages: 162395
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: smtplib: add low-level APIs to doc?
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  6 10:11:21 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 06 Jun 2012 08:11:21 +0000
Subject: [New-bugs-announce] [issue15014] smtplib: allow to choose auth
	method on login()
Message-ID: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za>


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

Hello,
I'm writing some tests from an MTA, and so I'm using smtplib. Sadly the login() method doesn't allow to choose the auth method to use (but it's selected from a static list compared with what's advertized from the MTA) while it would be useful to be able to choose the AUTH method to use.

----------
components: Library (Lib)
messages: 162396
nosy: sandro.tosi
priority: normal
severity: normal
status: open
title: smtplib: allow to choose auth method on login()
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun  6 11:05:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Piel?=)
Date: Wed, 06 Jun 2012 09:05:29 +0000
Subject: [New-bugs-announce] [issue15015] Access to non-existing "future"
	attribute in error path	of futures
Message-ID: <1338973529.66.0.217110755385.issue15015@psf.upfronthosting.co.za>


New submission from ?ric Piel <e.a.b.piel at tudelft.nl>:

concurrent.futures.Future.set_running_or_notify_cancel() has a reference to self.future, although Future has no future attribute. It's probably due to a copy/paste error. As it's in an error handling code path, most of the time the code is never used. Nevertheless it's worthy to fix it so that the right exception happens in case of error. This was detected by pylint.

Attaching a patch that fixes the error.

----------
components: Library (Lib)
files: future-fix-attribute.patch
keywords: patch
messages: 162398
nosy: pieleric
priority: normal
severity: normal
status: open
title: Access to non-existing "future" attribute in error path of futures
versions: Python 3.4
Added file: http://bugs.python.org/file25844/future-fix-attribute.patch

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

From report at bugs.python.org  Wed Jun  6 11:13:28 2012
From: report at bugs.python.org (Dmitry Shachnev)
Date: Wed, 06 Jun 2012 09:13:28 +0000
Subject: [New-bugs-announce] [issue15016] [patch] add special case for latin
	messages in	email.mime.text
Message-ID: <1338974008.79.0.846609742921.issue15016@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev <Mitya57 at gmail.com>:

(Follow-up to issue 14380)

The attached patch makes the email.mime.text.MIMEText constructor use the iso-8859-1 (aka latin-1) encoding for messages where all characters are in range(256). This also makes them use quoted-printable transfer encoding instead of base64.

So, the current algorithm of guessing encoding is as follows:

- all characters are in range(128) -> encoding is us-ascii
- all characters are in range(256) -> encoding is iso-8859-1 (aka latin-1)
- else                             -> encoding is utf-8

----------
components: email
messages: 162399
nosy: barry, mitya57, r.david.murray
priority: normal
severity: normal
status: open
title: [patch] add special case for latin messages in email.mime.text
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  6 12:40:13 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jun 2012 10:40:13 +0000
Subject: [New-bugs-announce] [issue15017] threading.Lock documentation
	conflict
Message-ID: <1338979213.38.0.308308399616.issue15017@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

In the description of section 16.2.2. Lock objects:

    If an attempt is made to release an unlocked lock, a RuntimeError
    will be raised.

In the description of Lock.release():

    When invoked on an unlocked lock, a ThreadError is raised.

Apparently, ThreadError is the correct exception.

----------
assignee: petri.lehtinen
components: Documentation, Library (Lib)
keywords: easy
messages: 162401
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: threading.Lock documentation conflict
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  6 14:51:43 2012
From: report at bugs.python.org (Marcus von Appen)
Date: Wed, 06 Jun 2012 12:51:43 +0000
Subject: [New-bugs-announce] [issue15018] Incomplete Python LDFLAGS and
	CPPFLAGS used for	extension modules on posix
Message-ID: <1338987103.32.0.200789346526.issue15018@psf.upfronthosting.co.za>


New submission from Marcus von Appen <mva at sysfault.org>:

If CPython is built and installed with additional CPPFLAGS and/or LDFLAGS on a posix platform, those flags are not passed to C extension modules, leaving users (in the worst case) lost without the ability to build and install C extension modules, if the flags are important for detecting include files or linking.

Example:

* Python shall be built with GNU pthreads (--with-pth)
* The pth libs are not installed in any default location, CPP and LD know about, but somewhere else (e.g. /usr/local/lib/pth/ and /usr/local/include/pth/)
* Appropriate CPPFLAGS="-I/usr/local/include/pth" and LDFLAGS="-L/usr/local/lib/pth" are defined in the environment for the build.

Python gets built and installed. Result in /wherever/pythonX.X/config/Makefile:

...
OPT=        
BASECFLAGS= -fno-strict-aliasing
CFLAGS=     $(BASECFLAGS) -pipe $(OPT) $(EXTRA_CFLAGS)
...
CPPFLAGS=   -I. -IInclude -I$(srcdir)/Include -I/usr/local/include/pth
LDFLAGS=    -L/usr/local/lib/pth
...

Invocation of python-config --cflags:

# python-config --cflags 
-I/whereever/include/pythonX.X -I/whereever/include/pythonX.X -fno-strict-aliasing -pipe 

Invocation of python-config --ldflags:

# python-config --ldflags 
-L/whereever/lib/pythonX.X/config -lpth -lutil -lm -lpythonX.X


So far, so problematic. Since Python.h incorporates pth.h, compiling something without defining the necessary CPPFLAGS manually will fail. Same for linking.

The issue is *not* limited to --with-pth, but to any CPPFLAGS/LDFLAGS settings that are necessary to get CPython to work on the target platform. One might argue that CPPFLAGS should go to CFLAGS, but that contradicts the purpose of CPPFLAGS and CFLAGS.

At least for posix-alike platforms (those for which _init_posix() is called in distutils/sysconfig.py), it is necessary that both, python-config as well as the distutils internals add the appropriate CPPFLAGS.

It might be argued that one should use CFLAGS instead of CPPFLAGS for such important additional flags, but what shall be done with LDFLAGS then?

----------
assignee: eric.araujo
components: Build, Distutils, Extension Modules
messages: 162405
nosy: eric.araujo, marcusva, tarek
priority: normal
severity: normal
status: open
title: Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix
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/issue15018>
_______________________________________

From report at bugs.python.org  Wed Jun  6 16:47:45 2012
From: report at bugs.python.org (=?utf-8?b?SsSBbmlz?=)
Date: Wed, 06 Jun 2012 14:47:45 +0000
Subject: [New-bugs-announce] [issue15019] Sting termination on Linux
Message-ID: <1338994065.34.0.987983176333.issue15019@psf.upfronthosting.co.za>


New submission from J?nis <janis.judvaitis at gmail.com>:

test = "Hi there :)"
    print len(test), test // Prints "11 Hi there :)"
    test = test.replace(" ", "\x00")
    print len(test), test // Prints "11 

On Windows '\x00' is same as ' ', but on linux string is terminated at first occurance of '\x00'. Results on problems with pySerial and binary data, so I can't replace '\x00' with ' '.

----------
components: Interpreter Core
messages: 162413
nosy: jjanis
priority: normal
severity: normal
status: open
title: Sting termination on Linux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  7 00:37:29 2012
From: report at bugs.python.org (Joshua Cogliati)
Date: Wed, 06 Jun 2012 22:37:29 +0000
Subject: [New-bugs-announce] [issue15020] Poor default value for progname
Message-ID: <1339022249.32.0.319991311655.issue15020@psf.upfronthosting.co.za>


New submission from Joshua Cogliati <jrincayc at gmail.com>:

In Python/pythonrun.c the following definition exists:
static wchar_t *progname = L"python";

This is then used by Py_GetProgramName which is used by calculate_path in Modules/getpath.c 

Since in python 3, the default executable is python3, and not python, when calculate_path searches for "python" it will find where python 2 is installed instead of where python3 is installed.  This is the error message that this causes:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

I recommend that line be changed to:
static wchar_t *progname = L"python3";

since that is the default executable name.

For my purposes (which is making an executable that embedds python 3), I was able to work around this by calling: 
Py_SetProgramName(L"python3");
before
Py_Initialize();

----------
messages: 162425
nosy: Joshua.Cogliati
priority: normal
severity: normal
status: open
title: Poor default value for progname
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  7 02:01:11 2012
From: report at bugs.python.org (Abhishek Singh)
Date: Thu, 07 Jun 2012 00:01:11 +0000
Subject: [New-bugs-announce] [issue15021] xmlrpc server hangs
Message-ID: <1339027271.75.0.304876559161.issue15021@psf.upfronthosting.co.za>


New submission from Abhishek Singh <abhishekrsingh at gmail.com>:

Hi Terry,

I am running into a xmlrpc server issue where it just hangs.

  9.914048    127.0.0.1 -> 127.0.0.1    TCP 52327 > 8012 [SYN] Seq=0 Win=32792 Len=0 MSS=16396 TSV=3131436173 TSER=0 WS=6

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 3c 27 64 40 00 40 06 15 56 7f 00 00 01 7f 00   .<'d at .@..V......
0020  00 01 cc 67 1f 4c ee eb cb e9 00 00 00 00 a0 02   ...g.L..........
0030  80 18 41 d1 00 00 02 04 40 0c 04 02 08 0a ba a5   ..A..... at .......
0040  ec 8d 00 00 00 00 01 03 03 06                     ..........

  9.914060    127.0.0.1 -> 127.0.0.1    TCP 8012 > 52327 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=3131436173 TSER=3131436173 WS=6

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 3c 00 00 40 00 40 06 3c ba 7f 00 00 01 7f 00   .<.. at .@.<.......
0020  00 01 1f 4c cc 67 0e c1 e9 95 ee eb cb ea a0 12   ...L.g..........
0030  80 00 a2 4d 00 00 02 04 40 0c 04 02 08 0a ba a5   ...M.... at .......
0040  ec 8d ba a5 ec 8d 01 03 03 06                     ..........

  9.914070    127.0.0.1 -> 127.0.0.1    TCP 52327 > 8012 [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=3131436173 TSER=3131436173

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 27 65 40 00 40 06 15 5d 7f 00 00 01 7f 00   .4'e at .@..]......
0020  00 01 cc 67 1f 4c ee eb cb ea 0e c1 e9 96 80 10   ...g.L..........
0030  02 01 89 70 00 00 01 01 08 0a ba a5 ec 8d ba a5   ...p............
0040  ec 8d                                             ..

  9.914123    127.0.0.1 -> 127.0.0.1    TCP 52327 > 8012 [PSH, ACK] Seq=1 Ack=1 Win=32832 Len=141 TSV=3131436173 TSER=3131436173

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 c1 27 66 40 00 40 06 14 cf 7f 00 00 01 7f 00   ..'f at .@.........
0020  00 01 cc 67 1f 4c ee eb cb ea 0e c1 e9 96 80 18   ...g.L..........
0030  02 01 fe b5 00 00 01 01 08 0a ba a5 ec 8d ba a5   ................
0040  ec 8d 50 4f 53 54 20 2f 20 48 54 54 50 2f 31 2e   ..POST / HTTP/1.
0050  30 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f   0..Host: localho
0060  73 74 3a 38 30 31 32 0d 0a 55 73 65 72 2d 41 67   st:8012..User-Ag
0070  65 6e 74 3a 20 78 6d 6c 72 70 63 6c 69 62 2e 70   ent: xmlrpclib.p
0080  79 2f 31 2e 30 2e 31 20 28 62 79 20 77 77 77 2e   y/1.0.1 (by www.
0090  70 79 74 68 6f 6e 77 61 72 65 2e 63 6f 6d 29 0d   pythonware.com).
00a0  0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74   .Content-Type: t
00b0  65 78 74 2f 78 6d 6c 0d 0a 43 6f 6e 74 65 6e 74   ext/xml..Content
00c0  2d 4c 65 6e 67 74 68 3a 20 39 38 0d 0a 0d 0a      -Length: 98....

  9.914130    127.0.0.1 -> 127.0.0.1    TCP 8012 > 52327 [ACK] Seq=1 Ack=142 Win=33856 Len=0 TSV=3131436173 TSER=3131436173

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 05 1b 40 00 40 06 37 a7 7f 00 00 01 7f 00   .4.. at .@.7.......
0020  00 01 1f 4c cc 67 0e c1 e9 96 ee eb cc 77 80 10   ...L.g.......w..
0030  02 11 88 d3 00 00 01 01 08 0a ba a5 ec 8d ba a5   ................
0040  ec 8d                                             ..

  9.914171    127.0.0.1 -> 127.0.0.1    TCP 52327 > 8012 [PSH, ACK] Seq=142 Ack=1 Win=32832 Len=98 TSV=3131436173 TSER=3131436173

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 96 27 67 40 00 40 06 14 f9 7f 00 00 01 7f 00   ..'g at .@.........
0020  00 01 cc 67 1f 4c ee eb cc 77 0e c1 e9 96 80 18   ...g.L...w......
0030  02 01 fe 8a 00 00 01 01 08 0a ba a5 ec 8d ba a5   ................
0040  ec 8d 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d   ..<?xml version=
0050  27 31 2e 30 27 3f 3e 0a 3c 6d 65 74 68 6f 64 43   '1.0'?>.<methodC
0060  61 6c 6c 3e 0a 3c 6d 65 74 68 6f 64 4e 61 6d 65   all>.<methodName
0070  3e 69 6e 66 6f 3c 2f 6d 65 74 68 6f 64 4e 61 6d   >info</methodNam
0080  65 3e 0a 3c 70 61 72 61 6d 73 3e 0a 3c 2f 70 61   e>.<params>.</pa
0090  72 61 6d 73 3e 0a 3c 2f 6d 65 74 68 6f 64 43 61   rams>.</methodCa
00a0  6c 6c 3e 0a                                       ll>.

  9.914177    127.0.0.1 -> 127.0.0.1    TCP 8012 > 52327 [ACK] Seq=1 Ack=240 Win=33856 Len=0 TSV=3131436173 TSER=3131436173

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 05 1c 40 00 40 06 37 a6 7f 00 00 01 7f 00   .4.. at .@.7.......
0020  00 01 1f 4c cc 67 0e c1 e9 96 ee eb cc d9 80 10   ...L.g..........
0030  02 11 88 71 00 00 01 01 08 0a ba a5 ec 8d ba a5   ...q............
0040  ec 8d                                             ..


<Client sent a request, and server just hangs here>

When I look at the server, it is stuck here:

(gdb) bt
#0  0x00310424 in __kernel_vsyscall ()
#1  0x003df758 in recv () from /lib/libpthread.so.0
#2  0x00dbbca5 in sock_recv_guts (s=0xb7489890, cbuf=<value optimized out>, len=8192, flags=0) at /home/shankar/python/Python-2.7.3/Modules/socketmodule.c:2361
#3  0x00dbbee6 in sock_recv (s=0xb7489890, args=0xb746780c) at /home/shankar/python/Python-2.7.3/Modules/socketmodule.c:2442
#4  0x080e1071 in call_function (f=0x8db3a3c, throwflag=0) at Python/ceval.c:4021
#5  PyEval_EvalFrameEx (f=0x8db3a3c, throwflag=0) at Python/ceval.c:2666
#6  0x080e2c1b in PyEval_EvalCodeEx (co=0xb77211d0, globals=0xb7706604, locals=0x0, args=0x8db3a14, argcount=2, kws=0x8db3a1c, kwcount=0, defs=0xb74a79b8, defcount=1, closure=0x0) at Python/ceval.c:3253
#7  0x080e12e9 in fast_function (f=0x8db38cc, throwflag=0) at Python/ceval.c:4117
#8  call_function (f=0x8db38cc, throwflag=0) at Python/ceval.c:4042
#9  PyEval_EvalFrameEx (f=0x8db38cc, throwflag=0) at Python/ceval.c:2666
#10 0x080e1b55 in fast_function (f=0x8db3774, throwflag=0) at Python/ceval.c:4107
#11 call_function (f=0x8db3774, throwflag=0) at Python/ceval.c:4042
#12 PyEval_EvalFrameEx (f=0x8db3774, throwflag=0) at Python/ceval.c:2666
#13 0x080e1b55 in fast_function (f=0x8db2f3c, throwflag=0) at Python/ceval.c:4107
#14 call_function (f=0x8db2f3c, throwflag=0) at Python/ceval.c:4042
#15 PyEval_EvalFrameEx (f=0x8db2f3c, throwflag=0) at Python/ceval.c:2666
#16 0x080e2c1b in PyEval_EvalCodeEx (co=0xb747c458, globals=0xb7477714, locals=0x0, args=0xb7469538, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#17 0x0813ee2a in function_call (func=0xb748b8b4, arg=0xb746952c, kw=0x0) at Objects/funcobject.c:526
#18 0x0805d90a in PyObject_Call (func=0xb748b8b4, arg=0xb746952c, kw=0x0) at Objects/abstract.c:2529
#19 0x080657f1 in instancemethod_call (func=0xb748b8b4, arg=<value optimized out>, kw=0x0) at Objects/classobject.c:2578
#20 0x0805d90a in PyObject_Call (func=0xb7470054, arg=0xb74896bc, kw=0x0) at Objects/abstract.c:2529
#21 0x080db852 in PyEval_CallObjectWithKeywords (func=0xb7470054, arg=0xb74896bc, kw=0x0) at Python/ceval.c:3890
#22 0x08067900 in PyInstance_New (klass=0xb747ff8c, arg=0xb74896bc, kw=0x0) at Objects/classobject.c:571
#23 0x0805d90a in PyObject_Call (func=0xb747ff8c, arg=0xb74896bc, kw=0x0) at Objects/abstract.c:2529
#24 0x080e04ba in do_call (f=0x8db2dd4, throwflag=0) at Python/ceval.c:4239
#25 call_function (f=0x8db2dd4, throwflag=0) at Python/ceval.c:4044
#26 PyEval_EvalFrameEx (f=0x8db2dd4, throwflag=0) at Python/ceval.c:2666
#27 0x080e1b55 in fast_function (f=0x8db2c6c, throwflag=0) at Python/ceval.c:4107
#28 call_function (f=0x8db2c6c, throwflag=0) at Python/ceval.c:4042
#29 PyEval_EvalFrameEx (f=0x8db2c6c, throwflag=0) at Python/ceval.c:2666
#30 0x080e1b55 in fast_function (f=0x8db26dc, throwflag=0) at Python/ceval.c:4107
#31 call_function (f=0x8db26dc, throwflag=0) at Python/ceval.c:4042
#32 PyEval_EvalFrameEx (f=0x8db26dc, throwflag=0) at Python/ceval.c:2666
#33 0x080e1b55 in fast_function (f=0x8db251c, throwflag=0) at Python/ceval.c:4107
#34 call_function (f=0x8db251c, throwflag=0) at Python/ceval.c:4042
#35 PyEval_EvalFrameEx (f=0x8db251c, throwflag=0) at Python/ceval.c:2666
#36 0x080e1b55 in fast_function (f=0x8d3855c, throwflag=0) at Python/ceval.c:4107
#37 call_function (f=0x8d3855c, throwflag=0) at Python/ceval.c:4042
#38 PyEval_EvalFrameEx (f=0x8d3855c, throwflag=0) at Python/ceval.c:2666
#39 0x080e1b55 in fast_function (f=0x8757eac, throwflag=0) at Python/ceval.c:4107
#40 call_function (f=0x8757eac, throwflag=0) at Python/ceval.c:4042
#41 PyEval_EvalFrameEx (f=0x8757eac, throwflag=0) at Python/ceval.c:2666
#42 0x080e2c1b in PyEval_EvalCodeEx (co=0xb76f99b0, globals=0xb779935c, locals=0x0, args=0x870ec84, argcount=0, kws=0x870ec84, kwcount=0, defs=0xb7467778, defcount=1, closure=0x0) at Python/ceval.c:3253
#43 0x080e12e9 in fast_function (f=0x870eb44, throwflag=0) at Python/ceval.c:4117
#44 call_function (f=0x870eb44, throwflag=0) at Python/ceval.c:4042
#45 PyEval_EvalFrameEx (f=0x870eb44, throwflag=0) at Python/ceval.c:2666
#46 0x080e2c1b in PyEval_EvalCodeEx (co=0xb76f99f8, globals=0xb779935c, locals=0xb779935c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#47 0x080e2d47 in PyEval_EvalCode (co=0xb76f99f8, globals=0xb779935c, locals=0xb779935c) at Python/ceval.c:667
#48 0x08100276 in run_mod (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb779935c, locals=0xb779935c, closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:1353
#49 PyRun_FileExFlags (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb779935c, locals=0xb779935c, closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:1339
#50 0x081004d2 in PyRun_SimpleFileExFlags (fp=0x870eb38, filename=0xbfb0388b "/home/shankar/apsim-6.2/1.1.5/apsim.py", closeit=1, flags=0xbfb0361c) at Python/pythonrun.c:943
#51 0x080592f1 in Py_Main (argc=8, argv=0xbfb03704) at Modules/main.c:639
#52 0x0805839b in main (argc=8, argv=0xbfb03704) at ./Modules/python.c:23
(gdb) q


Here is good/complete one (another process, serving 8011)

  9.911198    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 TSV=3131436170 TSER=3131436170 WS=6

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 3c 00 00 40 00 40 06 3c ba 7f 00 00 01 7f 00   .<.. at .@.<.......
0020  00 01 1f 4b d8 4b 01 ce ef bc 30 38 0b 97 a0 12   ...K.K....08....
0030  80 00 1c 44 00 00 02 04 40 0c 04 02 08 0a ba a5   ...D.... at .......
0040  ec 8a ba a5 ec 8a 01 03 03 06                     ..........

  9.911208    127.0.0.1 -> 127.0.0.1    TCP 55371 > 8011 [ACK] Seq=1 Ack=1 Win=32832 Len=0 TSV=3131436170 TSER=3131436170

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 e7 1d 40 00 40 06 55 a4 7f 00 00 01 7f 00   .4.. at .@.U.......
0020  00 01 d8 4b 1f 4b 30 38 0b 97 01 ce ef bd 80 10   ...K.K08........
0030  02 01 03 67 00 00 01 01 08 0a ba a5 ec 8a ba a5   ...g............
0040  ec 8a                                             ..

  9.911260    127.0.0.1 -> 127.0.0.1    TCP 55371 > 8011 [PSH, ACK] Seq=1 Ack=1 Win=32832 Len=141 TSV=3131436170 TSER=3131436170

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 c1 e7 1e 40 00 40 06 55 16 7f 00 00 01 7f 00   .... at .@.U.......
0020  00 01 d8 4b 1f 4b 30 38 0b 97 01 ce ef bd 80 18   ...K.K08........
0030  02 01 fe b5 00 00 01 01 08 0a ba a5 ec 8a ba a5   ................
0040  ec 8a 50 4f 53 54 20 2f 20 48 54 54 50 2f 31 2e   ..POST / HTTP/1.
0050  30 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f   0..Host: localho
0060  73 74 3a 38 30 31 31 0d 0a 55 73 65 72 2d 41 67   st:8011..User-Ag
0070  65 6e 74 3a 20 78 6d 6c 72 70 63 6c 69 62 2e 70   ent: xmlrpclib.p
0080  79 2f 31 2e 30 2e 31 20 28 62 79 20 77 77 77 2e   y/1.0.1 (by www.
0090  70 79 74 68 6f 6e 77 61 72 65 2e 63 6f 6d 29 0d   pythonware.com).
00a0  0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74   .Content-Type: t
00b0  65 78 74 2f 78 6d 6c 0d 0a 43 6f 6e 74 65 6e 74   ext/xml..Content
00c0  2d 4c 65 6e 67 74 68 3a 20 39 38 0d 0a 0d 0a      -Length: 98....

  9.911267    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [ACK] Seq=1 Ack=142 Win=33856 Len=0 TSV=3131436171 TSER=3131436170

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 03 37 40 00 40 06 39 8b 7f 00 00 01 7f 00   .4.7 at .@.9.......
0020  00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 24 80 10   ...K.K....08.$..
0030  02 11 02 c9 00 00 01 01 08 0a ba a5 ec 8b ba a5   ................
0040  ec 8a                                             ..

  9.911307    127.0.0.1 -> 127.0.0.1    TCP 55371 > 8011 [PSH, ACK] Seq=142 Ack=1 Win=32832 Len=98 TSV=3131436171 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 96 e7 1f 40 00 40 06 55 40 7f 00 00 01 7f 00   .... at .@.U at ......
0020  00 01 d8 4b 1f 4b 30 38 0c 24 01 ce ef bd 80 18   ...K.K08.$......
0030  02 01 fe 8a 00 00 01 01 08 0a ba a5 ec 8b ba a5   ................
0040  ec 8b 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d   ..<?xml version=
0050  27 31 2e 30 27 3f 3e 0a 3c 6d 65 74 68 6f 64 43   '1.0'?>.<methodC
0060  61 6c 6c 3e 0a 3c 6d 65 74 68 6f 64 4e 61 6d 65   all>.<methodName
0070  3e 69 6e 66 6f 3c 2f 6d 65 74 68 6f 64 4e 61 6d   >info</methodNam
0080  65 3e 0a 3c 70 61 72 61 6d 73 3e 0a 3c 2f 70 61   e>.<params>.</pa
0090  72 61 6d 73 3e 0a 3c 2f 6d 65 74 68 6f 64 43 61   rams>.</methodCa
00a0  6c 6c 3e 0a                                       ll>.

  9.911313    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [ACK] Seq=1 Ack=240 Win=33856 Len=0 TSV=3131436171 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 03 38 40 00 40 06 39 8a 7f 00 00 01 7f 00   .4.8 at .@.9.......
0020  00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 86 80 10   ...K.K....08....
0030  02 11 02 66 00 00 01 01 08 0a ba a5 ec 8b ba a5   ...f............
0040  ec 8b                                             ..

  9.911990    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [PSH, ACK] Seq=1 Ack=240 Win=33856 Len=508 TSV=3131436171 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  02 30 03 39 40 00 40 06 37 8d 7f 00 00 01 7f 00   .0.9 at .@.7.......
0020  00 01 1f 4b d8 4b 01 ce ef bd 30 38 0c 86 80 18   ...K.K....08....
0030  02 11 00 25 00 00 01 01 08 0a ba a5 ec 8b ba a5   ...%............
0040  ec 8b 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f   ..HTTP/1.0 200 O
0050  4b 0d 0a 53 65 72 76 65 72 3a 20 42 61 73 65 48   K..Server: BaseH
0060  54 54 50 2f 30 2e 33 20 50 79 74 68 6f 6e 2f 32   TTP/0.3 Python/2
0070  2e 37 2e 33 0d 0a 44 61 74 65 3a 20 57 65 64 2c   .7.3..Date: Wed,
0080  20 30 36 20 4a 75 6e 20 32 30 31 32 20 32 33 3a    06 Jun 2012 23:
0090  33 34 3a 32 31 20 47 4d 54 0d 0a 43 6f 6e 74 65   34:21 GMT..Conte
00a0  6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f 78 6d   nt-type: text/xm
00b0  6c 0d 0a 43 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74   l..Content-lengt
00c0  68 3a 20 33 37 32 0d 0a 0d 0a 3c 3f 78 6d 6c 20   h: 372....<?xml
00d0  76 65 72 73 69 6f 6e 3d 27 31 2e 30 27 3f 3e 0a   version='1.0'?>.
00e0  3c 6d 65 74 68 6f 64 52 65 73 70 6f 6e 73 65 3e   <methodResponse>
00f0  0a 3c 70 61 72 61 6d 73 3e 0a 3c 70 61 72 61 6d   .<params>.<param
0100  3e 0a 3c 76 61 6c 75 65 3e 3c 73 74 72 69 6e 67   >.<value><string
0110  3e 70 6f 72 74 20 3d 20 38 30 31 31 0a 73 74 61   >port = 8011.sta
0120  72 74 5f 74 69 6d 65 20 3d 20 32 30 31 32 2d 30   rt_time = 2012-0
0130  36 2d 30 35 20 32 33 3a 32 37 3a 34 39 0a 75 70   6-05 23:27:49.up
0140  74 69 6d 65 20 3d 20 36 31 35 39 32 0a 6e 75 6d   time = 61592.num
0150  61 70 73 20 3d 20 35 0a 6e 75 6d 73 74 73 20 3d   aps = 5.numsts =
0160  20 39 30 0a 66 69 72 73 74 5f 61 70 5f 69 70 20    90.first_ap_ip
0170  3d 20 31 37 32 2e 33 32 2e 31 2e 35 38 0a 66 69   = 172.32.1.58.fi
0180  72 73 74 5f 73 74 5f 69 70 20 3d 20 30 2e 30 2e   rst_st_ip = 0.0.
0190  30 2e 30 0a 66 69 72 73 74 5f 73 74 5f 6d 61 63   0.0.first_st_mac
01a0  20 3d 20 30 30 3a 66 66 3a 30 30 3a 30 30 3a 30    = 00:ff:00:00:0
01b0  33 3a 64 65 0a 65 74 68 30 5f 6d 61 63 20 3d 20   3:de.eth0_mac =
01c0  30 30 3a 30 32 3a 30 34 3a 30 30 3a 30 30 3a 33   00:02:04:00:00:3
01d0  37 0a 66 69 72 73 74 5f 61 70 20 3d 20 73 69 6d   7.first_ap = sim
01e0  5f 61 70 5f 30 35 35 5f 30 30 30 0a 66 69 72 73   _ap_055_000.firs
01f0  74 5f 73 74 20 3d 20 73 69 6d 5f 73 74 61 5f 39   t_st = sim_sta_9
0200  39 30 5f 30 30 30 0a 3c 2f 73 74 72 69 6e 67 3e   90_000.</string>
0210  3c 2f 76 61 6c 75 65 3e 0a 3c 2f 70 61 72 61 6d   </value>.</param
0220  3e 0a 3c 2f 70 61 72 61 6d 73 3e 0a 3c 2f 6d 65   >.</params>.</me
0230  74 68 6f 64 52 65 73 70 6f 6e 73 65 3e 0a         thodResponse>.

  9.912012    127.0.0.1 -> 127.0.0.1    TCP 55371 > 8011 [ACK] Seq=240 Ack=509 Win=33920 Len=0 TSV=3131436171 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 e7 20 40 00 40 06 55 a1 7f 00 00 01 7f 00   .4. @. at .U.......
0020  00 01 d8 4b 1f 4b 30 38 0c 86 01 ce f1 b9 80 10   ...K.K08........
0030  02 12 00 69 00 00 01 01 08 0a ba a5 ec 8b ba a5   ...i............
0040  ec 8b                                             ..

  9.912038    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [FIN, ACK] Seq=509 Ack=240 Win=33856 Len=0 TSV=3131436171 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 03 3a 40 00 40 06 39 88 7f 00 00 01 7f 00   .4.:@. at .9.......
0020  00 01 1f 4b d8 4b 01 ce f1 b9 30 38 0c 86 80 11   ...K.K....08....
0030  02 11 00 69 00 00 01 01 08 0a ba a5 ec 8b ba a5   ...i............
0040  ec 8b                                             ..

  9.912779    127.0.0.1 -> 127.0.0.1    TCP 55371 > 8011 [FIN, ACK] Seq=240 Ack=510 Win=33920 Len=0 TSV=3131436172 TSER=3131436171

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 e7 21 40 00 40 06 55 a0 7f 00 00 01 7f 00   .4.!@. at .U.......
0020  00 01 d8 4b 1f 4b 30 38 0c 86 01 ce f1 ba 80 11   ...K.K08........
0030  02 12 00 66 00 00 01 01 08 0a ba a5 ec 8c ba a5   ...f............
0040  ec 8b                                             ..

  9.912790    127.0.0.1 -> 127.0.0.1    TCP 8011 > 55371 [ACK] Seq=510 Ack=241 Win=33856 Len=0 TSV=3131436172 TSER=3131436172

0000  00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   ..............E.
0010  00 34 03 3b 40 00 40 06 39 87 7f 00 00 01 7f 00   .4.;@. at .9.......
0020  00 01 1f 4b d8 4b 01 ce f1 ba 30 38 0c 87 80 10   ...K.K....08....
0030  02 11 00 66 00 00 01 01 08 0a ba a5 ec 8c ba a5   ...f............
0040  ec 8c                                             ..

A good server is always at select:

(gdb) bt
#0  0x00bb8424 in __kernel_vsyscall ()
#1  0x0030e921 in select () from /lib/libc.so.6
#2  0x0016baf8 in select_select (self=0x0, args=0xb754052c) at /home/shankar/python/Python-2.7.3/Modules/selectmodule.c:271
#3  0x080e1071 in call_function (f=0xa35fcec, throwflag=0) at Python/ceval.c:4021
#4  PyEval_EvalFrameEx (f=0xa35fcec, throwflag=0) at Python/ceval.c:2666
#5  0x080e1b55 in fast_function (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:4107
#6  call_function (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:4042
#7  PyEval_EvalFrameEx (f=0xa2bf7bc, throwflag=0) at Python/ceval.c:2666
#8  0x080e1b55 in fast_function (f=0x9cd5eac, throwflag=0) at Python/ceval.c:4107
#9  call_function (f=0x9cd5eac, throwflag=0) at Python/ceval.c:4042
#10 PyEval_EvalFrameEx (f=0x9cd5eac, throwflag=0) at Python/ceval.c:2666
#11 0x080e2c1b in PyEval_EvalCodeEx (co=0xb77d09b0, globals=0xb787035c, locals=0x0, args=0x9c8cc84, argcount=0, kws=0x9c8cc84, kwcount=0, defs=0xb753e778, defcount=1, closure=0x0) at Python/ceval.c:3253
#12 0x080e12e9 in fast_function (f=0x9c8cb44, throwflag=0) at Python/ceval.c:4117
#13 call_function (f=0x9c8cb44, throwflag=0) at Python/ceval.c:4042
#14 PyEval_EvalFrameEx (f=0x9c8cb44, throwflag=0) at Python/ceval.c:2666
#15 0x080e2c1b in PyEval_EvalCodeEx (co=0xb77d09f8, globals=0xb787035c, locals=0xb787035c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#16 0x080e2d47 in PyEval_EvalCode (co=0xb77d09f8, globals=0xb787035c, locals=0xb787035c) at Python/ceval.c:667
#17 0x08100276 in run_mod (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb787035c, locals=0xb787035c, closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:1353
#18 PyRun_FileExFlags (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", start=257, globals=0xb787035c, locals=0xb787035c, closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:1339
#19 0x081004d2 in PyRun_SimpleFileExFlags (fp=0x9c8cb38, filename=0xbfee888b "/home/shankar/apsim-6.2/1.1.5/apsim.py", closeit=1, flags=0xbfee6b2c) at Python/pythonrun.c:943
#20 0x080592f1 in Py_Main (argc=8, argv=0xbfee6c14) at Modules/main.c:639
#21 0x0805839b in main (argc=8, argv=0xbfee6c14) at ./Modules/python.c:23

----------
components: XML
messages: 162432
nosy: Abhishek.Singh
priority: normal
severity: normal
status: open
title: xmlrpc server hangs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  7 05:37:40 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 07 Jun 2012 03:37:40 +0000
Subject: [New-bugs-announce] [issue15022] types.SimpleNamespace needs to be
	picklable
Message-ID: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In issue 15003 Raymond recommended that types.SimpleNamespace be picklable.  I'll get a patch up as soon as I can to add this capability.

----------
messages: 162453
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: types.SimpleNamespace needs to be picklable
type: behavior

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

From report at bugs.python.org  Thu Jun  7 07:23:12 2012
From: report at bugs.python.org (Julian Berman)
Date: Thu, 07 Jun 2012 05:23:12 +0000
Subject: [New-bugs-announce] [issue15023] listextend (and therefore
	list.extend and list.__init__)	peek at len before iter
Message-ID: <1339046592.67.0.693988189804.issue15023@psf.upfronthosting.co.za>


New submission from Julian Berman <Julian+Python.org at GrayVines.com>:

The following code raises an unexpected exception:

    class Foo(object):
        def __len__(self):
            raise Exception()
        def __iter__(self):
            return iter([])

    list(Foo())


In the optimizations being done in listextend, it appears len is getting called first for some reason (sorry, haven't gotten a chance to step through it carefully yet).

Tangentially, PyPy (correctly I guess) throws no such exception.

----------
components: Interpreter Core
messages: 162457
nosy: Julian
priority: normal
severity: normal
status: open
title: listextend (and therefore list.extend and list.__init__) peek at len before iter
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/issue15023>
_______________________________________

From report at bugs.python.org  Thu Jun  7 09:40:56 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Jun 2012 07:40:56 +0000
Subject: [New-bugs-announce] [issue15024] Split enhanced assertion support
	out as a	unittest.TestCase base class
Message-ID: <1339054856.06.0.856824140254.issue15024@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The unittest module has some lovely enhanced comparison operations, but they're currently hard to access outside a test run.

It would be rather convenient if they were split out into a separate base class so they could be used directly without needing to create an actual test case.

Possible API:

  class Assertions:
    # All the enhanced assertion machinery goes here
    # Nothing related to actually running test cases

  class TestCase(Assertions):
    # This adds support for setUp, tearDown, addCleanup etc, etc

My current workaround is to just define a dummy "runTest" method in a subclass and use that:

>>> class Assertions(unittest.TestCase):
...     def runTest(self): pass
... 
>>> check = Assertions()
>>> check.assertEqual([], ())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/unittest/case.py", line 511, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/usr/lib64/python2.7/unittest/case.py", line 504, in _baseAssertEqual
    raise self.failureException(msg)
AssertionError: [] != ()
>>> check.assertEqual([1], [2])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/unittest/case.py", line 511, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/usr/lib64/python2.7/unittest/case.py", line 740, in assertListEqual
    self.assertSequenceEqual(list1, list2, msg, seq_type=list)
  File "/usr/lib64/python2.7/unittest/case.py", line 722, in assertSequenceEqual
    self.fail(msg)
  File "/usr/lib64/python2.7/unittest/case.py", line 408, in fail
    raise self.failureException(msg)
AssertionError: Lists differ: [1] != [2]

First differing element 0:
1
2

- [1]
+ [2]

----------
messages: 162463
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
status: open
title: Split enhanced assertion support out as a unittest.TestCase base class

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

From report at bugs.python.org  Thu Jun  7 13:15:42 2012
From: report at bugs.python.org (Craig Loftus)
Date: Thu, 07 Jun 2012 11:15:42 +0000
Subject: [New-bugs-announce] [issue15025] httplib and http.client are
	missing response messages	for defined WEBDAV responses, e.g.,
	UNPROCESSABLE_ENTITY (422)
Message-ID: <1339067742.9.0.619240246861.issue15025@psf.upfronthosting.co.za>


New submission from Craig Loftus <craig at wildknowledge.co.uk>:

Calling httplib.responses[httplib.UNPROCESSABLE_ENTITY] in 2.7, or http.client.responses[http.client.UNPROCESSABLE_ENTITY] raises "KeyError: 422".

The expected behaviour would be to return "Unprocessable Entity".

This is the specific issue that I have hit, but the same is true of all the WEBDAV status codes that constants are defined for.

----------
components: Library (Lib)
messages: 162470
nosy: craigloftus
priority: normal
severity: normal
status: open
title: httplib and http.client are missing response messages for defined WEBDAV responses, e.g., UNPROCESSABLE_ENTITY (422)
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Jun  7 15:56:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Jun 2012 13:56:14 +0000
Subject: [New-bugs-announce] [issue15026] Faster UTF-16 encoding
Message-ID: <1339077374.41.0.500256039615.issue15026@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

In pair to issue14624 here is a patch than speed up UTF-16 encoding in several times. In addition, it fixes an unsafe check of an integer overflow.

Here are the results of benchmarking. See benchmark tools in https://bitbucket.org/storchaka/cpython-stuff repository.

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

Py2.7        Py3.2        Py3.3        patched

457 (+575%)  458 (+573%)  1077 (+186%) 3083   encode  utf-16le  'A'*10000
457 (+579%)  493 (+529%)  1084 (+186%) 3102   encode  utf-16le  '\x80'*10000
489 (+534%)  458 (+577%)  1081 (+187%) 3102   encode  utf-16le    '\x80'+'A'*9999
457 (+1261%) 493 (+1161%) 1116 (+457%) 6219   encode  utf-16le  '\u0100'*10000
489 (+1266%) 458 (+1358%) 1126 (+493%) 6678   encode  utf-16le    '\u0100'+'A'*9999
489 (+1263%) 458 (+1355%) 1129 (+490%) 6666   encode  utf-16le    '\u0100'+'\x80'*9999
457 (+1240%) 493 (+1142%) 1118 (+448%) 6125   encode  utf-16le  '\u8000'*10000
489 (+1271%) 458 (+1363%) 1127 (+495%) 6702   encode  utf-16le    '\u8000'+'A'*9999
489 (+1271%) 458 (+1364%) 1129 (+494%) 6705   encode  utf-16le    '\u8000'+'\x80'*9999
489 (+1135%) 458 (+1218%) 1136 (+432%) 6038   encode  utf-16le    '\u8000'+'\u0100'*9999
498 (+128%)  505 (+125%)  630 (+80%)   1137   encode  utf-16le  '\U00010000'*10000
489 (+35%)   458 (+44%)   360 (+83%)   659    encode  utf-16le    '\U00010000'+'A'*9999
489 (+35%)   458 (+44%)   359 (+84%)   660    encode  utf-16le    '\U00010000'+'\x80'*9999
489 (+36%)   458 (+45%)   361 (+84%)   663    encode  utf-16le    '\U00010000'+'\u0100'*9999
489 (+36%)   458 (+45%)   361 (+84%)   663    encode  utf-16le    '\U00010000'+'\u8000'*9999

447 (+507%)  493 (+450%)  1086 (+150%) 2712   encode  utf-16be  'A'*10000
447 (+513%)  493 (+456%)  1080 (+154%) 2739   encode  utf-16be  '\x80'*10000
489 (+458%)  458 (+496%)  1079 (+153%) 2729   encode  utf-16be    '\x80'+'A'*9999
447 (+498%)  494 (+441%)  1118 (+139%) 2672   encode  utf-16be  '\u0100'*10000
489 (+464%)  458 (+502%)  1128 (+144%) 2756   encode  utf-16be    '\u0100'+'A'*9999
489 (+463%)  458 (+502%)  1131 (+144%) 2755   encode  utf-16be    '\u0100'+'\x80'*9999
447 (+500%)  493 (+444%)  1119 (+139%) 2680   encode  utf-16be  '\u8000'*10000
489 (+463%)  458 (+502%)  1126 (+145%) 2755   encode  utf-16be    '\u8000'+'A'*9999
489 (+464%)  458 (+502%)  1129 (+144%) 2757   encode  utf-16be    '\u8000'+'\x80'*9999
489 (+479%)  458 (+518%)  1137 (+149%) 2829   encode  utf-16be    '\u8000'+'\u0100'*9999
499 (+102%)  506 (+99%)   630 (+60%)   1009   encode  utf-16be  '\U00010000'*10000
489 (+6%)    458 (+13%)   360 (+44%)   519    encode  utf-16be    '\U00010000'+'A'*9999
489 (+6%)    458 (+13%)   359 (+44%)   518    encode  utf-16be    '\U00010000'+'\x80'*9999
489 (+6%)    458 (+13%)   361 (+44%)   519    encode  utf-16be    '\U00010000'+'\u0100'*9999
489 (+6%)    458 (+13%)   361 (+44%)   519    encode  utf-16be    '\U00010000'+'\u8000'*9999

----------
components: Interpreter Core, Unicode
files: encode-utf16.patch
keywords: patch
messages: 162473
nosy: Arfrever, asvetlov, ezio.melotti, haypo, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Faster UTF-16 encoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25856/encode-utf16.patch

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

From report at bugs.python.org  Thu Jun  7 15:57:31 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Jun 2012 13:57:31 +0000
Subject: [New-bugs-announce] [issue15027] Faster UTF-32 encoding
Message-ID: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

In pair to issue14625 here is a patch than speed up UTF-32 encoding in several times. In addition, it fixes an unsafe check of an integer overflow.

Here are the results of benchmarking. See benchmark tools in https://bitbucket.org/storchaka/cpython-stuff repository.

On 32-bit Linux, AMD Athlon 64 X2 4600+ @ 2.4GHz:

Py2.7        Py3.2        Py3.3        patched

541 (+1032%) 541 (+1032%) 844 (+626%)  6125   encode  utf-32le  'A'*10000
543 (+1056%) 541 (+1060%) 844 (+643%)  6275   encode  utf-32le  '\x80'*10000
544 (+1010%) 542 (+1014%) 843 (+616%)  6037   encode  utf-32le    '\x80'+'A'*9999
541 (+799%)  542 (+797%)  764 (+537%)  4864   encode  utf-32le  '\u0100'*10000
544 (+781%)  542 (+784%)  767 (+525%)  4793   encode  utf-32le    '\u0100'+'A'*9999
544 (+789%)  542 (+792%)  766 (+531%)  4834   encode  utf-32le    '\u0100'+'\x80'*9999
542 (+799%)  541 (+801%)  764 (+538%)  4874   encode  utf-32le  '\u8000'*10000
544 (+779%)  542 (+782%)  767 (+523%)  4780   encode  utf-32le    '\u8000'+'A'*9999
544 (+793%)  542 (+796%)  766 (+534%)  4859   encode  utf-32le    '\u8000'+'\x80'*9999
544 (+819%)  542 (+823%)  766 (+553%)  5001   encode  utf-32le    '\u8000'+'\u0100'*9999
430 (+867%)  427 (+874%)  860 (+383%)  4157   encode  utf-32le  '\U00010000'*10000
543 (+655%)  543 (+655%)  861 (+376%)  4101   encode  utf-32le    '\U00010000'+'A'*9999
543 (+658%)  543 (+658%)  861 (+378%)  4116   encode  utf-32le    '\U00010000'+'\x80'*9999
543 (+670%)  543 (+670%)  859 (+387%)  4180   encode  utf-32le    '\U00010000'+'\u0100'*9999
543 (+666%)  543 (+666%)  860 (+383%)  4158   encode  utf-32le    '\U00010000'+'\u8000'*9999

541 (+880%)  543 (+876%)  844 (+528%)  5300   encode  utf-32be  'A'*10000
541 (+872%)  542 (+870%)  844 (+523%)  5256   encode  utf-32be  '\x80'*10000
544 (+843%)  542 (+846%)  843 (+509%)  5130   encode  utf-32be    '\x80'+'A'*9999
541 (+363%)  542 (+362%)  764 (+228%)  2505   encode  utf-32be  '\u0100'*10000
544 (+366%)  542 (+368%)  766 (+231%)  2534   encode  utf-32be    '\u0100'+'A'*9999
544 (+363%)  542 (+365%)  766 (+229%)  2519   encode  utf-32be    '\u0100'+'\x80'*9999
542 (+363%)  541 (+364%)  764 (+228%)  2509   encode  utf-32be  '\u8000'*10000
544 (+366%)  542 (+368%)  766 (+231%)  2534   encode  utf-32be    '\u8000'+'A'*9999
544 (+363%)  542 (+364%)  766 (+229%)  2517   encode  utf-32be    '\u8000'+'\x80'*9999
544 (+372%)  542 (+374%)  766 (+235%)  2568   encode  utf-32be    '\u8000'+'\u0100'*9999
430 (+428%)  427 (+432%)  860 (+164%)  2270   encode  utf-32be  '\U00010000'*10000
543 (+317%)  541 (+318%)  861 (+163%)  2262   encode  utf-32be    '\U00010000'+'A'*9999
543 (+320%)  541 (+321%)  861 (+165%)  2279   encode  utf-32be    '\U00010000'+'\x80'*9999
543 (+322%)  541 (+323%)  859 (+167%)  2290   encode  utf-32be    '\U00010000'+'\u0100'*9999
543 (+322%)  541 (+324%)  860 (+167%)  2292   encode  utf-32be    '\U00010000'+'\u8000'*9999

----------
components: Interpreter Core, Unicode
files: encode-utf32.patch
keywords: patch
messages: 162474
nosy: Arfrever, asvetlov, ezio.melotti, haypo, pitrou, storchaka
priority: normal
severity: normal
status: open
title: Faster UTF-32 encoding
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file25857/encode-utf32.patch

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

From report at bugs.python.org  Thu Jun  7 19:13:54 2012
From: report at bugs.python.org (R.M.Bianchi)
Date: Thu, 07 Jun 2012 17:13:54 +0000
Subject: [New-bugs-announce] [issue15028] PySys_SetArgv escapes quotes in
	argv[]
Message-ID: <1339089234.78.0.185097327197.issue15028@psf.upfronthosting.co.za>


New submission from R.M.Bianchi <riccardomaria.bianchi at gmail.com>:

Embedding Python in C++ I saw that if I pass this string below to the PySys_SetArgv, as one of the command-line arguments passed to an embedded script:

"--net-label-name='("DC1","eth1")'"

PySys_Argv transforms it escaping the single quotes, and in the Python side I get this value for sys.argv[i]:

'--net-label-name=\'("DC1","eth1")\''

It does not seem a problem of converting strings or char in the C++ sides, I checked them.

The problem appears just after the PySys_Argv call.

=== cut ===
Qt-Debug: python script command-line args: ("/afs/cern.ch/work/r/rbianchi/private/tdaq_4_0_0/dbe/cmt/pm_farm.py", "--safe-hw-tags", "--add='pcatd143'", "--net-label-name='("DC1","eth1")'", "newdb.data.xml")
[...]
pyout: sys.argv:
pyout:
pyout: ['/afs/cern.ch/work/r/rbianchi/private/tdaq_4_0_0/dbe/cmt/pm_farm.py', '--safe-hw-tags', "--add='pcatd143'", '--net-label-name=\'("DC1","eth1")\'', 'newdb.data.xml']
=== cut ===

Please notice that the same script works perfectly with the same argument list in stand-alone mode (i.e. not embedded in C++).

Please also notice that in the embedded side the problem does not appear if I substitute the string passed as command line parameter from the original one:

"--net-label-name='("DC1","eth1")'"

to this one below, where I omit a level of quotes and I skip the double quotes:

"--net-label-name=('DC1','eth1')"

In this last case the embedded script also works fine in the embedded world.

It seems to me an issue in PySys_SetArgv, while parsing the strings. But maybe I'm missing something.

Best regards,

  R.M.Bianchi

----------
components: Interpreter Core
messages: 162478
nosy: RMBianchi
priority: normal
severity: normal
status: open
title: PySys_SetArgv escapes quotes in argv[]
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun  7 19:25:09 2012
From: report at bugs.python.org (Mateusz Loskot)
Date: Thu, 07 Jun 2012 17:25:09 +0000
Subject: [New-bugs-announce] [issue15029] Update Defining New Types chapter
	according to PEP 253
Message-ID: <1339089909.82.0.778815916296.issue15029@psf.upfronthosting.co.za>


New submission from Mateusz Loskot <mateusz at loskot.net>:

The chapter '2. Defining New Types" in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types.

The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual.

I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like

* Preparing a type for subtyping
* Creating a subtype of a built-in type in C

could be copied with little editing, IMHO.

The PEP 253 really seems to be a must-read document for Python C API users.

[1] http://docs.python.org/release/3.2.2/extending/newtypes.html
[2] http://www.python.org/dev/peps/pep-0253/

----------
assignee: docs at python
components: Documentation
messages: 162480
nosy: docs at python, mloskot
priority: normal
severity: normal
status: open
title: Update Defining New Types chapter according to PEP 253
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  7 20:29:05 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Thu, 07 Jun 2012 18:29:05 +0000
Subject: [New-bugs-announce] [issue15030] PyPycLoader can't read cached .pyc
	files
Message-ID: <1339093745.36.0.217954238906.issue15030@psf.upfronthosting.co.za>


New submission from Ronan Lamy <ronan.lamy at gmail.com>:

PyPycLoader can't read or write .pyc files created by the core import machinery. I'm attaching a failing test case demonstrating the issue: if you import a .py file using standard mechanisms, thus creating a .pyc, and then (in a separate process, say) attempt to make use of that cached file with PyPycLoader, the import fails with 'ValueError: bad marshal data (unknown type code)'.

It looks like that there has been a change in the binary format of .pyc files but PyPycLoader wasn't updated.

----------
components: Library (Lib)
files: test_PyPyc.diff
keywords: patch
messages: 162486
nosy: Ronan.Lamy, brett.cannon
priority: normal
severity: normal
status: open
title: PyPycLoader can't read cached .pyc files
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25859/test_PyPyc.diff

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

From report at bugs.python.org  Thu Jun  7 21:10:13 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Thu, 07 Jun 2012 19:10:13 +0000
Subject: [New-bugs-announce] [issue15031] Split .pyc parsing from module
	loading
Message-ID: <1339096213.71.0.334524050625.issue15031@psf.upfronthosting.co.za>


New submission from Ronan Lamy <ronan.lamy at gmail.com>:

I think it would be beneficial to extract the handling of the binary format of bytecode files from the rest of the loader/finder code in importlib._bootstrap. That means exposing, internally at least, functions that do nothing more than convert the binary contents of a .pyc file to/from metadata + code object. They would help in testing and implementing alternate loaders and would prevent the kind of code duplication that led to issue 15030.

I'm adding a patch implementing extracting a _loads_pyc() function from _bytes_to_bytecode(). Note that:

* _loads_pyc() has only one parameter, instead of 5 for _bytes_from_bytecode.
* The raising of exceptions is more consistent: _loads_pyc being an IO helper, it never raises ImportError. Thanks to exception chaining, no information is lost, though.

Obviously, this should be complemented with a _dumps_pyc(). Then there's the question of whether these functions should be public and what the best interface is - I actually feel that the natural home of both functions is in a lower level module, either imp or marshal.

So, should I get on with it, or are there things I overlooked that make this a bad idea?

----------
components: Interpreter Core
files: loads_pyc.diff
keywords: patch
messages: 162489
nosy: Ronan.Lamy, brett.cannon, ncoghlan
priority: normal
severity: normal
status: open
title: Split .pyc parsing from module loading
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25860/loads_pyc.diff

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

From report at bugs.python.org  Thu Jun  7 23:00:03 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 Jun 2012 21:00:03 +0000
Subject: [New-bugs-announce] [issue15032] Provide a select.select
	implemented using select.poll
Message-ID: <1339102803.48.0.0979109123526.issue15032@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

Many random bits of the standard library were originally written using select.select.  This is an ancient API that is available everywhere, but these days you'd be hard pressed to find _any_ system that does not implement the superior poll() API which does not suffer from the file descriptor limits problem of select().

A select.select() work-a-like should be possible to write that is implemented using poll.poll().

I am attaching my untested work in progress version of something like that as I don't have time to work on this further at the moment.  Someone else can pick it up if desired. (sorry about the code being in Google style rather than PEP-8)

----------
files: poll_select-gps001.txt
messages: 162498
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Provide a select.select implemented using select.poll
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25861/poll_select-gps001.txt

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

From report at bugs.python.org  Thu Jun  7 23:13:39 2012
From: report at bugs.python.org (Kamil Kisiel)
Date: Thu, 07 Jun 2012 21:13:39 +0000
Subject: [New-bugs-announce] [issue15033] Different exit status when using -m
Message-ID: <1339103619.16.0.545991410176.issue15033@psf.upfronthosting.co.za>


New submission from Kamil Kisiel <kamil at kamilkisiel.net>:

Python returns a different exit status when an exception is raised and -m is used as opposed to just running a module.

A short example, let's call it foo.py:

    def main():
        raise ValueError()

    if __name__ == '__main__':
        main()

When run with python foo.py the exit status of the process is 1. If run with python -mfoo the exit status of the process is 255.

----------
messages: 162501
nosy: kisielk
priority: normal
severity: normal
status: open
title: Different exit status when using -m
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun  8 03:22:05 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jun 2012 01:22:05 +0000
Subject: [New-bugs-announce] [issue15034] tutorial should use best practices
	in user defined	execeptions section
Message-ID: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>


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

And I wish I knew what those were.

----------
assignee: docs at python
components: Documentation
messages: 162513
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: tutorial should use best practices in user defined execeptions section
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  8 11:22:50 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Jun 2012 09:22:50 +0000
Subject: [New-bugs-announce] [issue15035] array.array of UCS2 values
Message-ID: <1339147370.98.0.5823346157.issue15035@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I'm sometimes using an array.array with format character "u" as a writable backing store for buffers shared with platform APIs that access buffers of UCS2 values. This works fine in python 3.2 and earlier with a ucs2 build of python, but no longer works with python 3.3 because the "u" character explicitly selects a UCS4 representation in that version.

An example of how I use this is using PyObjC on MacOSX, for example:

b = array.array('u', "hello world")
s = CFStringCreateMutableWithExternalCharactersNoCopy(                      
        None, b, len(b), len(b), kCFAllocatorNull)

"s" now refers to a mutable Objective-C string that uses "b" as its backing store.

It would be nice if there were a format code that would allow me to do this with Python 3.3, for example   b = array.array("U", ...)


(BTW. I'm sorry if this is a duplicate, searching for "array.array" on the tracker results in a lot of hits, most of which have nothing to do with the array module)

----------
components: Extension Modules
messages: 162520
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: array.array of UCS2 values
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  8 16:18:55 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 08 Jun 2012 14:18:55 +0000
Subject: [New-bugs-announce] [issue15036] mailbox.mbox fails to pop two
	items in a row, flushing in between
Message-ID: <1339165135.64.0.720965840978.issue15036@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

test_mbox is an mbox mailbox with a few messages in it.

>>> import mailbox
>>> inbox = mailbox.mbox('test_mbox')
>>> inbox.lock()
>>> inbox.popitem()
(0, <mailbox.mboxMessage instance at 0x7f78016bc680>)
>>> inbox.flush()
>>> inbox.unlock()
>>> inbox.lock()
>>> inbox.popitem()
(1, <mailbox.mboxMessage instance at 0x7f7801653320>)
>>> inbox.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/mailbox.py", line 633, in flush
    (self._file_length, cur_len))
mailbox.ExternalClashError: Size of mailbox file changed (expected 141289, found 141147)

----------
components: Library (Lib)
messages: 162528
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: mailbox.mbox fails to pop two items in a row, flushing in between
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  8 18:08:32 2012
From: report at bugs.python.org (John Bollinger)
Date: Fri, 08 Jun 2012 16:08:32 +0000
Subject: [New-bugs-announce] [issue15037] test_curses fails with
	OverflowError
Message-ID: <1339171712.6.0.747270716657.issue15037@psf.upfronthosting.co.za>


New submission from John Bollinger <John.Bollinger at stJude.org>:

I encountered this test failure while attempting to verify a patch for a separate issue, and I found that it occurs with the unmodified source on the default branch:

LD_LIBRARY_PATH="$PWD" ./python -bb -Wd -m test -r -w -uall -v test_curses
== CPython 3.3.0a4+ (default:4aeb5b9b62d7, Jun 8 2012, 10:23:35) [GCC 4.4.6
20110731 (Red Hat 4.4.6-3)]
==   Linux-2.6.32-220.4.1.el6.x86_64-x86_64-with-centos-6.2-Final
little-endian
==   /home/jbolling/cpython/build/test_python_26873
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=2, quiet=0, hash_randomization=1)
Using random seed 3072318
[1/1] test_curses
test test_curses crashed -- Traceback (most recent call last):
  File "/home/jbolling/cpython/Lib/test/regrtest.py", line 1237, in
runtest_inner
    test_runner()
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 338, in
test_main
    main(stdscr)
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 324, in main
    test_unget_wch(stdscr)
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 283, in
test_unget_wch
    read = chr(read)
OverflowError: signed integer is greater than maximum

1 test failed:
    test_curses
Re-running failed tests in verbose mode
Re-running test 'test_curses' in verbose mode
test test_curses crashed -- Traceback (most recent call last):
  File "/home/jbolling/cpython/Lib/test/regrtest.py", line 1237, in
runtest_inner
    test_runner()
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 338, in
test_main
    main(stdscr)
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 324, in main
    test_unget_wch(stdscr)
  File "/home/jbolling/cpython/Lib/test/test_curses.py", line 283, in
test_unget_wch
    read = chr(read)
OverflowError: signed integer is greater than maximum

[123272 refs]


Python was built and the tests run on CentOS 6.2 / x86_64, using the platform's standard tool chain, configured with "--enable-shared --with-threads --with-pydebug".

All other tests pass for me, although test_builtin failed when run as part of the whole suite but passed when run by itself.


For what it's worth, it looks like that particular message is emitted in exactly one place: Python/getargs.c:661 (function convertsimple()), which in this case I guess is being called indirectly from Python/bltinmodule.c:526 (function builtin_chr()).  It's not obvious to me why that would be failing.

----------
components: Tests
messages: 162532
nosy: jcbollinger
priority: normal
severity: normal
status: open
title: test_curses fails with OverflowError
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun  8 20:31:41 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 08 Jun 2012 18:31:41 +0000
Subject: [New-bugs-announce] [issue15038] Optimize python Locks on Windows
Message-ID: <1339180301.31.0.978544490833.issue15038@psf.upfronthosting.co.za>


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

The attached patch does three things:

"
- Abstract the condition variable used by ceval_gil.h into a separate file,
condvar.h.  It now defines a PyMUTEX_T, PyCOND_T and associated functions.
This file can be used by different parts of the python core.
- Implement locking on windows using custom structures based on condition
variables, rather than using a semaphore kernel object.  This avoids kernel
transitions for uncontensted locks and provides a large speedup for windows.
- Add a condition variable implementation using native primitives for builds
targeted for Vista.  Experimental and disabled by default.
"

Using this locking mechanism on windows results in a 60% speedup of using uncontested locks, due to the removal of the necessary kernel transition that is required by regular semaphore objects.

Before:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l
.release()"
1000000 loops, best of 3: 0.731 usec per loop

After:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l
.release()"
1000000 loops, best of 3: 0.27 usec per loop

----------
components: Interpreter Core, Windows
files: 77369.patch
keywords: patch
messages: 162545
nosy: kristjan.jonsson, loewis, pitrou
priority: normal
severity: normal
status: open
title: Optimize python Locks on Windows
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25867/77369.patch

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

From report at bugs.python.org  Sat Jun  9 01:59:03 2012
From: report at bugs.python.org (Dan Stromberg)
Date: Fri, 08 Jun 2012 23:59:03 +0000
Subject: [New-bugs-announce] [issue15039] module/ found before module.py
	when both are in the CWD
Message-ID: <1339199943.51.0.731148494988.issue15039@psf.upfronthosting.co.za>


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

CPython 3.3a4 appears to find treap/ before treap.py in the CWD.  If I rename treap to treap-dir, all seems well for the code in question:

dstromberg at zareason-limbo6000a /tmp/tt $ mv treap treap-dir

dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python -c 'import sys; print(sys.path); import treap; t = treap.treap()'
['', '/usr/local/cpython-3.3/lib/python33.zip', '/usr/local/cpython-3.3/lib/python3.3', '/usr/local/cpython-3.3/lib/python3.3/plat-linux', '/usr/local/cpython-3.3/lib/python3.3/lib-dynload', '/usr/local/cpython-3.3/lib/python3.3/site-packages']

dstromberg at zareason-limbo6000a /tmp/tt $ mv treap-dir/ treap

dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python -c 'import sys; print(sys.path); import treap; t = treap.treap()'
['', '/usr/local/cpython-3.3/lib/python33.zip', '/usr/local/cpython-3.3/lib/python3.3', '/usr/local/cpython-3.3/lib/python3.3/plat-linux', '/usr/local/cpython-3.3/lib/python3.3/lib-dynload', '/usr/local/cpython-3.3/lib/python3.3/site-packages']
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'treap'

dstromberg at zareason-limbo6000a /tmp/tt $ ls -l treap/__init__.py
ls: cannot access treap/__init__.py: No such file or directory

dstromberg at zareason-limbo6000a /tmp/tt $ /usr/local/cpython-3.3/bin/python
Python 3.3.0a4 (default, Jun  8 2012, 14:14:41)
[GCC 4.6.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
dstromberg at zareason-limbo6000a /tmp/tt $

----------
components: Library (Lib)
messages: 162552
nosy: strombrg
priority: normal
severity: normal
status: open
title: module/ found before module.py when both are in the CWD
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun  9 21:26:20 2012
From: report at bugs.python.org (mattip)
Date: Sat, 09 Jun 2012 19:26:20 +0000
Subject: [New-bugs-announce] [issue15040] stdlib compatability with pypy:
	mailbox.py
Message-ID: <1339269980.73.0.83333668475.issue15040@psf.upfronthosting.co.za>


New submission from mattip <matti.picus at gmail.com>:

These are changes necessary to mailbox.py and its tests so that tests pass (windows platform) on pypy 1.9.0. Files must be explicitly closed on pypy. 

I would like to submit these as a "compatability" issue type, but that category does not exist, so I used "behavior". 

This is the first in a series of a number of such patches, I think there will be about 20.

----------
components: Library (Lib)
files: mailbox.patch
keywords: patch
messages: 162564
nosy: mattip
priority: normal
severity: normal
status: open
title: stdlib compatability with pypy: mailbox.py
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25869/mailbox.patch

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

From report at bugs.python.org  Sun Jun 10 02:49:33 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sun, 10 Jun 2012 00:49:33 +0000
Subject: [New-bugs-announce] [issue15041] tkinter "see also" list is from
	Python2
Message-ID: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>


New submission from Daniel Swanson <popcorn.tomato.dude at gmail.com>:

I was looking for information about menus in tkinter and checked the "see also" list. The second is copyrighted 1999, the third says Python 2.5 and the first is pretty much just links to the second and third. The forth is a book. It is my opinion that these resources should be updated.

----------
assignee: docs at python
components: Documentation
messages: 162568
nosy: docs at python, weirdink13
priority: normal
severity: normal
status: open
title: tkinter "see also" list is from Python2
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 10 11:30:22 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 10 Jun 2012 09:30:22 +0000
Subject: [New-bugs-announce] [issue15042] Implemented PyState_AddModule,
	PyState_RemoveModule
Message-ID: <1339320622.0.0.56459406352.issue15042@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

PEP 3121 suggests a new way of Module-initialization, where the module state is being wrapped inside a dedicate struct, which can be accessed at runtime via the PyState_FindModule method. For code outside the Init-method, there is no other way to receive the module-state, as it has no reference to the object created by PyModule_Create.
PyState_FindModule requires, that the module-state has been attached to the interpreter-state beforehand. Inside an extension module code this is almost everywhere the case except inside the Init-method, because currently _PyState_AddModule is only called by the importer AFTER the extension module has been initialized successfully. As most of the macro definitions inside an extension module, which rely on data stored in the module state, have to receive the state via FindModule, they fail to work inside the modules Init-method.

This patch suggests an extension of PyState comprising two publicly available methods (PyState_AddModule, PyState_RemoveModule) that can be called from inside the Init-method, so that the module-state is attached to the interpreter state before further initialization of the module continues. As a result, PyState_FindModule will also work in this region of the extension module and the bespoken expanded macros will also work flawlessly when executed inside the Init code.

This patch is especially important for the future application of PEP 3121 together with PEP 384, as the newly created heap-types now reside inside the module-state. As type-objects are frequently used in macro-definitions which are also expanded within the Init-method of a module (or inside a function called from Init), the module state has to be received via FindModule. (The alternative would be nasty redefinitions of the specific macros, shortly before Init)

----------
components: Interpreter Core
files: PyState_add-remove_module.patch
keywords: patch
messages: 162581
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: Implemented PyState_AddModule, PyState_RemoveModule
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25871/PyState_add-remove_module.patch

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

From report at bugs.python.org  Mon Jun 11 14:48:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Jun 2012 12:48:40 +0000
Subject: [New-bugs-announce] [issue15043] test_gdb is disallowed by default
	security settings in	Fedora 17
Message-ID: <1339418920.32.0.804230672204.issue15043@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Running test_gdb on Fedora 17 produces a litany of the following error:

- warning: File "/home/ncoghlan/devel/py3k/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "/usr/share/gdb/auto-load:/usr/lib/debug:/usr/bin/mono-gdb.py".

Presumably some security features in gdb have either been added, or enabled by default, with the F17 update.

The devguide needs to be updated with a reference to the relevant gdb security settings so contributors can get it running again.

----------
components: Devguide
messages: 162610
nosy: dmalcolm, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: test_gdb is disallowed by default security settings in Fedora 17
type: enhancement

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

From report at bugs.python.org  Mon Jun 11 14:54:36 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Jun 2012 12:54:36 +0000
Subject: [New-bugs-announce] [issue15044] _dbm not building on Fedora 17
Message-ID: <1339419276.14.0.776380081332.issue15044@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

After upgrading from Fedora 16 -> 17, my previously working trunk build is getting the following error:

Building '_dbm' extension
gcc -pthread -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -DHAVE_NDBM_H -IInclude -I. -I./Include -I/usr/local/include -I/home/ncoghlan/devel/py3k -c /home/ncoghlan/devel/py3k/Modules/_dbmmodule.c -o build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o
gcc -pthread -shared build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o -L/usr/local/lib -o build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so
*** WARNING: renaming "_dbm" since importing it failed: build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so: undefined symbol: dbm_nextkey

Failed to build these modules:
_dbm

----------
components: Extension Modules
messages: 162612
nosy: dmalcolm, ncoghlan
priority: normal
severity: normal
status: open
title: _dbm not building on Fedora 17
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 11 15:29:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Jun 2012 13:29:18 +0000
Subject: [New-bugs-announce] [issue15045] Make textwrap.dedent() consistent
	with	str.splitlines(True) and str.strip()
Message-ID: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

In working on #13857, I noticed that the current regex based implementation of textwrap.dedent() is limited specifically to ASCII whitespace (tabs and spaces) with Unix line endings (a line containing solely a Windows "\r\n" line ending will be deemed to contain a non-whitespace character, since "\r" isn't recognised by the regex)

The new textwrap.indent() function added in #13857 takes a much simpler approach to whitespace handling: its definition of a "line" is exactly that of "text.splitlines(True)", while its definition of a line that does not consist solely of whitespace is "bool(line.strip())"

As a simple example of how that can make a difference, consider:

>>> "\N{NO-BREAK SPACE}".strip()
''

One way to remedy this would be to replace the regex based implementation of textwrap.dedent with a simpler one written in terms of text.splitlines(True) and line.strip().

----------
components: Library (Lib)
messages: 162617
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make textwrap.dedent() consistent with str.splitlines(True) and str.strip()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 11 16:46:11 2012
From: report at bugs.python.org (Marco den Otter)
Date: Mon, 11 Jun 2012 14:46:11 +0000
Subject: [New-bugs-announce] [issue15046] Missing cast to Py_ssize_t in
	socket_connection.c
Message-ID: <1339425971.4.0.190872780402.issue15046@psf.upfronthosting.co.za>


New submission from Marco den Otter <marco.den.otter at nspyre.nl>:

In the file socket_connection.c on line 139 a cast to Py_ssize_t is missing for the return value.

Is:
  return res < 0 ? res : ulength;
Should be
  return res < 0 ? (Py_ssize_t)res : (Py_ssize_t)ulength;

Now it can be possible that a close of the socket is not detected.

Found the bug by creating a server client that only sends the length of a data package and then closing the socket. 

Without the cast the calling function (connection_recvbytes in connection.h) will try to return an object because of not detecting the result was smaller then 0.

----------
components: Library (Lib)
messages: 162620
nosy: MOtter
priority: normal
severity: normal
status: open
title: Missing cast to Py_ssize_t in socket_connection.c
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 11 20:21:46 2012
From: report at bugs.python.org (Jason Tishler)
Date: Mon, 11 Jun 2012 18:21:46 +0000
Subject: [New-bugs-announce] [issue15047] Cygwin install (regen) problem
Message-ID: <1339438906.76.0.557865099456.issue15047@psf.upfronthosting.co.za>


New submission from Jason Tishler <jason at tishler.net>:

The Cygwin build is failing during make install -- specifically, during the regen step:

[snip]
mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin
cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin;  ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named encodings
./regen: line 3:  2976 Aborted                 (core dumped) python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
[snip]

Note that I seem to be running into the same or similar problem as the following:

http://bugs.python.org/issue3626#msg72415

I was able to workaround the core dump problem with the following patch:

diff -u Python-2.6.5.orig/Makefile.pre.in Python-2.6.5/Makefile.pre.in
--- Python-2.6.5.orig/Makefile.pre.in   2009-12-24 09:19:38.000000000 -0500
+++ Python-2.6.5/Makefile.pre.in    2010-04-13 17:05:04.368555900 -0400
@@ -910,7 +910,7 @@
    mkdir $(srcdir)/Lib/$(PLATDIR)
    cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen
    export PATH; PATH="`pwd`:$$PATH"; \
-   export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
+   export PYTHONPATH; PYTHONPATH="$(srcdir)/Lib"; \
    export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
    export EXE; EXE="$(BUILDEXE)"; \
    cd $(srcdir)/Lib/$(PLATDIR); $(RUNSHARED) ./regen

Note that I'm building outside of the source tree, so when the original version sets PYTHONPATH to the following:

"`pwd`/Lib"

it was guaranteed to point to a nonexistent directory.

Unfortunately, now the build fails as follows:

[snip]
mkdir /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin
cp /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd /home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin;  ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
  File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py", line 334, in _init_posix
    _parse_makefile(makefile, vars)
  File "/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: '/usr/lib/python3.2/config-3.2m/Makefile'
[snip]

AFAICT, the problem is when regen runs, python thinks it is running out of an installation directory and not a build directory.

Does anyone know how to convince python to think it is running out its build directory even though it is being found in the PATH.  If not, does anyone have any other suggestions on how to resolve this problem?

----------
components: Build
messages: 162634
nosy: jlt63, yselkowitz
priority: normal
severity: normal
status: open
title: Cygwin install (regen) problem
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun 12 01:23:02 2012
From: report at bugs.python.org (James Kyle)
Date: Mon, 11 Jun 2012 23:23:02 +0000
Subject: [New-bugs-announce] [issue15048] Manually Installed Python Includes
	System Wide Paths
Message-ID: <1339456982.84.0.0507293690516.issue15048@psf.upfronthosting.co.za>


New submission from James Kyle <bugs at jameskyle.org>:

This behavior is present on OS X 10.7 and framework builds.

In this case, the /Library/Python/<version> paths are included in every install. 

I would consider this behavior non-standard as in most manual python installs only that installations library paths are included.

This can lead to surprising and inconsistent behavior if multiple installs are present (very common on osx, e.g. macports + system install).

This originated as a macports bug ticket: https://trac.macports.org/ticket/34763

----------
assignee: ronaldoussoren
components: Macintosh
messages: 162648
nosy: James.Kyle, ronaldoussoren
priority: normal
severity: normal
status: open
title: Manually Installed Python Includes System Wide Paths
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 12 03:15:24 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jun 2012 01:15:24 +0000
Subject: [New-bugs-announce] [issue15049] line buffering isn't always
Message-ID: <1339463724.73.0.621165878269.issue15049@psf.upfronthosting.co.za>


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

rdmurray at hey:~/python/p32>cat bad.py

    This line is just ascii
    A second line for good measure.
    This comment contains undecodable stuff: "?" or "\\xe9" in "pass?"" cannot be decoded.

The last line above is in latin-1, with an ? inside those quotes.

    rdmurray at hey:~/python/p32>cat bug.py      
    import sys
    with open('./bad.py', buffering=int(sys.argv[1])) as f:
        for line in f:
            print(line, end='')
    rdmurray at hey:~/python/p32>python3 bug.py -1
    Traceback (most recent call last):
      File "bug.py", line 3, in <module>
        for line in f:
      File "/usr/lib/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99: invalid continuation byte
    rdmurray at hey:~/python/p32>python3 bug.py 1 
    Traceback (most recent call last):
      File "bug.py", line 3, in <module>
        for line in f:
      File "/usr/lib/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99:
    invalid continuation byte
    rdmurray at hey:~/python/p32>python3 bug.py 2
    This line is just ascii
    A second line for good measure.
    Traceback (most recent call last):
      File "bug.py", line 3, in <module>
        for line in f:
      File "/usr/lib/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 0: invalid
    continuation byte

So, line buffering does not appear to buffer line by line.

I ran into this problem because I had a much larger file that I thought
was in utf-8.  When I got the encoding error, I was annoyed that the
error message didn't really tell me which line the error was on, but I
figured, OK, I'll just set line buffering and then I'll be able to tell.
But that didn't work.  Fortunately using '2' did work....but at a minimum
the docs need to be updated to indicate when line buffering really is
line buffering and when it isn't.

----------
messages: 162656
nosy: pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: line buffering isn't always
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 12 10:01:43 2012
From: report at bugs.python.org (Grey_Shao)
Date: Tue, 12 Jun 2012 08:01:43 +0000
Subject: [New-bugs-announce] [issue15050] Python 3.2.3 fail to make
Message-ID: <1339488103.99.0.17701742584.issue15050@psf.upfronthosting.co.za>


New submission from Grey_Shao <shojnhv at 163.com>:

When I try to compile the Python 3.2.3, I failed to make
After I ungzip and untar the source package of the Python 3.2.3, Then run the following commands:
    1. ./configure
    2. make
When step 2, the errors below happens:
gcc -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Mod
ules/python.o ./Modules/python.c
In file included from Include/Python.h:50,
                 from ./Modules/python.c:3:
Include/pyport.h:260:13: #error "This platform's pyconfig.h needs to define PY_FORMAT_LONG_LONG"
*** Error code 1
make: Fatal error: Command failed for target `Modules/python.o'

Can you help me

My system OS is:
uname -a
SunOS HPCT01 5.9 Generic_117171-02 sun4u sparc SUNW,Sun-Fire-280R

I attached install history file

Thanks

----------
components: None
files: Python3.2.3_Install_History_20120612.txt
messages: 162662
nosy: shojnhv
priority: normal
severity: normal
status: open
title: Python 3.2.3 fail to make
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file25941/Python3.2.3_Install_History_20120612.txt

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

From report at bugs.python.org  Tue Jun 12 17:40:08 2012
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 12 Jun 2012 15:40:08 +0000
Subject: [New-bugs-announce] [issue15051] Can't compile Python 3.3a4 on OS X
Message-ID: <1339515608.84.0.525003412108.issue15051@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

I try to compile Pyhton 3.3a4 on a OS X 10.7 with XCode 4.3.3 and it fails. I tried a few configuration options, but even with a basic "./configure && make", I get this:

./python.exe -SE -m sysconfig --generate-posix-vars
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
python.exe(11771) malloc: *** mmap(size=7310873954244194304) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Could not import runpy module
make: *** [Lib/_sysconfigdata.py] Segmentation fault: 11

I tried setting PYTHONHOME to `pwd`, to no avail. Am I doing something wrong? The same thing happens with v3.3a3. If I go back to v3.2.3, it compiles fine on the same system. I also tried on the repo's tip, same error.

----------
components: Build
messages: 162683
nosy: vdupras
priority: normal
severity: normal
status: open
title: Can't compile Python 3.3a4 on OS X
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 12 19:17:05 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 12 Jun 2012 17:17:05 +0000
Subject: [New-bugs-announce] [issue15052] Outdated comments in build_ssl.py
Message-ID: <1339521425.84.0.884791308596.issue15052@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

The comment regarding a Perl installation not being required is no longer true with regards to OpenSSL 1.0+ (at least 1.0.0j and 1.0.1c).  A Perl script(s) is used to generate source files within the generated Makefiles.

I would suggest to remove the outdated and misleading comment.

----------
components: Build
messages: 162687
nosy: jkloth
priority: normal
severity: normal
status: open
title: Outdated comments in build_ssl.py
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun 12 22:20:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Jun 2012 20:20:46 +0000
Subject: [New-bugs-announce] [issue15053] imp.lock_held() "Changed in Python
	3.3" mention	accidentally one function up
Message-ID: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at http://docs.python.org/dev/py3k/library/imp.html#imp.get_tag you will notice it has the "Changed in Python 3.3" notice for imp.lock_held() in it, the function *below* imp.get_tag().

----------
assignee: docs at python
components: Documentation
messages: 162694
nosy: brett.cannon, docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: imp.lock_held() "Changed in Python 3.3" mention accidentally one function up
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 13 14:47:54 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 13 Jun 2012 12:47:54 +0000
Subject: [New-bugs-announce] [issue15054] bytes literals erroneously
	tokenized
Message-ID: <1339591674.58.0.511161996211.issue15054@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

With Python 2.7, both b'hello' and br'hello' are wrong.
With Python 3.3, b'hello' is wrong.



$ python2.7 -m tokenize <<<"'hello', u'hello', ur'hello', b'hello', br'hello'"
1,0-1,7:	STRING	"'hello'"
1,7-1,8:	OP	','
1,9-1,17:	STRING	"u'hello'"
1,17-1,18:	OP	','
1,19-1,28:	STRING	"ur'hello'"
1,28-1,29:	OP	','
1,30-1,31:	NAME	'b'
1,31-1,38:	STRING	"'hello'"
1,38-1,39:	OP	','
1,40-1,42:	NAME	'br'
1,42-1,49:	STRING	"'hello'"
1,49-1,50:	NEWLINE	'\n'
2,0-2,0:	ENDMARKER	''

$ python3.3 -m tokenize <<<"'hello', u'hello', ur'hello', b'hello', br'hello', rb'hello'"
1,0-1,7:            STRING         "'hello'"      
1,7-1,8:            OP             ','            
1,9-1,17:           STRING         "u'hello'"     
1,17-1,18:          OP             ','            
1,19-1,28:          STRING         "ur'hello'"    
1,28-1,29:          OP             ','            
1,30-1,31:          NAME           'b'            
1,31-1,38:          STRING         "'hello'"      
1,38-1,39:          OP             ','            
1,40-1,49:          STRING         "br'hello'"    
1,49-1,50:          OP             ','            
1,51-1,60:          STRING         "rb'hello'"    
1,60-1,61:          NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''

----------
components: Library (Lib)
messages: 162705
nosy: flox
priority: normal
severity: normal
status: open
title: bytes literals erroneously tokenized
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 13 17:34:14 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 13 Jun 2012 15:34:14 +0000
Subject: [New-bugs-announce] [issue15055] dictnotes.txt is out of date
Message-ID: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

dictnotes.txt is out of date w.r.t. dictobject.c

Remove notes from dictnotes.txt that duplicate comments in dictobject.c
and ensure comments in dictobject.c cover all aspects of tunable parameters.

Patch attached.

----------
assignee: docs at python
components: Documentation
files: dictnotes.patch
keywords: patch
messages: 162709
nosy: Mark.Shannon, docs at python
priority: normal
severity: normal
status: open
title: dictnotes.txt is out of date
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25947/dictnotes.patch

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

From report at bugs.python.org  Wed Jun 13 19:10:52 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Jun 2012 17:10:52 +0000
Subject: [New-bugs-announce] [issue15056] Have imp.cache_from_source() raise
	NotImplementedError	when cache tag not available
Message-ID: <1339607452.3.0.633183856725.issue15056@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Both imp.cache_from_source() and source_from_cache() should throw NotImplementedError when sys.implementation.cache_tag is None. See the thread starting at http://mail.python.org/pipermail/python-dev/2012-June/120145.html for discussion of this decision.

----------
components: Library (Lib)
keywords: easy
messages: 162712
nosy: brett.cannon
priority: deferred blocker
severity: normal
status: open
title: Have imp.cache_from_source() raise NotImplementedError when cache tag not available
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 13 19:42:39 2012
From: report at bugs.python.org (Ken Cheung)
Date: Wed, 13 Jun 2012 17:42:39 +0000
Subject: [New-bugs-announce] [issue15057] Potential Bugs in mpd_qdivint and
	mpd_qrem
Message-ID: <1339609359.6.0.237192650193.issue15057@psf.upfronthosting.co.za>


New submission from Ken Cheung <msrbugzilla at gmail.com>:

I observed a code clone from the following files.

function : mpd_qdivint @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 3727)~3763
function : mpd_qrem @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 6331)~6361

The function mpd_qdivint checks the condition "mpd_isinfinite(a) && mpd_isinfinite(b)" while mpd_qrem does not. I wonder if this is necessary in mpd_qrem. The source code is included in the attachment. Hope it helps.

----------
components: Library (Lib)
files: mpdecimal_clone.txt
messages: 162717
nosy: Ken.Cheung
priority: normal
severity: normal
status: open
title: Potential Bugs in mpd_qdivint and mpd_qrem
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25949/mpdecimal_clone.txt

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

From report at bugs.python.org  Wed Jun 13 19:46:47 2012
From: report at bugs.python.org (Ken Cheung)
Date: Wed, 13 Jun 2012 17:46:47 +0000
Subject: [New-bugs-announce] [issue15058] Potential Bugs in dlpvalloc and
	dlvalloc
Message-ID: <1339609607.12.0.430213667453.issue15058@psf.upfronthosting.co.za>


New submission from Ken Cheung <msrbugzilla at gmail.com>:

I observed a code clone from the following files.

function : dlpvalloc @ (file: "Python-3.3.0a2/Modules/_ctypes/libffi/src/dlmalloc.c", line: 4360)~4362
function : dlvalloc @ (file: "Python-3.3.0a2/Modules/_ctypes/libffi/src/dlmalloc.c", line: 4353)~4355

The function dlpvalloc performs a bitwise operation at return while dlvalloc does not. I wonder if this is necessary in dlvalloc. The source code is included in the attachment. Hope it helps.

----------
components: Library (Lib)
files: dlmalloc_clone.txt
messages: 162718
nosy: Ken.Cheung
priority: normal
severity: normal
status: open
title: Potential Bugs in dlpvalloc and dlvalloc
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25950/dlmalloc_clone.txt

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

From report at bugs.python.org  Wed Jun 13 19:52:37 2012
From: report at bugs.python.org (Ken Cheung)
Date: Wed, 13 Jun 2012 17:52:37 +0000
Subject: [New-bugs-announce] [issue15059] Potential Bug in mpd_qresize and
	mpd_qresize_zero
Message-ID: <1339609957.89.0.517286245492.issue15059@psf.upfronthosting.co.za>


New submission from Ken Cheung <msrbugzilla at gmail.com>:

I observed a code clone from the following files.

function : mpd_qresize @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 481)~493
function : mpd_qresize_zero @ (file: "Python-3.3.0a2/Modules/_decimal/libmpdec/mpdecimal.c", line: 501)~517

The two functions perform different in the else if condition. I wonder this is due to functionality requirement or a bug. The source code is included in the attachment. Hope it helps.

----------
components: Library (Lib)
files: mpdecimal_clone 2.txt
messages: 162719
nosy: Ken.Cheung
priority: normal
severity: normal
status: open
title: Potential Bug in mpd_qresize and mpd_qresize_zero
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25951/mpdecimal_clone 2.txt

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

From report at bugs.python.org  Wed Jun 13 20:28:01 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Jun 2012 18:28:01 +0000
Subject: [New-bugs-announce] [issue15060] docs: socket typo
Message-ID: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

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

s/integral/integer/

----------
assignee: docs at python
components: Documentation
messages: 162720
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: socket typo

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

From report at bugs.python.org  Thu Jun 14 01:00:24 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Jun 2012 23:00:24 +0000
Subject: [New-bugs-announce] [issue15061] hmac.secure_compare() leaks
	information of length of	strings
Message-ID: <1339628424.5.0.00054113371222.issue15061@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The secure_compare() function immediately returns False when both strings don't have equal length. With the patch the run time of secure_compare() always depends on the length of the right side. It no longer gives away information about the length of the left side.

The patch should be applied in combination with the patch in issue #14955.

----------
components: IO
files: secure_compare_length.patch
keywords: needs review, patch
messages: 162739
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: hmac.secure_compare() leaks information of  length of strings
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26003/secure_compare_length.patch

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

From report at bugs.python.org  Thu Jun 14 01:15:46 2012
From: report at bugs.python.org (wrobell)
Date: Wed, 13 Jun 2012 23:15:46 +0000
Subject: [New-bugs-announce] [issue15062] argparse: option for a positional
	argument
Message-ID: <1339629346.54.0.223771927159.issue15062@psf.upfronthosting.co.za>


New submission from wrobell <wrobell at pld-linux.org>:

it would be great if argparse allowed to specify options for multiple positional arguments, i.e.

  usage: ascript [-h] [-k value] input [[-k value] input ...] output

then

$ ascript pos1 pos2 -k 1 pos3 -k 2 pos4 pos5 pos6 out

would give      

Namespace(input=[(None, 'pos1'), (None, 'pos2'), ('1', 'pos3'), ('2', 'pos4'), (None, 'pos5'), ('None', 'pos6')], output=['out'])

----------
components: Library (Lib)
messages: 162741
nosy: wrobell
priority: normal
severity: normal
status: open
title: argparse: option for a positional argument
type: enhancement

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

From report at bugs.python.org  Thu Jun 14 06:30:55 2012
From: report at bugs.python.org (Bryce Verdier)
Date: Thu, 14 Jun 2012 04:30:55 +0000
Subject: [New-bugs-announce] [issue15063] Source code links for JSON
	documentation
Message-ID: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>


New submission from Bryce Verdier <bryceverdier at gmail.com>:

In some parts of the documentation there are links to the source code. While looking in the JSON documentation that link isn't there.

Not sure if this is wanted or if it's complete. But I'm submitting it anyway in the hopes of feedback.

----------
assignee: docs at python
components: Documentation
files: json_source_link.patch
keywords: patch
messages: 162750
nosy: docs at python, louiscipher
priority: normal
severity: normal
status: open
title: Source code links for JSON documentation
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26006/json_source_link.patch

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

From report at bugs.python.org  Thu Jun 14 14:13:45 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 14 Jun 2012 12:13:45 +0000
Subject: [New-bugs-announce] [issue15064] multiprocessing should use more
	context manager
Message-ID: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

There are some types which should support the context manager protocol:

- connection objects
- listener objects
- pool objects

----------
messages: 162776
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing should use more context manager
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 14 14:48:01 2012
From: report at bugs.python.org (Kevin)
Date: Thu, 14 Jun 2012 12:48:01 +0000
Subject: [New-bugs-announce] [issue15065] strftime format string %F %T
	consistency problem
Message-ID: <1339678081.17.0.304576211597.issue15065@psf.upfronthosting.co.za>


New submission from Kevin <kevin.fairbanks at gatech.edu>:

When using %F and %T in strftime on Mac and Linux the function works as expected, but it fails on Windows.  Although these format strings are not in the Python documentation, the inconsistent behavior should be noted or corrected.  If possible, the %F and %T could be expanded in some way on Windows systems or cause a format string error on POSIX systems so that the function behaves the same way across platforms.

----------
messages: 162779
nosy: kfairbanks
priority: normal
severity: normal
status: open
title: strftime format string %F %T consistency problem
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 14 16:36:22 2012
From: report at bugs.python.org (suzhengchun)
Date: Thu, 14 Jun 2012 14:36:22 +0000
Subject: [New-bugs-announce] [issue15066] make install error: ImportError:
	No module named _struct
Message-ID: <1339684582.74.0.731857257466.issue15066@psf.upfronthosting.co.za>


New submission from suzhengchun <suzhengchun at yahoo.com.cn>:

if test -d /WORK/suzc/installed/python/lib/python2.7/distutils/tests; then \
        /usr/bin/install -c -m 644 ./Modules/xxmodule.c \
                /WORK/suzc/installed/python/lib/python2.7/distutils/tests ; \
fi
PYTHONPATH=/WORK/suzc/installed/python/lib/python2.7   \
        ./python -Wi -tt /WORK/suzc/installed/python/lib/python2.7/compileall.py \
        -d /WORK/suzc/installed/python/lib/python2.7 -f \
        -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
        /WORK/suzc/installed/python/lib/python2.7
Traceback (most recent call last):
  File "/WORK/suzc/installed/python/lib/python2.7/compileall.py", line 16, in <module>
    import struct
  File "/WORK/suzc/installed/python/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] ?? 1            


In directory /WORK/suzc/software/Python-2.7.3, I do this:
suzc at linux-opensuse:22:33:28:Python-2.7.3$ ./configure --prefix=/WORK/suzc/installed/python --exec-prefix=/WORK/suzc/installed/python --mandir=/WORK/suzc/installed/man | tee -a config_make.20120614.log
make 
make install

and then meets the install error!!

python's version is 2.7.3, i download the .tgz & .bz2, both the some problem.


My system is:
suzc at linux-opensuse:22:33:28:Python-2.7.3$ uname -a
Linux linux-opensuse 3.1.0-rc7-3-desktop #1 SMP PREEMPT Wed Sep 28 14:41:36 UTC 2011 (50fb02f) x86_64 x86_64 x86_64 GNU/Linux
suzc at linux-opensuse:22:35:22:Python-2.7.3$ lsb_release -a
LSB Version:    n/a
Distributor ID: SUSE LINUX
Description:    openSUSE 12.1 Beta 1 (x86_64)
Release:        12.1
Codename:       Asparagus


any help? Thank you very much.

----------
components: Installation
messages: 162794
nosy: suzhengchun
priority: normal
severity: normal
status: open
title: make install error: ImportError: No module named _struct
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 14 17:19:08 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Jun 2012 15:19:08 +0000
Subject: [New-bugs-announce] [issue15067] sqlite3 docs reference PEP 246,
	which was rejected
Message-ID: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

See: http://hg.python.org/cpython/file/d31e83497c5a/Doc/library/sqlite3.rst#l708

PEP 246 is headed by: 
"""
Rejection Notice

    I'm rejecting this PEP.  Something much better is about to happen;
    it's too early to say exactly what, but it's not going to resemble
    the proposal in this PEP too closely so it's better to start a new
    PEP.  GvR.
"""

I don't know what the "something much better" was/is, so I have no idea how that line in the docs should be replaced, but I don't think the PEP 246 reference is valid.

Thanks,

Zach

----------
assignee: docs at python
components: Documentation
messages: 162797
nosy: docs at python, ghaering, zach.ware
priority: normal
severity: normal
status: open
title: sqlite3 docs reference PEP 246, which was rejected
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 14 17:19:34 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 14 Jun 2012 15:19:34 +0000
Subject: [New-bugs-announce] [issue15068] fileinput requires two EOF when
	reading stdin
Message-ID: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I found that fileinput.input() requires two EOF characters to stop reading input on Python 2.7.3 on Windows and Ubuntu:

PS C:\Users\jaraco> python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
>>> import fileinput
>>> lines = list(fileinput.input())
foo
bar
^Z
^Z
>>> lines
['foo\n', 'bar\n']

I don't see anything in the documentation that suggests that two EOF characters would be required, and I can't think of any reason why that should be the case.

----------
components: Library (Lib)
messages: 162798
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: fileinput requires two EOF when reading stdin
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 14 18:41:06 2012
From: report at bugs.python.org (Pat)
Date: Thu, 14 Jun 2012 16:41:06 +0000
Subject: [New-bugs-announce] [issue15069] Dictionary Creation Fails with
	integer key
Message-ID: <1339692066.88.0.713985325998.issue15069@psf.upfronthosting.co.za>


New submission from Pat <pata at jegcpa.com>:

Attempting to import pyserial. In module serialposix.py a dict declaration starting on line 64;

    baudrate_constants = {
        0:       0000000,
        50:      0000001,
        75:      0000002,
       110:      0000003, ...etc
 



Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "serialposix.py", line 64
    50:      0000001,
                   ^
SyntaxError: invalid token


MacOSX 10.6.8 32bit x86 python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012, 11:09:56)

----------
assignee: ronaldoussoren
components: Macintosh
files: serialposix.py
messages: 162805
nosy: pata at jegcpa.com, ronaldoussoren
priority: normal
severity: normal
status: open
title: Dictionary Creation Fails with integer key
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file26007/serialposix.py

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

From report at bugs.python.org  Thu Jun 14 21:33:50 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jun 2012 19:33:50 +0000
Subject: [New-bugs-announce] [issue15070] AMD64 debug VS9.0 build doesn't
	work
Message-ID: <1339702430.89.0.525587619926.issue15070@psf.upfronthosting.co.za>


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

When I try to launch the AMD64 debug build:

Z:\default>PC\VS9.0\amd64\python_d.exe

I get an error box complaining that "python33_d.dll" is missing from my system.

Indeed it doesn't seem there:

Z:\default>dir PC\VS9.0\amd64\*.dll
 Volume in drive Z is VBOX_cpython
 Volume Serial Number is 0000-0805

 Directory of Z:\default\PC\VS9.0\amd64

05/16/2012  02:09 PM         3,176,960 python33.dll
05/16/2012  02:08 PM            79,872 python3.dll
               2 File(s)      3,256,832 bytes
               0 Dir(s)  60,807,380,992 bytes free

----------
components: Build, Windows
messages: 162816
nosy: loewis, pitrou, skrah
priority: normal
severity: normal
status: open
title: AMD64 debug VS9.0 build doesn't work
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 14 22:40:12 2012
From: report at bugs.python.org (Daniel C.)
Date: Thu, 14 Jun 2012 20:40:12 +0000
Subject: [New-bugs-announce] [issue15071] TLS get keys and randoms
Message-ID: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za>


New submission from Daniel C. <llaniscudani at gmail.com>:

I am develop a RADIUS server in 3.2 for WiFi authentication, the EAP-TLS or PEAP auths require a TLS tunnel AND get the master key and the client hello and server hello randoms to generate the MSK, the key to encrypt between WiFi user and WiFi access point.

The more necessary is the master key, the randoms is possible extract with "man in the middle"

Please, patch ssl.

----------
components: Library (Lib)
messages: 162825
nosy: llaniscudani
priority: normal
severity: normal
status: open
title: TLS get keys and randoms
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 15 00:47:00 2012
From: report at bugs.python.org (William Payne)
Date: Thu, 14 Jun 2012 22:47:00 +0000
Subject: [New-bugs-announce] [issue15072] Segfault on OSX
Message-ID: <1339714020.53.0.331077850595.issue15072@psf.upfronthosting.co.za>


New submission from William Payne <wtpayne at gmail.com>:

Unfortunately, I cannot provide the source of the script I was running then the crash occurred, so I strongly suspect that this issue will be closed as "cannot reproduce", but I have included the OSX problem report anyway, if it is of any use.

:-)

The script was running unit-tests & gathering unit-test coverage metrics in a separate process (using subprocess module) when the crash occurred. It was also doing some fairly funky things with dynamic imports which might have had a destabilizing influence.

Process:         Python [33830]
Path:            /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  Python [33825]

Date/Time:       2012-06-14 18:31:28.053 -0400
OS Version:      Mac OS X 10.7.4 (11E53)
Report Version:  9

Interval Since Last Report:          169200 sec
Crashes Since Last Report:           1
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      81415EC1-2F3C-4A2B-BE73-2AC40EA4A047

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000109071000-0000000109072000 [    4K] r-x/rwx SM=COW  /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Application Specific Information:
objc[33830]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x000000010912eeea 0x10907b000 + 737002
1   org.python.python             	0x000000010912f61d _PyObject_GC_Malloc + 177
2   org.python.python             	0x000000010912f6af _PyObject_GC_New + 21
3   org.python.python             	0x00000001090b28b0 PyDict_New + 109
4   org.python.python             	0x00000001090b300c PyDict_Copy + 57
5   org.python.python             	0x00000001090c9232 0x10907b000 + 320050
6   org.python.python             	0x00000001090c7afa 0x10907b000 + 314106
7   org.python.python             	0x0000000109082d32 PyObject_Call + 97
8   org.python.python             	0x0000000109082eed PyObject_CallFunctionObjArgs + 178
9   org.python.python             	0x000000010908dc0e PyClass_New + 462
10  org.python.python             	0x000000010908e9f3 0x10907b000 + 80371
11  org.python.python             	0x00000001090c7afa 0x10907b000 + 314106
12  org.python.python             	0x0000000109082d32 PyObject_Call + 97
13  org.python.python             	0x0000000109082eed PyObject_CallFunctionObjArgs + 178
14  org.python.python             	0x000000010910076b PyEval_EvalFrameEx + 4121
15  org.python.python             	0x0000000109105df7 0x10907b000 + 568823
16  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
17  org.python.python             	0x0000000109105df7 0x10907b000 + 568823
18  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
19  org.python.python             	0x0000000109105df7 0x10907b000 + 568823
20  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
21  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
22  org.python.python             	0x00000001090a3abf 0x10907b000 + 166591
23  org.python.python             	0x0000000109082d32 PyObject_Call + 97
24  org.python.python             	0x00000001090fec40 PyEval_CallObjectWithKeywords + 180
25  org.python.python             	0x00000001090fc552 0x10907b000 + 529746
26  org.python.python             	0x0000000109102d77 PyEval_EvalFrameEx + 13861
27  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
28  org.python.python             	0x0000000109105e6c 0x10907b000 + 568940
29  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
30  org.python.python             	0x0000000109105df7 0x10907b000 + 568823
31  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
32  org.python.python             	0x0000000109105df7 0x10907b000 + 568823
33  org.python.python             	0x0000000109102e0a PyEval_EvalFrameEx + 14008
34  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
35  org.python.python             	0x0000000109105d4d PyEval_EvalCode + 54
36  org.python.python             	0x0000000109113f3a PyImport_ExecCodeModuleEx + 211
37  org.python.python             	0x0000000109114482 0x10907b000 + 627842
38  org.python.python             	0x0000000109115246 0x10907b000 + 631366
39  org.python.python             	0x0000000109115454 0x10907b000 + 631892
40  org.python.python             	0x0000000109116201 PyImport_ImportModuleLevel + 1137
41  org.python.python             	0x00000001090fa506 0x10907b000 + 521478
42  org.python.python             	0x0000000109102d77 PyEval_EvalFrameEx + 13861
43  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
44  org.python.python             	0x0000000109105d4d PyEval_EvalCode + 54
45  org.python.python             	0x0000000109113f3a PyImport_ExecCodeModuleEx + 211
46  org.python.python             	0x0000000109114482 0x10907b000 + 627842
47  org.python.python             	0x0000000109114ccd 0x10907b000 + 629965
48  org.python.python             	0x0000000109115246 0x10907b000 + 631366
49  org.python.python             	0x0000000109115492 0x10907b000 + 631954
50  org.python.python             	0x0000000109116201 PyImport_ImportModuleLevel + 1137
51  org.python.python             	0x00000001090fa506 0x10907b000 + 521478
52  org.python.python             	0x0000000109082d32 PyObject_Call + 97
53  org.python.python             	0x00000001090fec40 PyEval_CallObjectWithKeywords + 180
54  org.python.python             	0x00000001091048d9 PyEval_EvalFrameEx + 20871
55  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
56  org.python.python             	0x0000000109105d4d PyEval_EvalCode + 54
57  org.python.python             	0x0000000109113f3a PyImport_ExecCodeModuleEx + 211
58  org.python.python             	0x0000000109114482 0x10907b000 + 627842
59  org.python.python             	0x0000000109114ccd 0x10907b000 + 629965
60  org.python.python             	0x0000000109115246 0x10907b000 + 631366
61  org.python.python             	0x0000000109115454 0x10907b000 + 631892
62  org.python.python             	0x0000000109116246 PyImport_ImportModuleLevel + 1206
63  org.python.python             	0x00000001090fa506 0x10907b000 + 521478
64  org.python.python             	0x0000000109082d32 PyObject_Call + 97
65  org.python.python             	0x00000001090fec40 PyEval_CallObjectWithKeywords + 180
66  org.python.python             	0x00000001091048d9 PyEval_EvalFrameEx + 20871
67  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
68  org.python.python             	0x0000000109105d4d PyEval_EvalCode + 54
69  org.python.python             	0x0000000109113f3a PyImport_ExecCodeModuleEx + 211
70  org.python.python             	0x0000000109114482 0x10907b000 + 627842
71  org.python.python             	0x0000000109115246 0x10907b000 + 631366
72  org.python.python             	0x00000001091155cc 0x10907b000 + 632268
73  org.python.python             	0x000000010911635f PyImport_ImportModuleLevel + 1487
74  org.python.python             	0x00000001090fa506 0x10907b000 + 521478
75  org.python.python             	0x0000000109082d32 PyObject_Call + 97
76  org.python.python             	0x00000001090fec40 PyEval_CallObjectWithKeywords + 180
77  org.python.python             	0x00000001091048d9 PyEval_EvalFrameEx + 20871
78  org.python.python             	0x0000000109105cd8 PyEval_EvalCodeEx + 1996
79  org.python.python             	0x0000000109105d4d PyEval_EvalCode + 54
80  org.python.python             	0x000000010911d08f 0x10907b000 + 663695
81  org.python.python             	0x000000010911d14f PyRun_FileExFlags + 157
82  org.python.python             	0x000000010911e2a2 PyRun_SimpleFileExFlags + 392
83  org.python.python             	0x000000010912e2af Py_Main + 2715
84  org.python.python             	0x0000000109071e88 0x109071000 + 3720

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x4000000000000000  rbx: 0x00000001091c4ac0  rcx: 0x00000001091c4af0  rdx: 0x00000001091c4ac0
  rdi: 0x0000000000000000  rsi: 0x0000000000000000  rbp: 0x00007fff68c696c0  rsp: 0x00007fff68c69610
   r8: 0x0000000000000016   r9: 0x0000000000000dd8  r10: 0x0000000000000000  r11: 0x000000003ae31e7c
  r12: 0x00000001091b0f30  r13: 0x000000010944bfc8  r14: 0x9000000001093a04  r15: 0x00000001091b0f30
  rip: 0x000000010912eeea  rfl: 0x0000000000010286  cr2: 0x00007ff4fbcde098
Logical CPU: 2

Binary Images:
       0x109071000 -        0x109071fff  org.python.python (2.7.1 - 2.7.1) <E2C46621-158F-349B-9131-263E8958B23A> /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x10907b000 -        0x109196ff7  org.python.python (2.7.1 - 2.7.1) <A7E34EB5-24D2-3B8F-A26B-4A5B28CD2C60> /System/Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1093c7000 -        0x1093cafff  strop.so (??? - ???) <A317730F-EDDF-3998-8A22-0E632B3E67A4> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
       0x10940f000 -        0x109410fff  time.so (??? - ???) <DA274462-B33A-33EB-90F7-BB9FB8120A5D> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
       0x109417000 -        0x109419ff7  binascii.so (??? - ???) <9B353DAC-B0E8-3B4B-91A1-50F6F86AA928> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
       0x10941d000 -        0x109428ff7  datetime.so (??? - ???) <9EC1E3BD-3BD3-3B39-AE19-448CCEEA747A> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/datetime.so
       0x109431000 -        0x109432fff  cStringIO.so (??? - ???) <AE5A2A12-8E57-3FE2-B998-C175083B27F7> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
       0x109477000 -        0x10947dfff  pyexpat.so (??? - ???) <0E02E7DD-AC97-38B5-BB3B-856249DEBFF9> /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/pyexpat.so
    0x7fff68c71000 -     0x7fff68ca5baf  dyld (195.6 - ???) <0CD1B35B-A28F-32DA-B72E-452EAD609613> /usr/lib/dyld
    0x7fff8bb2e000 -     0x7fff8bba1fff  libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib
    0x7fff8bc9d000 -     0x7fff8bcdfff7  libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib
    0x7fff8c135000 -     0x7fff8c13bff7  libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib
    0x7fff8cfef000 -     0x7fff8cffdfff  libdispatch.dylib (187.9.0 - compatibility 1.0.0) <1D5BE322-A9B9-3BCE-8FAC-076FB07CF54A> /usr/lib/system/libdispatch.dylib
    0x7fff8cffe000 -     0x7fff8d003ff7  libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib
    0x7fff8d136000 -     0x7fff8d13bfff  libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib
    0x7fff8d8c1000 -     0x7fff8d8c2fff  libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib
    0x7fff8d921000 -     0x7fff8da05e5f  libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <871E688B-CF57-3BC7-80D6-F6476DFF109B> /usr/lib/libobjc.A.dylib
    0x7fff8dba7000 -     0x7fff8dba9fff  libquarantine.dylib (36.6.0 - compatibility 1.0.0) <0EBF714B-4B69-3E1F-9A7D-6BBC2AACB310> /usr/lib/system/libquarantine.dylib
    0x7fff8f4e3000 -     0x7fff8f4e4ff7  libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib
    0x7fff8f4e5000 -     0x7fff8f6e7fff  libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib
    0x7fff9017f000 -     0x7fff901acfe7  libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <7BEBB139-50BB-3112-947A-F4AA168F991C> /usr/lib/libSystem.B.dylib
    0x7fff902bb000 -     0x7fff90331fff  libc++.1.dylib (28.1.0 - compatibility 1.0.0) <DA22E4D6-7F20-3BEA-9B89-2FBA735C2EE1> /usr/lib/libc++.1.dylib
    0x7fff90339000 -     0x7fff9050dff7  com.apple.CoreFoundation (6.7.2 - 635.21) <62A3402E-A4E7-391F-AD20-1EF20236CE1B> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff906df000 -     0x7fff906e0fff  libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff90b92000 -     0x7fff90b9dff7  libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib
    0x7fff90c5b000 -     0x7fff90c65ff7  liblaunch.dylib (392.38.0 - compatibility 1.0.0) <6ECB7F19-B384-32C1-8652-2463C1CF4815> /usr/lib/system/liblaunch.dylib
    0x7fff90d26000 -     0x7fff90e03fef  libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib
    0x7fff90e04000 -     0x7fff90e0bfff  libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib
    0x7fff91a32000 -     0x7fff91a36fff  libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib
    0x7fff91f2e000 -     0x7fff91f4efff  libsystem_kernel.dylib (1699.26.8 - compatibility 1.0.0) <1DDC0B0F-DB2A-34D6-895D-E5B2B5618946> /usr/lib/system/libsystem_kernel.dylib
    0x7fff920d0000 -     0x7fff9211efff  libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib
    0x7fff93b83000 -     0x7fff93b9efff  libexpat.1.dylib (7.2.0 - compatibility 7.0.0) <DDB91E75-A2FA-331F-8069-999127AC6A9D> /usr/lib/libexpat.1.dylib
    0x7fff94278000 -     0x7fff9427efff  libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib
    0x7fff943a9000 -     0x7fff943aafff  libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib
    0x7fff943b9000 -     0x7fff943f4fff  libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib
    0x7fff9464c000 -     0x7fff9464cfff  libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib
    0x7fff94a6c000 -     0x7fff94a89fff  libxpc.dylib (77.19.0 - compatibility 1.0.0) <9F57891B-D7EF-3050-BEDD-21E7C6668248> /usr/lib/system/libxpc.dylib
    0x7fff95187000 -     0x7fff95188ff7  libsystem_sandbox.dylib (??? - ???) <96D38E74-F18F-3CCB-A20B-E8E3ADC4E166> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff95189000 -     0x7fff9519bff7  libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib
    0x7fff96fe0000 -     0x7fff96fe4fff  libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib
    0x7fff9705f000 -     0x7fff97068ff7  libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib
    0x7fff974cc000 -     0x7fff974cdff7  libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib
    0x7fff97edf000 -     0x7fff97ee7fff  libsystem_dnssd.dylib (??? - ???) <D9BB1F87-A42B-3CBC-9DC2-FC07FCEF0016> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff98489000 -     0x7fff9848efff  libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    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: 24138
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=57.8M resident=29.7M(51%) swapped_out_or_unallocated=28.1M(49%)
Writable regions: Total=20.6M written=2800K(13%) resident=3796K(18%) swapped_out=0K(0%) unallocated=16.9M(82%)
 
REGION TYPE                      VIRTUAL
===========                      =======
MALLOC                             12.3M
MALLOC guard page                    32K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           4K
__DATA                             1364K
__LINKEDIT                         47.9M
__TEXT                              9.9M
__UNICODE                           544K
shared memory                        12K
===========                      =======
TOTAL                             136.0M

Model: MacBookPro8,1, BootROM MBP81.0047.B27, 2 processors, Intel Core i7, 2.7 GHz, 8 GB, SMC 1.68f98
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x029E, 0x434D5341344758334D314131333333433920
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x029E, 0x434D5341344758334D314131333333433920
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.106.198.4.20)
Bluetooth: Version 4.0.5f11, 2 service, 18 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: TOSHIBA MK5065GSXF, 500.11 GB
Serial ATA Device: HL-DT-ST DVDRW  GS31N
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfa100000 / 2
USB Device: hub_device, 0x0424  (SMSC), 0x2514, 0xfa130000 / 6
USB Device: Natural? Ergonomic Keyboard 4000, 0x045e  (Microsoft Corporation), 0x00db, 0xfa133000 / 10
USB Device: Evoluent VerticalMouse 4, 0x1a7c, 0x0191, 0xfa134000 / 9
USB Device: hub_device, 0x0424  (SMSC), 0x2640, 0xfa131000 / 7
USB Device: Ultra Fast Media Reader, 0x0424  (SMSC), 0x4064, 0xfa131100 / 11
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0252, 0xfa120000 / 5
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 4
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 8
USB Device: hub_device, 0x0424  (SMSC), 0x2513, 0xfd100000 / 2
USB Device: Plugable UGA-2K-A, 0x17e9  (DisplayLink (UK) Ltd.), 0x0378, 

0xfd120000 / 4
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3

----------
assignee: ronaldoussoren
components: Macintosh
messages: 162832
nosy: William.Payne, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segfault on OSX
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 15 07:53:20 2012
From: report at bugs.python.org (Pavel Fedin)
Date: Fri, 15 Jun 2012 05:53:20 +0000
Subject: [New-bugs-announce] [issue15073] commands.getoutput() is broken
Message-ID: <1339739600.87.0.936564016625.issue15073@psf.upfronthosting.co.za>


New submission from Pavel Fedin <p.fedin at samsung.com>:

commands.getoutput() is broken on Windows. The issue has been detected in v2.7.2, but still persists in v2.7.3:
--- cut ---
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import commands;
>>> print commands.getoutput("dir");
'{' is not recognized as an internal or external command,
operable program or batch file.
>>>
--- cut ---
 The error message comes from cmd.exe. Looks like Python tries to feed native Windows shell with UNIX-style commands sequence in {...}.
 I believe this is very simple to fix, please take a look at it. Some our internal software croaks because of this.

----------
components: Windows
messages: 162844
nosy: p.fedin
priority: normal
severity: normal
status: open
title: commands.getoutput() is broken
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 15 09:41:32 2012
From: report at bugs.python.org (jsevilleja)
Date: Fri, 15 Jun 2012 07:41:32 +0000
Subject: [New-bugs-announce] [issue15074] Strange behaviour of python cmd
	module. (Ignores slash)
Message-ID: <1339746092.55.0.309146138832.issue15074@psf.upfronthosting.co.za>


New submission from jsevilleja <joel at jsevilleja.org>:

I've used the code from here: http://stackoverflow.com/questions/5637124/tab-completion-in-pythons-raw-input/5638688#5638688 and it works. But I've used the same code in a class which inherits from cmd.Cmd, and the code doesn't works. Doing tests, I've noticed that if I do "put /", the argument text from "complete_put" method, skips '/' character. I don't know if this is a bug or my code is wrong, but it works with any other character, and I haven't found anything in the docs. Thanks.

----------
files: shell.py
messages: 162854
nosy: jsevilleja
priority: normal
severity: normal
status: open
title: Strange behaviour of python cmd module. (Ignores slash)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26012/shell.py

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

From report at bugs.python.org  Fri Jun 15 10:18:05 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 15 Jun 2012 08:18:05 +0000
Subject: [New-bugs-announce] [issue15075] XincludeTest failure in
	test_xml_etree
Message-ID: <1339748285.77.0.903136291102.issue15075@psf.upfronthosting.co.za>


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

The XincludeTest test-case in test_xml_etree is now skipped, because it fails in an intermittent manner. I can reproduce the failure when running full regrtest with -j1, but not -j8, and not when run individually.

The failure is most likely due to the test itself, in the way it imports the Python ET, leaving _elementtree out. 

This may be related to http://bugs.python.org/issue14035

----------
components: Tests
messages: 162870
nosy: eli.bendersky, flox
priority: normal
severity: normal
stage: test needed
status: open
title: XincludeTest failure in test_xml_etree
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 15 11:51:03 2012
From: report at bugs.python.org (Leon Zhang)
Date: Fri, 15 Jun 2012 09:51:03 +0000
Subject: [New-bugs-announce] [issue15076] Sometimes couldn't import os,
	shown 'import site' failed, use -v for trackback
Message-ID: <1339753863.16.0.615623699476.issue15076@psf.upfronthosting.co.za>


New submission from Leon Zhang <leozhang at cisco.com>:

Hello Experts,

I am using Python 2.6.2 on a Linux machine. I found sometimes I have problem to run my simple python script.

========> Linux version and Python version <========
leonz at fxcsgbu2c1% uname -a
SunOS fxcsgbu2c1 5.8 Generic_117350-06 sun4u sparc SUNW,UltraAX-i2
leonz at fxcsgbu2c1% python
Python 2.6.2 (r262:71600, Sep  9 2009, 06:36:48) 
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>

========> Problem description <========
I have one python script file located at "/usr/autoprog/LogUtility/pygen.py", the first 4 lines are:
line 1: #!/usr/bin/python
line 2: import sys
line 3: import os
line 4: import traceback

If I just run "python /usr/autoprog/LogUtility/pygen.py" from shell, the script always worked fine.
We are running another application called "autotest" on this machine, "autotest" will create a new process and launch Python in this new process (/usr/bin/python /usr/autoprog/LogUtility/pygen.py) to run my Python script.
Most of the time, the Python script worked fine, but from some time, for some reason, the script suddenty failed, and from this time, if I run autotest to luanch my python script, it always fails, but if I run the python script from shell, it always works fine. If I reboot this machine, both way to run python script works fine. But after some time, run autotest to luanch python script will fail again...
Here is the details of the error message of running autotest to luanch python script:
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/usr/autoprog/SGBU/LogUtility/pygen.py", line 19, in <module>
import os
File "/usr/local/lib/python2.6/os.py", line 49, in <module>
import posixpath as path
File "/usr/local/lib/python2.6/posixpath.py", line 16, in <module>
import warnings
File "/usr/local/lib/python2.6/warnings.py", line 6, in <module>
import linecache
ImportError: No module named linecache

========> Some other information may help <========
I had searched "'import site' failed; use -v for traceback" on internet, there are also many other people have this problem, but I didn't see any useful information to fix my problem.
Here are some information about the Python on my machine:
Install path is /usr/local/lib/python2.6
There is just one "README" file under /usr/local/lib/python2.6/site-packages

Attached is the python script file "pygen.py". Could any expert help me on this problem? Appreciate if any experts can reply me. Thanks.

----------
components: Library (Lib)
files: pygen.py
messages: 162879
nosy: qtld614
priority: normal
severity: normal
status: open
title: Sometimes couldn't import os, shown 'import site' failed, use -v for trackback
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file26015/pygen.py

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

From report at bugs.python.org  Fri Jun 15 12:41:10 2012
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Fri, 15 Jun 2012 10:41:10 +0000
Subject: [New-bugs-announce] [issue15077] Regexp match goes into infinite
	loop
Message-ID: <1339756870.03.0.464046287951.issue15077@psf.upfronthosting.co.za>


New submission from Moriyoshi Koizumi <mozo+python at mozo.jp>:

A peculiar pair of a regexp and a target string causes the runtime into an infinite loop.  The same expression works with Perl.

----------
components: Regular Expressions
files: x.py
messages: 162883
nosy: ezio.melotti, moriyoshi, mrabarnett
priority: normal
severity: normal
status: open
title: Regexp match goes into infinite loop
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26016/x.py

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

From report at bugs.python.org  Fri Jun 15 12:53:38 2012
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 15 Jun 2012 10:53:38 +0000
Subject: [New-bugs-announce] [issue15078] Change os.sendfile so its
	arguments are stable
Message-ID: <1339757618.68.0.436456402492.issue15078@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

As I keep saying on python-dev: I think that the argument list for a function should be stable.  If you have a function where some abilities are only available on certain platforms, it's best to always accept default no-op parameters for those parameters, rather than adding and removing parameters based on what functionality is available.

os.sendfile() accepts either four or seven parameters, depending on the current platform.  However, it's a new function in trunk and therefore has no installed base.  So it's not too late to change it.

I propose to amend os.sendfile so it always accepts all seven arguments.  Its signature would therefore be the following, on all platforms:

os.sendfile(out, in, offset, nbytes, headers=None, trailers=None, flags=0)

Passing in a non-None value for headers or trailers, or a nonzero value for flags, on a platform where the seven-argument form of sendfile is not available would raise NotImplementedError.

----------
assignee: larry
messages: 162886
nosy: larry
priority: normal
severity: normal
status: open
title: Change os.sendfile so its arguments are stable
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 15 18:37:50 2012
From: report at bugs.python.org (Stefan M)
Date: Fri, 15 Jun 2012 16:37:50 +0000
Subject: [New-bugs-announce] [issue15079] pickle: Possibly misplaced test
Message-ID: <1339778270.97.0.949730169084.issue15079@psf.upfronthosting.co.za>


New submission from Stefan M <mstefanro at gmail.com>:

After issue7455 was fixed, a test was created to reflect the fix (Lib/test/pickletester.py @ AbstractPickleModuleTests.test_bad_input). The test makes sure that an UnpicklingError is raised whenever pickled data attempts to pop on an empty stack.
Although tests on AbstractPickleModuleTests normally only run on the C implementation of pickle (on which UnpicklingError is thrown), they may also run on the Python implementation if the C implementation of pickle is not available (which throws IndexError). I'm not sure if it's still reasonable to assume that it's possible for the C implementation of pickle not to exist (the python module does), as I've discovered this by forcefully disabling the C implementation.

>>> pickle.Unpickler(io.BytesIO(b'0')).load()
_pickle.UnpicklingError: unpickling stack underflow

>>> pickle._Unpickler(io.BytesIO(b'0')).load()
IndexError: list assignment index out of range

The current fix involves adding IndexError to the list of exceptions that may be raised and moving the testcase to AbstractPickleTests (where the tests are ran against both the C and Python impl).

As I'm working on improving pickle in protocol v4, it might be worth considering adding more consistency to the exceptions that are being raised by the Python unpickler.

----------
components: Tests
files: pickletester.py.patch
keywords: patch
messages: 162919
nosy: alexandre.vassalotti, collinwinter, mstefanro
priority: normal
severity: normal
status: open
title: pickle: Possibly misplaced test
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26019/pickletester.py.patch

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

From report at bugs.python.org  Fri Jun 15 22:20:56 2012
From: report at bugs.python.org (Jeremy Gillick)
Date: Fri, 15 Jun 2012 20:20:56 +0000
Subject: [New-bugs-announce] [issue15080] Cookie library doesn't parse date
	properly
Message-ID: <1339791656.15.0.174723735856.issue15080@psf.upfronthosting.co.za>


New submission from Jeremy Gillick <j_gillick at yahoo.com>:

The cookie library doesn't seem to support the standard date format (RFC 822) for the expire property while parsing a cookie. 

For example, in the Python prompt:

    >>> import Cookie
    >>> cookie = Cookie.SimpleCookie('bcookie="123"; Expires=Sat, 14-Jun-2014 23:03:13 GMT;')
    >>> cookie['bcookie']['expires']
    'Sat,'

That is a standard header, but it only processes the date up to the first space.

----------
components: Library (Lib)
messages: 162932
nosy: jgillick
priority: normal
severity: normal
status: open
title: Cookie library doesn't parse date properly
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 16 02:07:51 2012
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Jun 2012 00:07:51 +0000
Subject: [New-bugs-announce] [issue15081] No documentation for
	PyState_FindModule()
Message-ID: <1339805271.75.0.926484818342.issue15081@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Dear Martin,

I can't find any documentation of PyState_FindModule() in the official. According to hg annotate you are the creator of the function.

----------
assignee: loewis
components: Documentation
messages: 162944
nosy: christian.heimes, loewis
priority: low
severity: normal
status: open
title: No documentation for PyState_FindModule()
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 16 03:52:08 2012
From: report at bugs.python.org (George Stephanos)
Date: Sat, 16 Jun 2012 01:52:08 +0000
Subject: [New-bugs-announce] [issue15082] [httplib] httplib.BadStatusLine on
	any HTTPS connection	in certain unknown cases.
Message-ID: <1339811528.79.0.0690651710917.issue15082@psf.upfronthosting.co.za>


New submission from George Stephanos <gaf.stephanos at gmail.com>:

When trying to POST /anything/ @ https://grooveshark.com/, I get an httplib.BadStatusLine exception (server returns nothing at all. It's a timeout since it waits a while).

The many Grooveshark webclients however works perfectly, along with a curl command (run through cygwin, commented out in the script) that does the exact same. Meaning this weird behavior is exclusive to Python.

This issue was found to be present on many Windows systems. However, not all (all the systems have Python 2.7.2). I'm not sure what the difference is, and I'm not sure if this is a Python bug, but this is the only place I could think of to discuss the behavior. The only Linux system I've tested this on worked (again, Python 2.7.2).
Note: If it fails on one system, it never succeeds no matter how much you try.

The code *used* to work yesterday and it's been working for many months. Grooveshark might have changed something but this doesn't make any sense since curl works.

Please try to reproduce this. I can provide any testing details needed.
A script containing the code to test with is attached, along with the curl line and a BadStatusLine traceback.

Excuse my complete ignorance on the inner workings of SSL and my weak English skills (second language).

----------
components: Windows
files: ssltest.py
messages: 162947
nosy: jtr51
priority: normal
severity: normal
status: open
title: [httplib] httplib.BadStatusLine on any HTTPS connection in certain unknown cases.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26024/ssltest.py

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

From report at bugs.python.org  Sat Jun 16 05:52:39 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 16 Jun 2012 03:52:39 +0000
Subject: [New-bugs-announce] [issue15083] Rewrite ElementTree tests in a
	cleaner and safer way
Message-ID: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>


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

As #15075 demonstrated, the ET tests are sensitive to execution order because of the way they operate.

Two sets of tests (one for the C module and one for the pure Python module) operate from the same test code, monkey-patching the imported module. This sometimes breaks. A more robust solution is needed that is completely deterministic and does not rely on import artifacts.

----------
assignee: eli.bendersky
components: Tests
messages: 162952
nosy: eli.bendersky, flox, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Rewrite ElementTree tests in a cleaner and safer way
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jun 16 09:10:50 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Jun 2012 07:10:50 +0000
Subject: [New-bugs-announce] [issue15084] Add option to os.makefile to not
	raise an exception for	existing directories
Message-ID: <1339830650.07.0.788386004533.issue15084@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

I commonly see the code pattern:

try:
    os.mkdir(dirname)
except OSError:
    pass

It would be nice to have this instead:

   os.mkdir(dirname, ignore_if_existing=True)

There's probably a better name for the keyword argument, but it communicates the idea clearly enough.

----------
messages: 162956
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add option to os.makefile to not raise an exception for existing directories
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 16 11:09:09 2012
From: report at bugs.python.org (Stefan Krastanov)
Date: Sat, 16 Jun 2012 09:09:09 +0000
Subject: [New-bugs-announce] [issue15085] set.union accepts not set
	iterables for all but the	first argument.
Message-ID: <1339837749.11.0.973257724486.issue15085@psf.upfronthosting.co.za>


New submission from Stefan Krastanov <krastanov.stefan at gmail.com>:

>>> set.union(set([1,2]), [3])
set([1, 2, 3])

>>> set.union([1,2], [3])
TypeError: descriptor 'union' requires a 'set' object but received a 'list'


It seems a bit inconsistent. Is it justified somehow?

----------
components: None
messages: 162962
nosy: krastanov-stefan
priority: normal
severity: normal
status: open
title: set.union accepts not set iterables for all but the first argument.
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 16 20:18:03 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Jun 2012 18:18:03 +0000
Subject: [New-bugs-announce] [issue15086] Ubuntu bot: error while loading
	shared libraries
Message-ID: <1339870683.52.0.123357667128.issue15086@psf.upfronthosting.co.za>


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

The Ubuntu shared buildbot fails to run the tests:

 using PTY: True
./python: error while loading shared libraries: libpython3.3dm.so.1.0: cannot open shared object file: No such file or directory
make: *** [Python/importlib.h] Error 127



034c814eb187 was O.K., as far as the logs are still visible the error
first appears in 240b7467e65c .

----------
components: Tests
keywords: buildbot
messages: 162981
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Ubuntu bot: error while loading shared libraries
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 17 03:34:39 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Jun 2012 01:34:39 +0000
Subject: [New-bugs-announce] [issue15087] Add gzip function to read gzip'd
	strings
Message-ID: <1339896879.03.0.627255791455.issue15087@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The API for the gzip module is convenient for reading gzipped file but is rather awkward for reading bytes downloaded from a socket:

  >>> import gzip, io
  >>> from urllib.request import urlopen, Request
  >>> u = urlopen(Request('http://www.nytimes.com', headers={'Accept-Encoding': 'gzip'}))
  >>> content = gzip.GzipFile(fileobj=io.BytesIO(u.read()), mode='rb').read()

It would be better if the last line could be written:

  >>> content = gzip.decompress_file(u)

----------
components: Library (Lib)
messages: 163004
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add gzip function to read gzip'd strings
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 17 06:21:01 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jun 2012 04:21:01 +0000
Subject: [New-bugs-announce] [issue15088] PyGen_NeedsFinalizing is public,
	but undocumented
Message-ID: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Currently undocumented: http://docs.python.org/py3k/c-api/gen.html
Public API in a released version of Python: http://hg.python.org/cpython/file/3.2/Include/genobject.h

----------
messages: 163012
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PyGen_NeedsFinalizing is public, but undocumented

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

From report at bugs.python.org  Sun Jun 17 08:51:13 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Jun 2012 06:51:13 +0000
Subject: [New-bugs-announce] [issue15089] Add gzip support to
	urllib.request.retrieve()
Message-ID: <1339915873.52.0.115462585972.issue15089@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Enable retrieve() to take advantage of data compression in HTTP requests.

* In the request, add the header "Accept-Encoding: gzip".
* In the response, check the headers for "Content-Encoding: gzip".
* Convert the downloaded content using gzip.GzipFile.

----------
components: Library (Lib)
keywords: easy
messages: 163020
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add gzip support to urllib.request.retrieve()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun 17 09:02:37 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Jun 2012 07:02:37 +0000
Subject: [New-bugs-announce] [issue15090] Add etag support to
	urllib.request.urlretrieve()
Message-ID: <1339916557.45.0.663415683134.issue15090@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Add an optional argument to urlretrieve to specify an etag for previously downloaded content:

    >>> urlretrieve('example.com/data.txt', etag="105800d-4af6-4c29d893d69c0")

That optional argument would add the following to the outgoing headers:

    "If-None-Match: 105800d-4af6-4c29d893d69c0"

If the site returns a 304 Not Modified, then the full content download isn't needed.

----------
components: Library (Lib)
messages: 163021
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add etag support to urllib.request.urlretrieve()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun 17 11:04:15 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jun 2012 09:04:15 +0000
Subject: [New-bugs-announce] [issue15091] ImportError when package is
	symlinked on Unix
Message-ID: <1339923855.95.0.218612178638.issue15091@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In testing issue6727, I added a test (http://hg.python.org/cpython/rev/afe67ea94bc6) to the default branch. The test passes on Windows, but fails on some of the Unix buildbots. Here's a quick breakdown of where it's passing and failing:

fail:
 x86 Gentoo 3.x
 x86 Gentoo Non-Debug 3.x
 x86 Ubuntu Shared 3.x
 AMD64 FreeBSD 9.0 3.x
 x86 debian parallel 3.x
 x86 RHEL 6 3.x
 ARM Ubuntu 3.x
 x86 Solaris 11 3.x
pass:
 AMD64 Gentoo Wide 3.x
 AMD64 Ubuntu LTS 3.x
 AMD64 OpenIndiana 3.x
 AMD64 Fedora without threads 3.x
 AMD64 Ubuntu LTS bigmem 3.x
 x86 Tiger 3.x
 x86 OpenIndiana 3.x
 x86 FreeBSD 7.2 3.x
 x86 FreeBSD 6.4 3.x

As far as I can tell, the failures don't seem to have an obvious correlation. I will be disabling this test for non-Windows boxes, but it's probably worth tracking down why the test is failing.

I should also note that this test is included in Python 2.7 and does not fail on the Unix.

----------
components: Interpreter Core
messages: 163039
nosy: brett.cannon, jason.coombs
priority: normal
severity: normal
status: open
title: ImportError when package is symlinked on Unix
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 17 11:21:07 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Jun 2012 09:21:07 +0000
Subject: [New-bugs-announce] [issue15092] Using enum PyUnicode_Kind
Message-ID: <1339924867.59.0.117831113894.issue15092@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Now a string kind declared in different places of code as `enum PyUnicode_Kind`, `int` or `unsigned int`. Working on the codecs optimization, I noticed that sometimes the use of `enum PyUnicode_Kind` gives a little advantage over the use of int's. Probably this hint allows compiler to better utilize the optimizer. The proposed patch replaces all string kind's declarations of local variables and private functions to `enum PyUnicode_Kind`. If this will not impact significantly on the performance, then at least the unification will enhance the readability and will allow to avoid some of the errors (missing switch cases).

----------
components: Interpreter Core
files: enum_PyUnicode_Kind.patch
keywords: patch
messages: 163043
nosy: storchaka
priority: normal
severity: normal
status: open
title: Using enum PyUnicode_Kind
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file26033/enum_PyUnicode_Kind.patch

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

From report at bugs.python.org  Sun Jun 17 11:28:57 2012
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 Jun 2012 09:28:57 +0000
Subject: [New-bugs-announce] [issue15093] ntpath.isdir returns False for
	directory symlinks
Message-ID: <1339925337.89.0.456468873164.issue15093@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

On Unix:

python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo'); print(os.path.isdir('foo'))"
True

On Windows:
python -c "import os; os.mkdir('bar'); os.symlink('bar', 'foo'); print(os.path.isdir('foo'))"
False

Windows should correctly discern the directory-ness of a symlink (especially since in Windows, the symlink itself has a directory-ness).

----------
components: Windows
messages: 163044
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: ntpath.isdir returns False for directory symlinks
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 17 11:57:27 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Jun 2012 09:57:27 +0000
Subject: [New-bugs-announce] [issue15094] Incorrectly placed #endif in
	_tkinter.c.
Message-ID: <1339927047.37.0.67596869478.issue15094@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

#endif is placed incorrectly in _tkinter.c. As a result, braces are unbalanced when TCL_UTF_MAX != 3. This is Python 3.3 only error.

There are no tests yet. Just wait a few years until TCL will support non-BMP characters or use a time machine.

----------
components: Extension Modules, Tkinter
files: tkinter_endif.patch
keywords: patch
messages: 163050
nosy: storchaka
priority: normal
severity: normal
status: open
title: Incorrectly placed #endif in _tkinter.c.
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file26034/tkinter_endif.patch

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

From report at bugs.python.org  Sun Jun 17 13:09:54 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jun 2012 11:09:54 +0000
Subject: [New-bugs-announce] [issue15095] test_imaplib problem -
	intermittent skips and	LOGINDISABLED not reported
Message-ID: <1339931394.61.0.931073792835.issue15095@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When running the test suite on Fedora 17 (and behind a couple of layers of NAT), I see the following problems:

Intermittently: skipped "Resource 'cyrus.andrew.cmu.edu' is not available"

Consistently (with a couple of tests updated to use the improved assertion methods for containment testing):

======================================================================
FAIL: test_logincapa (test.test_imaplib.RemoteIMAPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py32/Lib/test/test_imaplib.py", line 236, in test_logincapa
    self.assertIn('LOGINDISABLED', self.server.capabilities)
AssertionError: 'LOGINDISABLED' not found in ('IMAP4REV1', 'LITERAL+', 'ID', 'ENABLE', 'ACL', 'RIGHTS=KXTE', 'QUOTA', 'MAILBOX-REFERRALS', 'NAMESPACE', 'UIDPLUS', 'NO_ATOMIC_RENAME', 'UNSELECT', 'CHILDREN', 'MULTIAPPEND', 'BINARY', 'CATENATE', 'CONDSTORE', 'ESEARCH', 'SORT', 'SORT=MODSEQ', 'SORT=DISPLAY', 'THREAD=ORDEREDSUBJECT', 'THREAD=REFERENCES', 'ANNOTATEMORE', 'LIST-EXTENDED', 'WITHIN', 'QRESYNC', 'SCAN', 'XLIST', 'URLAUTH', 'URLAUTH=BINARY', 'MUPDATE=MUPDATE://MUPDATE.ANDREW.CMU.EDU/', 'AUTH=GSSAPI', 'AUTH=PLAIN', 'AUTH=ANONYMOUS', 'SASL-IR', 'STARTTLS')

----------
messages: 163053
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_imaplib problem - intermittent skips and LOGINDISABLED not reported
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun 17 14:17:39 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jun 2012 12:17:39 +0000
Subject: [New-bugs-announce] [issue15096] Drop support for the "ur" string
	prefix
Message-ID: <1339935459.47.0.228207726214.issue15096@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When PEP 414 restored support for explicit Unicode literals in Python 3, the "ur" string prefix was deemed to be a synonym for the "r" prefix.

However, "ur" in 2.x was only kinda-sorta-raw, since it still supported Unicode escapes:

$ python
Python 2.7.3 (default, Apr 30 2012, 21:18:11) 
[GCC 4.7.0 20120416 (Red Hat 4.7.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print(ur'\u03B3')
?

By contrast, they really are raw strings in 3.x, because the default UTF-8 source code encoding allows arbitrary Unicode characters to be included directly in the literal:

$ ./python
Python 3.3.0a4+ (default:cfbf6aa5c9e3+, Jun 17 2012, 15:25:45) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> r"?"
'?'
>>> "\U000003B3"
'?'
>>> r"\U000003B3"
'\\U000003B3'
>>> ur"\U000003B3"
'\\U000003B3'

Rather than reintroducing this weird legacy not-really-raw string behaviour, I'd prefer to revert this aspect of the PEP 414 changes completely.

----------
components: Interpreter Core
messages: 163062
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Drop support for the "ur" string prefix
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 17 16:23:56 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 17 Jun 2012 14:23:56 +0000
Subject: [New-bugs-announce] [issue15097] Improving wording on the
	thread-safeness of import
Message-ID: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

http://docs.python.org/library/threading.html#importing-in-threaded-code

Currently, the documentation states
"Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module."

which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block.

As such, I would suggest rephrasing it to something like:
"Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module."

There are two additional points that might be interesting to note:
(1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests.
(1b) so: never, ever, have code that causes locks in a different thread  in module level code witout 'if __name__=="__main__" ' blocks?

(2) The lock is also acquired if a module has already been imported. For instance, in

import sys # (1)
def f():
    import sys # (2)

the import lock is acquired in (1) /and/ (2).


Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens).

----------
assignee: docs at python
components: Documentation
files: deadlock.py
messages: 163068
nosy: docs at python, valhallasw
priority: normal
severity: normal
status: open
title: Improving wording on the thread-safeness of import
type: enhancement
Added file: http://bugs.python.org/file26037/deadlock.py

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

From report at bugs.python.org  Sun Jun 17 17:39:28 2012
From: report at bugs.python.org (Marco Buccini)
Date: Sun, 17 Jun 2012 15:39:28 +0000
Subject: [New-bugs-announce] [issue15098] "TypeError" can give a misleading
	message
Message-ID: <1339947568.49.0.0833314799207.issue15098@psf.upfronthosting.co.za>


New submission from Marco Buccini <marcusbu at gmail.com>:

Suppose that you have an instance method that takes 2 arguments: one is required, while the other is a keyword argument. 

If you call that method without passing the required argument, but instead you only set the keyword argument, then you will get a TypeError exception, claiming this ...
 -> TypeError: 'method' takes at least 2 arguments (2 given)

(I am referring to this particular method: http://www.voidspace.org.uk/python/mock/mock.html#mock.Mock.mock_add_spec)

@patch('xyz.subprocess.Popen')
def test_xyz(self, mocked_popen):
    mocked_popen.mock_add_spec(spec_set=True)

I think the right error message should be different, in particular should be this:
 -> TypeError: 'method' takes at least 2 arguments (1 given)

----------
components: Interpreter Core
messages: 163072
nosy: markon
priority: normal
severity: normal
status: open
title: "TypeError" can give a misleading message
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 18 12:59:59 2012
From: report at bugs.python.org (John Firestone)
Date: Mon, 18 Jun 2012 10:59:59 +0000
Subject: [New-bugs-announce] [issue15099] exec of function doesn't call
	__getitem__ or __missing__	on undefined global
Message-ID: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>


New submission from John Firestone <johnf at freenet.de>:

exec(source, Dict()) doesn't call Dict().__getitem__ or Dict().__missing__ if the source string contains a function and the function references an undefined global.

class Dict1(dict):
    def __getitem__(self, key):
        print '    __getitem__', repr(key)
        if key == 's':
            return None
        return dict.__getitem__(self, key)

class Dict2(dict):
    def __missing__(self, key):
        print '    __missing__', repr(key)
        return None

source = """if 1:
    print '  1'
    s
    def f():
        print '  2'
        s
        print '  3'
    f()"""

print 'Dict1.__getitem__'
try:
    exec(source, Dict1())
except NameError as exc_value:
    print '  %s: %s' % (exc_value.__class__.__name__, exc_value)

print 'Dict2.__missing__'
try:
    exec(source, Dict2())
except NameError as exc_value:
    print '    %s: %s' % (exc_value.__class__.__name__, exc_value)


Python 2.7.3 (v2.7.3:70274d53c1dd, Apr  9 2012, 20:32:06) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
>>> import curiosity
Dict1.__getitem__
  1
    __getitem__ 's'
    __getitem__ 'f'
  2
    NameError: global name 's' is not defined
Dict2.__missing__
  1
    __missing__ 's'
  2
    NameError: global name 's' is not defined
>>>

----------
components: Interpreter Core
files: curiosity.py
messages: 163095
nosy: johnf
priority: normal
severity: normal
status: open
title: exec of function doesn't call __getitem__ or __missing__ on undefined global
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26041/curiosity.py

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

From report at bugs.python.org  Mon Jun 18 13:57:48 2012
From: report at bugs.python.org (Radoslaw A. Zarzynski)
Date: Mon, 18 Jun 2012 11:57:48 +0000
Subject: [New-bugs-announce] [issue15100] Race conditions in shutil.copy,
	shutil.copy2 and shutil.copyfile
Message-ID: <1340020668.92.0.801725909503.issue15100@psf.upfronthosting.co.za>


New submission from Radoslaw A. Zarzynski <radoslaw.zarzynski at student.put.poznan.pl>:

shutil.copy and shutil.copy2 first copy a file content and afterwards
change permissions of a destination file. Unfortunately, the sequence isn't atomical and may lead to disclosure of matter of any file that is being duplicated.
            
Additionally, shutil.copyfile procedure seems to have a problem with symlinks that could result in the corruption of content of any file on filesystem (in favorable conditions).

Some functions from shutil module that depend on copy[2] (and thus copyfile) are vulnerable too.
For example, shutil.move is using copy2 when os.rename fails because of file transfer between filesystems.

I have attached listing from strace(1) system utility below that illustrates the disclosure problem.

# ls -l ./shutil_test
-r-------- 1 root root 10 06-18 11:42 shutil_test

# strace -- python -c "import shutil; shutil.move('./shutil_test', '/tmp')"
<many irrelevant lines>
open("./shutil_test", O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
open("/tmp/shutil_test", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat(3, {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13e000
read(3, "blablabla\n", 16384)           = 10
read(3, "", 12288)                      = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd82e13d000
read(3, "", 16384)                      = 0
write(4, "blablabla\n", 10)             = 10
close(4)                                = 0
munmap(0x7fd82e13d000, 4096)            = 0
close(3)                                = 0
munmap(0x7fd82e13e000, 4096)            = 0
stat("./shutil_test", {st_mode=S_IFREG|0400, st_size=10, ...}) = 0
utimes("/tmp/shutil_test", {{1340012952, 0}, {1340012539, 0}}) = 0
chmod("/tmp/shutil_test", 0400)         = 0

Quick fix for the first issue could rely on os.umask but much more elegant and composite solution might use combination of os.open, os.fchmod and os.fdopen instead of open(dst, 'wb') in shutil.copyfile procedure which additionally rectifies the problem with symlink attack.
However, I am not sure that the last one is portable and won't mess with another code.
I have prepared *untested* patches for both propositions.

Best regards,
Radoslaw A. Zarzynski

----------
components: Library (Lib)
files: python_shutil_copyfile.diff
keywords: patch
messages: 163096
nosy: radoslaw.zarzynski
priority: normal
severity: normal
status: open
title: Race conditions in shutil.copy, shutil.copy2 and shutil.copyfile
type: security
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file26042/python_shutil_copyfile.diff

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

From report at bugs.python.org  Mon Jun 18 16:33:41 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 18 Jun 2012 14:33:41 +0000
Subject: [New-bugs-announce] [issue15101] multiprocessing pool finalizer can
	fail if triggered in	background pool thread
Message-ID: <1340030021.48.0.355749717921.issue15101@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

Multiprocessing's process pool originally used a finalizer to shutdown the pool when the pool object is garbage collected.

Since the maxtasksperchild feature was added, the worker_handler thread holds a reference to the pool, preventing garbage collection at least until that thread finished.

In some cases the last reference to the pool is owned by the worker_handler thread, and as it exits, the finalizer is triggered.  Since the finalizer tries to join the worker_handler thread, an error will be raised since a thread cannot join itself.

It would have been better if pools had used the context manager protocol rather than using RAII -- see Issue #15064.

Unless/until RAII usage is fixed, a quick fix would be to just make the finalizer skip trying to join the current thread.

----------
messages: 163101
nosy: sbt
priority: normal
severity: normal
status: open
title: multiprocessing pool finalizer can fail if triggered in background pool thread
type: behavior

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

From report at bugs.python.org  Mon Jun 18 16:48:16 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 18 Jun 2012 14:48:16 +0000
Subject: [New-bugs-announce] [issue15102] Fix 64-bit building for buildbot
	scripts
Message-ID: <1340030896.31.0.399200852267.issue15102@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

The buildbot scripts do not work for the 64-bit targets.

Firstly, the "/p:UseEnv=True" parameter to msbuild causes the 32-bit only projects (make_buildinfo and make_versioninfo) to fail due to architecture mismatch.  The scripts now unconditionally build those projects using the 32-bit command-line tools.

The make_versioninfo project wasn't completely converted to be 32-bit only (issue9981); it would work correctly only from the IDE.  This fixes that and removes the Debug configuration as that was already #ifdef'd in the generated .h file.

----------
components: Build, Cross-Build, Windows
hgrepos: 136
messages: 163102
nosy: jkloth
priority: normal
severity: normal
status: open
title: Fix 64-bit building for buildbot scripts
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 18 23:38:01 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Jun 2012 21:38:01 +0000
Subject: [New-bugs-announce] [issue15103] Solaris compiler chokes on
	importlib.h
Message-ID: <1340055481.5.0.751999548135.issue15103@psf.upfronthosting.co.za>


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

The Solaris compiler chokes on the embedded NUL character. Perhaps we can find another way to remove the importlib.h diffs from the notification e-mails (simply hardcode the filename?).

http://www.python.org/dev/buildbot/all/builders/x86%20Solaris%2011%203.x/builds/21/steps/compile/logs/stdio

/opt/solarisstudio/bin/cc -c  -O    -I. -I./Include    -DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c
"Python/importlib.h", line 3847: null character in input
cc: acomp failed for Python/frozen.c

----------
components: Interpreter Core
messages: 163124
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Solaris compiler chokes on importlib.h
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 19 10:02:45 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 08:02:45 +0000
Subject: [New-bugs-announce] [issue15104] abusive language in __name__
	description
Message-ID: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

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

"It is this environment in which the idiomatic ?conditional script? stanza causes a script to run"

?!?

----------
assignee: docs at python
components: Documentation
messages: 163140
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: abusive language in __name__ description

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

From report at bugs.python.org  Tue Jun 19 15:19:59 2012
From: report at bugs.python.org (vjp)
Date: Tue, 19 Jun 2012 13:19:59 +0000
Subject: [New-bugs-announce] [issue15105] curses: wrong indentation
Message-ID: <1340111999.91.0.28631303072.issue15105@psf.upfronthosting.co.za>


New submission from vjp <volker.pilipp at dectris.com>:

Running the program below on Linux (CentOS 5 and 6) two lines are printed, of which the second one is not correctly indented:

Output is:
1234567012345670
               012345670
rather than 
1234567012345670
       012345670




import curses
import time

def display(screen):
    while 1:
        screen.erase()
        screen.addstr("1234567012345670\n")
        screen.addstr("       012345670\n")
        screen.refresh()

        time.sleep(100)
                        
curses.wrapper(display)

----------
messages: 163161
nosy: vjp
priority: normal
severity: normal
status: open
title: curses: wrong indentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 19 17:42:52 2012
From: report at bugs.python.org (Ken Cheung)
Date: Tue, 19 Jun 2012 15:42:52 +0000
Subject: [New-bugs-announce] [issue15106] Potential Bug in errors.c
Message-ID: <1340120572.84.0.94173614856.issue15106@psf.upfronthosting.co.za>


New submission from Ken Cheung <msrbugzilla at gmail.com>:

I observed a code clone from the following files.

function : PyErr_Restore @ (file: "Python-3.3.0a4/Python/errors.c", line: 27)~49
function : PyErr_SetExcInfo @ (file: "Python-3.3.0a4/Python/errors.c", line: 341)~353

The function PyErr_Restore performs some checking on traceback while PyErr_SetExcInfo does not. I wonder if this is necessary in the function PyErr_SetExcInfo. The source code is included in the attachment. Hope it helps.

----------
components: None
files: errors_clone.txt
messages: 163181
nosy: Ken.Cheung
priority: normal
severity: normal
status: open
title: Potential Bug in errors.c
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26049/errors_clone.txt

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

From report at bugs.python.org  Tue Jun 19 17:59:21 2012
From: report at bugs.python.org (Ken Cheung)
Date: Tue, 19 Jun 2012 15:59:21 +0000
Subject: [New-bugs-announce] [issue15107] Potential Bug in mpdecimal.c
Message-ID: <1340121561.65.0.31237517889.issue15107@psf.upfronthosting.co.za>


New submission from Ken Cheung <msrbugzilla at gmail.com>:

I observed a code clone from the following files.

function : mpd_qexp @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4092)~4165
function : mpd_qln @ (file: "Python-3.3.0a4/Modules/_decimal/libmpdec/mpdecimal.c", line: 4525)~4612

In the first few lines of this clone, the function mpd_qexp only calls mpd_setspecial when mpd_isnegative is false while the function mpd_qln calls mpd_setspecial independent of the value of mpd_isnegative. I wonder the checking is necessary in the function mpd_qln. The source code is included in the attachment. Hope it helps.

----------
components: Library (Lib)
files: mpdecimal_clone.txt
messages: 163185
nosy: Ken.Cheung
priority: normal
severity: normal
status: open
title: Potential Bug in mpdecimal.c
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26051/mpdecimal_clone.txt

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

From report at bugs.python.org  Tue Jun 19 23:52:14 2012
From: report at bugs.python.org (Pankaj D)
Date: Tue, 19 Jun 2012 21:52:14 +0000
Subject: [New-bugs-announce] [issue15108] ERROR: SystemError:
	./../Objects/tupleobject.c:118: bad	argument to internal function
Message-ID: <1340142734.59.0.259692259195.issue15108@psf.upfronthosting.co.za>


New submission from Pankaj D <pxd at comcast.net>:

Hi,

Sporadically, while running an sqlite3 query, the above error is seen.
In order to debug, I modified Objects/tupleobject.c, PyTuple_SetItem() as follows:

	if (!PyTuple_Check(op) || op->ob_refcnt != 1) {
		Py_XDECREF(newitem);
		/*
		 * Temp: Bug XYZ Generate core so that we can debug
		 *  
		 * PyErr_BadInternalCall();
		 * return -1;
		*/
		char errmsg[200];
		sprintf(errmsg, "Bug XYZ: PyTuple_Check(op) = %d "
			"op->ob_refcnt = %d; see core\n", PyTuple_Check(op),
			op->ob_refcnt);
		Py_FatalError(errmsg); 
	}

This generates a core with the following bt.  Showing the top few frames only:
(gdb) bt
#0  0x0000000800acd3fc in thr_kill () at thr_kill.S:3
#1  0x0000000800b5e283 in abort () at /build/mnt/src/lib/libc/stdlib/abort.c:65
#2  0x0000000000494acf in Py_FatalError (msg=Variable "msg" is not available.
) at ./../Python/pythonrun.c:1646
#3  0x000000000044e740 in PyTuple_SetItem (op=0x80c6e6308, i=16, newitem=0x80a80d780) at ./../Objects/tupleobject.c:128
#4  0x0000000807298866 in _pysqlite_fetch_one_row (self=0x80b846e48) at _sqlite/cursor.c:402
#5  0x0000000807298bf5 in pysqlite_cursor_iternext (self=0x80b846e48) at _sqlite/cursor.c:898
#6  0x0000000000476943 in PyEval_EvalFrameEx (f=0x80a94d420, throwflag=Variable "throwflag" is not available.
) at ./../Python/ceval.c:2237
#7  0x000000000047acbf in PyEval_EvalFrameEx (f=0x80a94b820, throwflag=Variable "throwflag" is not available.
) at ./../Python/ceval.c:3765
#8  0x000000000047bf09 in PyEval_EvalCodeEx (co=0x808d2ac60, globals=Variable "globals" is not available.
) at ./../Python/ceval.c:2942
...
(gdb) fr 4
#4  0x0000000807298866 in _pysqlite_fetch_one_row (self=0x80b846e48) at _sqlite/cursor.c:402
402	            PyTuple_SetItem(row, i, converted);
Current language:  auto; currently c
(gdb) l
397	                converted = buffer;
398	            }

(gdb) p *(PyTupleObject *)row
$11 = {ob_refcnt = 2, ob_type = 0x60fee0, ob_size = 22, ob_item = {0x80a534030}}

'row' was allocated via PyTuple_New()
but, somehow its  refcount has become 2 while setting the 16th item!!!

Is this a known issue?  If not, what can I do to debug.

Thanks,
Pankaj

----------
messages: 163224
nosy: pxd
priority: normal
severity: normal
status: open
title: ERROR: SystemError: ./../Objects/tupleobject.c:118: bad argument to internal function
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun 20 00:18:48 2012
From: report at bugs.python.org (Ev Kontsevoy)
Date: Tue, 19 Jun 2012 22:18:48 +0000
Subject: [New-bugs-announce] [issue15109] sqlite3.Connection.iterdump() dies
	with encoding	exception
Message-ID: <1340144328.26.0.0393319745323.issue15109@psf.upfronthosting.co.za>


New submission from Ev Kontsevoy <eugueny at gmail.com>:

When calling connection.iterdump() on a database with non-ASCII string values, the following exception is raised:

----------------------------------------------------
File "/python-2.7.3/lib/python2.7/sqlite3/dump.py", line 56, in _iterdump
    yield("{0};".format(row[0]))

UnicodeEncodeError: 'ascii' codec can't encode characters in position 48-51: ordinal not in range(128)
----------------------------------------------------

The older versions used the following (safer) version in /python-2.7.3/lib/python2.7/sqlite3/dump.py:56:

yield("%s;" % row[0])

----------
components: Library (Lib)
messages: 163227
nosy: ekontsevoy
priority: normal
severity: normal
status: open
title: sqlite3.Connection.iterdump() dies with encoding exception
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 20 02:11:44 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Jun 2012 00:11:44 +0000
Subject: [New-bugs-announce] [issue15110] strange Tracebacks with importlib
Message-ID: <1340151104.06.0.0801108215149.issue15110@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Exceptions during import now display huge tracebacks across importlib._bootstrap, this adds a lot of noise to the error:

For example, I added some syntax error in distutils/spawn.py, then:

~/python/cpython3.x$ ./python -c "from distutils import ccompiler"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1335, in _handle_fromlist
  File "<frozen importlib._bootstrap>", line 1288, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1255, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 778, in load_module
  File "<frozen importlib._bootstrap>", line 759, in load_module
  File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 647, in _load_module
  File "/home/amauryfa/python/cpython3.x/Lib/distutils/ccompiler.py", line 8, in <module>
    from distutils.spawn import spawn
  File "<frozen importlib._bootstrap>", line 1288, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1255, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 432, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 778, in load_module
  File "<frozen importlib._bootstrap>", line 759, in load_module
  File "<frozen importlib._bootstrap>", line 408, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 635, in _load_module
  File "<frozen importlib._bootstrap>", line 736, in get_code
  File "/home/amauryfa/python/cpython3.x/Lib/distutils/spawn.py", line 14
    does not compile
                   ^
SyntaxError: invalid syntax

----------
components: Library (Lib)
messages: 163233
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: strange Tracebacks with importlib
type: behavior

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

From report at bugs.python.org  Wed Jun 20 02:17:26 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Jun 2012 00:17:26 +0000
Subject: [New-bugs-announce] [issue15111] Wrong ImportError message with
	importlib
Message-ID: <1340151446.59.0.121813331775.issue15111@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Up to Python3.2, a nested ImportError was correctly displayed:

./python -c "import distutils.msvc9compiler"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/amauryfa/python/cpython3.2/Lib/distutils/msvc9compiler.py", line 27, in <module>
    import winreg
ImportError: No module named winreg

But with 3.3, the traceback is lost:

~/python/cpython3.x$ ./python -c "from distutils import msvc9compiler"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name msvc9compiler

Even though the failure is still on the "import winreg" line. Only ImportError seems affected, other exceptions are correctly displayed.

----------
components: Interpreter Core
messages: 163234
nosy: amaury.forgeotdarc
priority: normal
severity: normal
status: open
title: Wrong ImportError message with importlib
type: behavior

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

From report at bugs.python.org  Wed Jun 20 06:15:47 2012
From: report at bugs.python.org (Walter Mundt)
Date: Wed, 20 Jun 2012 04:15:47 +0000
Subject: [New-bugs-announce] [issue15112] argparse: nargs='*' positional
	argument doesn't accept	any items if preceded by an option
	and another positional
Message-ID: <1340165747.87.0.563099760163.issue15112@psf.upfronthosting.co.za>


New submission from Walter Mundt <waltermundt at codethink.info>:

Test case:

    from argparse import *

    parser = ArgumentParser()
    parser.add_argument('-x', action='store_true')
    parser.add_argument('y')
    parser.add_argument('z', nargs='*')

    print parser.parse_args('yy -x zz'.split(' '))

The result of this is that the "z" option is unfilled, and the "zz" argument is unrecognized, resulting in an error.  Changing the 'nargs' to '+' works in this case, but results in errors if the 'zz' is left off.

----------
messages: 163249
nosy: waltermundt
priority: normal
severity: normal
status: open
title: argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional

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

From report at bugs.python.org  Wed Jun 20 08:03:52 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Jun 2012 06:03:52 +0000
Subject: [New-bugs-announce] [issue15113] IDLE Shell: delattr(__builtins__,
	"getattr") causes shell to stop working
Message-ID: <1340172232.21.0.850838599551.issue15113@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

delattr(__builtins__,"getattr") causes shell to stop working
if you type some code in nothing gets printed back
if you press enter without typing any code you get a traceback

Exception in thread SockThread:
Traceback (most recent call last):
  File "/usr/lib/python3.2/socketserver.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python3.2/socketserver.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.2/idlelib/rpc.py", line 503, in __init__
    socketserver.BaseRequestHandler.__init__(self, sock, addr, svr)
  File "/usr/lib/python3.2/socketserver.py", line 637, in __init__
    self.handle()
  File "/usr/lib/python3.2/idlelib/run.py", line 264, in handle
    rpc.RPCHandler.getresponse(self, myseq=None, wait=0.05)
  File "/usr/lib/python3.2/idlelib/rpc.py", line 280, in getresponse
    response = self._getresponse(myseq, wait)
  File "/usr/lib/python3.2/idlelib/rpc.py", line 300, in _getresponse
    response = self.pollresponse(myseq, wait)
  File "/usr/lib/python3.2/idlelib/rpc.py", line 438, in pollresponse
    response = self.localcall(seq, resq)
  File "/usr/lib/python3.2/idlelib/rpc.py", line 185, in localcall
    method = getattr(obj, methodname)
NameError: global name 'getattr' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.2/threading.py", line 740, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.2/threading.py", line 693, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.2/idlelib/run.py", line 135, in manage_socket
    server.handle_request() # A single request only
  File "/usr/lib/python3.2/socketserver.py", line 269, in handle_request
    self._handle_request_noblock()
  File "/usr/lib/python3.2/socketserver.py", line 286, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/lib/python3.2/idlelib/run.py", line 240, in handle_error
    print('Request: ', repr(request), file=erf)
  File "/usr/lib/python3.2/socket.py", line 111, in __repr__
    getattr(self, '_closed', False) and " [closed] " or "",
NameError: global name 'getattr' is not defined

----------
messages: 163254
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: IDLE Shell: delattr(__builtins__,"getattr") causes shell to stop working
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 20 11:42:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Jun 2012 09:42:51 +0000
Subject: [New-bugs-announce] [issue15114] Deprecate strict mode of HTMLParser
Message-ID: <1340185371.41.0.609283463083.issue15114@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

The deprecation plan for the strict mode of HTMLParser might be as follow:

3.3 (before the beta)
strict=False default
strict arg deprecated in the doc
strict=True deprecated (raises a warning)
HTMLParseError deprecated
HTMLParser.error deprecated (raises a warning)
calls to HTMLParser.error removed/converted to asserts

3.4
strict arg deprecated (raises a warning)

3.5
strict arg removed and strict code removed
HTMLParseError removed
HTMLParser.error removed


Everything that is parsed by strict=True is parsed by strict=False too, so changing the default shouldn't be a problem.  The difference is that strict=False won't raise any error and will parse broken markup too.  Given that no errors are raised HTMLParseError and HTMLParser.error become useless and can be deprecated (3.3) and removed (3.5) too.
Once strict=False is the default (3.3), the instances should be created simply with HTMLParser(), and eventually the strict argument will be deprecated (3.4) and removed (3.5).

----------
assignee: ezio.melotti
components: Library (Lib)
messages: 163265
nosy: eric.araujo, ezio.melotti, georg.brandl, r.david.murray
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Deprecate strict mode of HTMLParser
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 20 12:38:31 2012
From: report at bugs.python.org (Sergei Stolyarov)
Date: Wed, 20 Jun 2012 10:38:31 +0000
Subject: [New-bugs-announce] [issue15115] Duplicated
	Content-Transfer-Encoding header when	applying email.encoders
Message-ID: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>


New submission from Sergei Stolyarov <sergei at regolit.com>:

Here is the test script:

--------------
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email import encoders

msg = MIMEMultipart()
msg['Subject'] = 'Bug test'

text_part = MIMEText('actual content doesnt matter')
text_part.set_charset('utf-8')
msg.attach(text_part)

xml_part = MIMEText(b'<xml>aaa</xml>')
xml_part.set_type('text/xml')
xml_part.set_charset('utf-8')
encoders.encode_base64(xml_part)
msg.attach(xml_part)

print(msg.as_string())
--------------------------

It prints the following:
--------------------------
Content-Type: multipart/mixed; boundary="===============2584752675366770986=="
MIME-Version: 1.0
Subject: Bug test

--===============2584752675366770986==
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"

actual content doesnt matter
--===============2584752675366770986==
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/xml; charset="utf-8"
Content-Transfer-Encoding: base64

PHhtbD5hYWE8L3htbD4=

--===============2584752675366770986==--
--------------------------

And that's incorrect: the header "Content-Transfer-Encoding" set twice. As workaround you can use:

del xml_part['Content-Transfer-Encoding']

----------
components: email
messages: 163266
nosy: barry, cancel, r.david.murray
priority: normal
severity: normal
status: open
title: Duplicated Content-Transfer-Encoding header when applying email.encoders
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun 20 16:54:13 2012
From: report at bugs.python.org (hhas)
Date: Wed, 20 Jun 2012 14:54:13 +0000
Subject: [New-bugs-announce] [issue15116] remove out-of-date Mac application
	scripting	documentation
Message-ID: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>


New submission from hhas <hhas at users.sourceforge.net>:

1. The entire '4.6. Application Scripting' section should be deleted from the following Python 2 & 3 pages as appscript (and PyOSA) is no longer developed or supported and its use is not recommended for new projects (http://appscript.sourceforge.net/status.html):

http://docs.python.org/using/mac.html#application-scripting
http://docs.python.org/release/3.2/using/mac.html#application-scripting
http://docs.python.org/dev/using/mac.html#application-scripting


2. The sentence 'For more up-to-date implementation of AppleScript support for Python, see the third-party py-appscript project: <http://pypi.python.org/pypi/appscript/>' should be deleted from the following Python 2 page:

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

----------
assignee: docs at python
components: Documentation
messages: 163282
nosy: docs at python, hhas
priority: normal
severity: normal
status: open
title: remove out-of-date Mac application scripting documentation
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/issue15116>
_______________________________________

From report at bugs.python.org  Wed Jun 20 17:21:24 2012
From: report at bugs.python.org (wchlm)
Date: Wed, 20 Jun 2012 15:21:24 +0000
Subject: [New-bugs-announce] [issue15117] Please document top-level sqlite3
	module variables
Message-ID: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za>


New submission from wchlm <shenkin at gmail.com>:

sqlite3 top-level variables, such as version, sqlite_version, version_info, and sqlite_version_info are all useful for Python users of the module -- even essential at times. Yet there is no mention of them in the Py 2.7.3 documentation. 

dir(sqlite3) reveals a longer list. It would be good if someone with a deeper knowledge of the module could assemble a list of useful items and add them to the sqlite3 documentation.

----------
assignee: docs at python
components: Documentation
messages: 163285
nosy: docs at python, shenkin
priority: normal
severity: normal
status: open
title: Please document top-level sqlite3 module variables
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 20 22:12:41 2012
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 20 Jun 2012 20:12:41 +0000
Subject: [New-bugs-announce] [issue15118] uname &c should return a struct
	sequence instead of a	tuple
Message-ID: <1340223161.28.0.941736214162.issue15118@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

The trend in the standard library is to get rid of awkward Python-1-style tuple return values and switch to struct sequences.  (And perhaps, in the fullness of time, to deprecate the iterability of such objects.  But that's for the future.)

os.stat is a good example; it's much better to say s = os.stat() then refer to s.st_mtime than s[5] (or whatever the offset is).  And doing destructuring assignment... ptui!

I just noticed that the following functions in Modules/posixmodule.c still use BuildValue to build raw tuples:

_getdiskusage
_getfileinformation
forkpty
getloadavg
getresgid
getresuid
openpty
os2_error (can't get excited about this one)
pipe, pipe2
times
uname
wait, waitpid
wait3, wait4 (but one of the values is a struct sequence)

I think it'd be worthwhile to change all of these to struct sequences, sooner or later.

I realize we're almost out of time for 3.3, but perhaps we could hit the important ones (uname! times!) and get to the rest for 3.4?

----------
messages: 163295
nosy: larry
priority: normal
severity: normal
status: open
title: uname &c should return a struct sequence instead of a tuple

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

From report at bugs.python.org  Thu Jun 21 11:13:35 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Jun 2012 09:13:35 +0000
Subject: [New-bugs-announce] [issue15119] Bug in ctypes bitfield layout?
Message-ID: <1340270015.73.0.680065532366.issue15119@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

It looks as though there's a bug in the ctypes bitfield layout algorithm.  After:

>>> from ctypes import Structure, c_int, c_short
>>> class BITS(Structure):
...     _fields_ = [("A", c_int, 17), ("M", c_short, 1)]
... 

I get:

>>> BITS.M
<Field type=c_short, ofs=2:17, bits=1>

which doesn't make a lot of sense (17th bit of a short?)  This causes a negative shift operation when trying to access the .M field of an instance of this structure (see issue 9530 and in particular msg163303).

On this machine (OS X 10.6, 64-bit build of Python using the system gcc (4.2) with no special compiler flags), the corresponding struct in a simple C test program has size 4:

    #include <stdio.h>

    struct {
      int A : 17;
      short B: 1;
    } flags;

    int main(void) {
      printf("sizeof flags is: %ld\n", sizeof(flags));
      return 0;
    }

So it looks like everything gets packed into that first int.  At a guess, BITS.M should therefore look like <Field type=c_int, ofs=0:17, bits=1> instead.



System info:

Python 3.3.0a4+ (default:2035c5ad4239+, Jun 21 2012, 08:30:36) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

----------
components: ctypes
messages: 163315
nosy: mark.dickinson, meador.inge
priority: normal
severity: normal
status: open
title: Bug in ctypes bitfield layout?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 21 12:00:39 2012
From: report at bugs.python.org (hansokumake)
Date: Thu, 21 Jun 2012 10:00:39 +0000
Subject: [New-bugs-announce] [issue15120] Different behavior of
	html.parser.HTMLParser
Message-ID: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>


New submission from hansokumake <hansokumake at seznam.cz>:

I tried this example from the documentation:

from html.parser import HTMLParser

class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print("Encountered a start tag:", tag)
    def handle_endtag(self, tag):
        print("Encountered an end tag :", tag)
    def handle_data(self, data):
        print("Encountered some data  :", data)

parser = MyHTMLParser(strict=False)
parser.feed('<html><head><title>Test</title></head>'
            '<body><h1>Parse me!</h1></body></html>')



According to documentation the output should be like this:
Encountered a start tag: html
Encountered a start tag: head
Encountered a start tag: title
Encountered some data  : Test
Encountered an end tag : title
Encountered an end tag : head
Encountered a start tag: body
Encountered a start tag: h1
Encountered some data  : Parse me!
Encountered an end tag : h1
Encountered an end tag : body
Encountered an end tag : html

but Python produced this:
Encountered some data  : <html>
Encountered some data  : <head>
Encountered some data  : <title>
Encountered some data  : Test
Encountered an end tag : title
Encountered an end tag : head
Encountered some data  : <body>
Encountered some data  : <h1>
Encountered some data  : Parse me!
Encountered an end tag : h1
Encountered an end tag : body
Encountered an end tag : html


If strict is set to True, it works correctly.

----------
assignee: docs at python
components: Documentation
messages: 163318
nosy: docs at python, hansokumake
priority: normal
severity: normal
status: open
title: Different behavior of html.parser.HTMLParser
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 21 12:37:22 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 21 Jun 2012 10:37:22 +0000
Subject: [New-bugs-announce] [issue15121] devguide doesn't document all bug
	tracker components
Message-ID: <1340275042.61.0.991678411408.issue15121@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

http://docs.python.org/devguide/triaging.html#components

The undocumented components are:
- None
- Cross-Build
- email

----------
components: Devguide
messages: 163321
nosy: ezio.melotti, petri.lehtinen
priority: normal
severity: normal
status: open
title: devguide doesn't document all bug tracker components

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

From report at bugs.python.org  Thu Jun 21 12:45:50 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 21 Jun 2012 10:45:50 +0000
Subject: [New-bugs-announce] [issue15122] Add an option to always rewrite
	single-file mailboxes	in-place.
Message-ID: <1340275550.98.0.309231550082.issue15122@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

This seems like a common feature request. Many people suffer from the fact that upon flush, the contents of single-file mailboxes are written into a new file which is then renamed over the old file.

For example: #1599254, #5346, #7359, #7360, #9559, 

The original design rationale was probably to prepare for crashes. When changes are made like this, a power loss, other sytem crash, or even a bug in the mailbox.py code in the middle of writing the mailbox, cannot destroy all the data in the mailbox file.

We could add a flag to the constructors of all single-file mailboxes that changes this behavior to in-place rewriting. This would of course need accompanying documentation that warns about that the same safety guarantees don't apply with this flag.

----------
messages: 163322
nosy: petri.lehtinen
priority: normal
severity: normal
status: open
title: Add an option to always rewrite single-file mailboxes in-place.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 21 13:14:52 2012
From: report at bugs.python.org (=?utf-8?q?Lu=C3=ADs_Gomes?=)
Date: Thu, 21 Jun 2012 11:14:52 +0000
Subject: [New-bugs-announce] [issue15123] float().__format__() disregards
	given field width
Message-ID: <1340277292.24.0.000274542917798.issue15123@psf.upfronthosting.co.za>


Changes by Lu?s Gomes <luismsgomes at gmail.com>:


----------
nosy: luismsgomes
priority: normal
severity: normal
status: open
title: float().__format__() disregards given field width
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 21 16:11:40 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 21 Jun 2012 14:11:40 +0000
Subject: [New-bugs-announce] [issue15124] _thread.LockType: Optimize lock
	deletion, acquisition of uncontested lock and release of lock.
Message-ID: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za>


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

_thread.LockType contains code for sanity checking when the lock is released, and for unlocking it when it is deleted.  Both operations involve actually try-lock operations that are costly.  Use a flag on the log to keep track of its locking state instead.

Also, acquiring a lock now first tries a try-aqcuire without releasing the  GIL, same as _thread.RLock().  This is done by moving logic from RLock.acquire to acquire_timed() so that both locks benefit.


Improvement, on a 64 bit windows machine:
Before:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()"
1000000 loops, best of 3: 0.725 usec per loop
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
1000000 loops, best of 3: 0.315 usec per loop

After:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()"
1000000 loops, best of 3: 0.691 usec per loop
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
1000000 loops, best of 3: 0.294 usec per loop

This amounts to 5% and 7% improvement, respectively.

----------
files: lock.patch
keywords: patch
messages: 163335
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: _thread.LockType: Optimize lock deletion, acquisition of uncontested lock and release of lock.
Added file: http://bugs.python.org/file26066/lock.patch

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

From report at bugs.python.org  Thu Jun 21 17:34:07 2012
From: report at bugs.python.org (Nicu Stiurca)
Date: Thu, 21 Jun 2012 15:34:07 +0000
Subject: [New-bugs-announce] [issue15125] argparse: positional arguments
	containing - in name not	handled well
Message-ID: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>


New submission from Nicu Stiurca <supernic2002 at gmail.com>:

To reproduce, try the following code:
from argparse import ArgumentParser
a = ArgumentParser()
a.add_argument("foo-bar")
args = a.parse_args(["biz"])
print args, args.foo_bar

Expected output:
Namespace(foo_bar='biz') biz

Actual output:
Namespace(foo-bar='biz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Namespace' object has no attribute 'foo_bar'

Other comments:
The positional argument 'foo-bar' becomes impossible to retrieve without explicitly passing keyword argument dest='foo_bar'. Hyphens in positional arguments should be automatically replaced with underscores just as with other arguments.

I have not tested if this problem occurs in Python versions newer than 2.6.

----------
messages: 163340
nosy: nstiurca
priority: normal
severity: normal
status: open
title: argparse: positional arguments containing - in name not handled well
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 21 18:27:52 2012
From: report at bugs.python.org (Damian)
Date: Thu, 21 Jun 2012 16:27:52 +0000
Subject: [New-bugs-announce] [issue15126] Theading isAlive() missing version
	note
Message-ID: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za>


New submission from Damian <atagar1 at gmail.com>:

The threading module's isAlive() method had an is_alive() alias first created in python 2.6. The documentation page doesn't mention this...
http://docs.python.org/library/threading.html#threading.Thread.is_alive

However, this is noted for other methods like the Event's is_set()...
http://docs.python.org/library/threading.html#threading.Event.is_set

Very minor issue, just meant that I needed to do a bit of experimentation to figure it out.

----------
assignee: docs at python
components: Documentation
messages: 163344
nosy: atagar1, docs at python
priority: normal
severity: normal
status: open
title: Theading isAlive() missing version note
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 21 19:02:57 2012
From: report at bugs.python.org (Samuel John)
Date: Thu, 21 Jun 2012 17:02:57 +0000
Subject: [New-bugs-announce] [issue15127] Supressing warnings with -w
	"whether gcc supports	ParseTuple"
Message-ID: <1340298177.77.0.231186835152.issue15127@psf.upfronthosting.co.za>


New submission from Samuel John <python at samueljohn.de>:

In configrue.in, Python checks if the compiler supports __attribute__((format(PyArg_ParseTuple, 2, 3))) and sets the CFLAGS to "CFLAGS -Werror" to decide this test.

When you build Python with "CFLAGS=-w" (homebrew's default), configure reports 

    whether gcc supports ParseTuple ... yes

which is not supported for clang (I was told).

I know it's hard to remove a certain flag from the CFLAGS, but perhaps there should be better documentation about this issue.

----------
components: Build
messages: 163349
nosy: samueljohn
priority: normal
severity: normal
status: open
title: Supressing warnings with -w  "whether gcc supports ParseTuple"
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 21 20:01:08 2012
From: report at bugs.python.org (Kevin M. Turner)
Date: Thu, 21 Jun 2012 18:01:08 +0000
Subject: [New-bugs-announce] [issue15128] inspect raises exception when
	frames are misleading	about source line numbers
Message-ID: <1340301668.18.0.785702018205.issue15128@psf.upfronthosting.co.za>


New submission from Kevin M. Turner <acapnotic at users.sourceforge.net>:

The attached example shows how inspect.findsource fails when given a stack frame that points to a non-existent source line, and how inspect.getframeinfo and getinnerframes do not handle that failure.

On the one hand, yes, this code was asking for it by building such a broken frame.  On the other hand, having code that examines tracebacks result in tracebacks of its own sucks a whole bunch.

The inspect find&get source methods are documented as returning IOError if they cannot find the source, and the calling code handles that case, so that's probably what should happen here.

(Actually, that seems straightforward enough, I can make a patch for that shortly.)

This may help with issue #1628987 as well.

----------
components: Library (Lib)
files: inspectLineNumber.py
messages: 163355
nosy: acapnotic
priority: normal
severity: normal
status: open
title: inspect raises exception when frames are misleading about source line numbers
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26073/inspectLineNumber.py

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

From report at bugs.python.org  Thu Jun 21 22:36:28 2012
From: report at bugs.python.org (Tony Malykh)
Date: Thu, 21 Jun 2012 20:36:28 +0000
Subject: [New-bugs-announce] [issue15129] file.readline() cannot read weird
	ascii character in file
Message-ID: <1340310988.11.0.765927148859.issue15129@psf.upfronthosting.co.za>


New submission from Tony Malykh <anton.malykh at gmail.com>:

readline() or readlines() method can read the file up to the line where weird character ascii code 26 appears. I would like to read the entire file though. A simple example attached.

----------
components: IO
files: testpy.zip
messages: 163363
nosy: Tony.Malykh
priority: normal
severity: normal
status: open
title: file.readline() cannot read weird ascii character in file
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26075/testpy.zip

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

From report at bugs.python.org  Thu Jun 21 22:49:12 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 21 Jun 2012 20:49:12 +0000
Subject: [New-bugs-announce] [issue15130] remove redundant paragraph in
	socket howto
Message-ID: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

same text used on Abstract is used in the beginning of the main text

----------
assignee: docs at python
components: Documentation
files: redundancy.diff
keywords: patch
messages: 163364
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: remove redundant paragraph in socket howto
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26076/redundancy.diff

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

From report at bugs.python.org  Fri Jun 22 00:16:22 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jun 2012 22:16:22 +0000
Subject: [New-bugs-announce] [issue15131] Document py/pyw launchers
Message-ID: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

As of http://hg.python.org/cpython/rev/a7ecbb2ad967, the PEP 397 launchers are included. Their functionality should be documented.

----------
assignee: docs at python
components: Documentation, Windows
messages: 163374
nosy: brian.curtin, docs at python
priority: critical
severity: normal
stage: needs patch
status: open
title: Document py/pyw launchers
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 22 10:25:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Jun 2012 08:25:30 +0000
Subject: [New-bugs-announce] [issue15132] Let unittest.TestProgram()'s
	defaultTest argument be a	list
Message-ID: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

It would be nice if unittest.TestProgram(), aka unittest.main(), allowed one to set self.testNames by programmatically passing in a list of test names.

Currently, unittest.main() almost allows this: the constructor sets self.testNames to a 1-tuple containing the value of the defaultTest argument.  But defaultTest can only be a string, not a list of test names.

A way around this is to pass the test names explicitly via the argv argument, but this seems less elegant as a programmatic API.  Moreover, this approach isn't equivalent because test names passed via argv first get passed to a _convert_names() function.

It seems like it would be a natural and simple change to enhance unittest.TestProgram() to accept not just a name but also a list of names for the defaultTest argument.  Thanks.

----------
components: Library (Lib)
keywords: easy
messages: 163386
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: Let unittest.TestProgram()'s defaultTest argument be a list
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 22 11:27:46 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 22 Jun 2012 09:27:46 +0000
Subject: [New-bugs-announce] [issue15133] tkinter.BooleanVar.get() docstring
	is wrong
Message-ID: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Python 3.2.2 (default, Jun  4 2012, 11:15:16) 
[GCC 4.4.5] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> from tkinter import *
>>> help(BooleanVar.get)
Help on function get in module tkinter:

get(self)
    Return the value of the variable as a bool.

On my system it actually returns an int. (I wish it did return a bool though.)

----------
components: Tkinter
messages: 163387
nosy: mark
priority: normal
severity: normal
status: open
title: tkinter.BooleanVar.get() docstring is wrong
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 22 11:34:45 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 22 Jun 2012 09:34:45 +0000
Subject: [New-bugs-announce] [issue15134] urllib.request.thishost() fails on
	OSX 10.7
Message-ID: <1340357685.54.0.913486027358.issue15134@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

I just noticed that test_urllib fails for me because urllib.request.thishost() fails:


======================================================================
ERROR: test_thishost (test.test_urllib.Utility_Tests)
Test the urllib.request.thishost utility function returns a tuple
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_urllib.py", line 1155, in test_thishost
    self.assertIsInstance(urllib.request.thishost(), tuple)
  File "/Users/ronald/Projects/python/rw/default/Lib/urllib/request.py", line 2236, in thishost
    _thishost = tuple(socket.gethostbyname_ex(socket.gethostname())[2])
socket.gaierror: [Errno 8] nodename nor servname provided, or not known

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


This is because this host's hostname (Gondolin.local) is not in DNS because my mDNSReponder detected a conflict and picked a different name to advertise in the .local zone without updating the hostname.

The reason I report this anyway is that URLopener.open_local_file seems to assume that thishost() cannot fail, and the error condition on my machine could easily happen on other systems as well.

BTW. The use of this host() in URLopener.open_local_file is wrong for other reasons as well: it assumes that the local machine has exactly 1 IP address, and won't correctly detect that a file is local when the IP address is one of the other IP addresses on a multi homed system.

----------
components: Library (Lib)
messages: 163389
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: urllib.request.thishost() fails on OSX 10.7
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 22 13:13:12 2012
From: report at bugs.python.org (Pan Yongzhi)
Date: Fri, 22 Jun 2012 11:13:12 +0000
Subject: [New-bugs-announce] [issue15135] HOWTOs doesn't link to "Idioms and
	Anti-Idioms" article
Message-ID: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za>


New submission from Pan Yongzhi <fossilet at users.sourceforge.net>:

In the py3k docs howtos table of contents, http://docs.python.org/py3k/howto/index.html, the link to the article "Idioms and Anti-Idioms in Python" is gone, but the article is still in the doc. It is at http://docs.python.org/py3k/howto/doanddont.html. Should it have a link at the howtos section?

----------
assignee: docs at python
components: Documentation
messages: 163396
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: HOWTOs doesn't link to "Idioms and Anti-Idioms" article
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 22 13:51:52 2012
From: report at bugs.python.org (Jon Clements)
Date: Fri, 22 Jun 2012 11:51:52 +0000
Subject: [New-bugs-announce] [issue15136] Decimal accepting Fraction
Message-ID: <1340365912.14.0.935631231431.issue15136@psf.upfronthosting.co.za>


New submission from Jon Clements <joncle at googlemail.com>:

I'm not a numeric expert but I was looking at a post on S/O which related to converting a Fraction to a certain amount of decimal places. I've had a hunt on the tracker but couldn't find anything relevant, but if I've missed it, I apologise.

# F=Fraction, D=Decimal classes

If I try num = D( F(5, 7) )

I get: TypeError: Cannot convert Fraction(5, 7) to Decimal

So I do:

>>> D(f.numerator) / D(f.denominator)
Decimal('0.7142857142857142857142857143')

Which I think is the correct result?

I guess my question is - should Decimal do this implicitly for Fraction?

----------
components: Library (Lib)
messages: 163397
nosy: joncle
priority: normal
severity: normal
status: open
title: Decimal accepting Fraction
type: enhancement

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

From report at bugs.python.org  Fri Jun 22 16:02:28 2012
From: report at bugs.python.org (Zearin)
Date: Fri, 22 Jun 2012 14:02:28 +0000
Subject: [New-bugs-announce] [issue15137] Cleaned source of `cmd` module
Message-ID: <1340373748.03.0.660378076445.issue15137@psf.upfronthosting.co.za>


New submission from Zearin <zearin at users.sourceforge.net>:

Cleaned up the source of the Standard Library?s `cmd` module.  

Attempted to focus on readability by changing things like using booleans instead of 0/1, newer syntax for string formatting, lining up variable declarations (judgement call), and adding comments between groups of methods.

Used ace45d23628a to start my work.

----------
components: Library (Lib)
files: cmd.py
messages: 163409
nosy: zearin
priority: normal
severity: normal
status: open
title: Cleaned source of `cmd` module
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26082/cmd.py

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

From report at bugs.python.org  Fri Jun 22 17:00:00 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Jun 2012 15:00:00 +0000
Subject: [New-bugs-announce] [issue15138] base64.urlsafe_b64**code are too
	slow
Message-ID: <1340377200.19.0.907616925756.issue15138@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

This bug is still present in Python 3.3.  Some people use urlsafe strings *a lot*. And they find that the (obvious) implementation in base64.py is way too slow.  In fact, I found myself writing the following a few times in App Engine libraries:

    # This is 3-4x faster than urlsafe_b64decode()                   
    urlsafe = base64.b64encode(<arg>)
    return urlsafe.rstrip('=').replace('+', '-').replace('/', '_')

Someone from YouTube told me they patch the stdlib for the same reason (they claim their solution is 10x faster).

IIUC the cause of the slowness is the (mostly irrelevant) generality in b64encode and the _translate() function.

----------
components: Library (Lib)
keywords: easy
messages: 163420
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: base64.urlsafe_b64**code are too slow
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jun 22 17:38:32 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 22 Jun 2012 15:38:32 +0000
Subject: [New-bugs-announce] [issue15139] Speed up threading.Condition wakeup
Message-ID: <1340379512.47.0.965576630558.issue15139@psf.upfronthosting.co.za>


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

This patch is based on work previously done locally in python 2.7, see http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/

The idea is to acquire the signaling Lock() of the threading.Condition object _and_ the outer lock, without releasing and re-aquiring the GIL in between that is, as an atomic operation from the program's point of view.

_thread.LockType objects, used by the Condition object, now have an _acquire_condition method which knows how to do it for LockType and RLock objects.

Both lock types grow _release_save and _acquire_restore methods, the latter of which is a no-op.

_acquire_coindition() will ignore any other kinds of locks, including subclasses (if such things exist).

The result of this is a very marked improvement in signaling time on a contested machine.  A file, queuetest.py is provided which measures the wakeup delay.

Typical before the change:
best:    totaltime: 0.167006, avg delay: 0.004766, delay_stddev: 0.002058
typical: totaltime: 0.154271, avg delay: 0.027621, delay_stddev: 0.007479

after the change
typical: totaltime: 0.169217, avg delay: 0.001410, delay_stddev: 0.000722

----------
components: Interpreter Core, Library (Lib)
files: condition.patch
keywords: patch
messages: 163423
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Speed up threading.Condition wakeup
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file26085/condition.patch

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

From report at bugs.python.org  Fri Jun 22 20:11:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jun 2012 18:11:27 +0000
Subject: [New-bugs-announce] [issue15140] PEP 384 inconsistent with
	implementation
Message-ID: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za>


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

In PEP 384, the PyType_Spec struct has a "const char *doc" that is not present in the implementation (Include/object.h).

----------
assignee: docs at python
components: Documentation
messages: 163449
nosy: docs at python, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 384 inconsistent with implementation
type: behavior

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

From report at bugs.python.org  Fri Jun 22 20:36:55 2012
From: report at bugs.python.org (Pat)
Date: Fri, 22 Jun 2012 18:36:55 +0000
Subject: [New-bugs-announce] [issue15141] IDLE horizontal scroll bar missing
	(Win-XPsp3)
Message-ID: <1340390215.85.0.455282030507.issue15141@psf.upfronthosting.co.za>


New submission from Pat <pasqualejr at ymail.com>:

There is no horizontal scroll bar at the bottom of the IDLE editor window.
When a program line exceeds the window area, the window has to be widened, or text has to be manually selected beyond the window to see or edit that portion of the line.
No major problem, just a minor inconvenience.
Even with this bug, IDLE is still a great editor.
Thank you.
Pat

----------
components: IDLE
messages: 163452
nosy: NyteHawk
priority: normal
severity: normal
status: open
title: IDLE horizontal scroll bar missing (Win-XPsp3)
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 22 21:56:07 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jun 2012 19:56:07 +0000
Subject: [New-bugs-announce] [issue15142] Fix reference leak with types
	created using	PyType_FromSpec
Message-ID: <1340394967.19.0.943084432103.issue15142@psf.upfronthosting.co.za>


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

The following patch seems to fix the issue explained in http://mail.python.org/pipermail/python-dev/2012-June/120659.html :


diff --git a/Objects/typeobject.c b/Objects/typeobject.c
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -2417,6 +2417,10 @@ PyType_FromSpec(PyType_Spec *spec)
     if (res->ht_type.tp_dictoffset) {
         res->ht_cached_keys = _PyDict_NewKeysForClass();
     }
+    if (res->ht_type.tp_dealloc == NULL) {
+        /* It's a heap type, so needs the heap types' dealloc */
+        res->ht_type.tp_dealloc = subtype_dealloc;
+    }
 
     if (PyType_Ready(&res->ht_type) < 0)
         goto fail;

----------
components: Interpreter Core
messages: 163470
nosy: loewis, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Fix reference leak with types created using PyType_FromSpec
type: resource usage
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun 22 21:58:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jun 2012 19:58:21 +0000
Subject: [New-bugs-announce] [issue15143] Windows compile errors
Message-ID: <1340395101.67.0.466421051649.issue15143@psf.upfronthosting.co.za>


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

The Windows buildbot are broken, they don't compile anymore. The errors seem to be:

[...]
ResourceCompile:
  C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /l"0x0409" /I..\PC /I..\Include /nologo /fo"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\Win32-temp-Debug\pylauncher\pylauncher.res" ..\PC\pylauncher.rc 
..\PC\pylauncher.rc(9): fatal error RC1015: cannot open include file 'pythonnt_rc.h'. [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\pylauncher.vcxproj]

[...]  
ResourceCompile:
  C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /D _UNICODE /D UNICODE /l"0x0409" /I..\PC /I..\Include /nologo /fo"d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\Win32-temp-Debug\pywlauncher\pylauncher.res" ..\PC\pylauncher.rc 
..\PC\pylauncher.rc(9): fatal error RC1015: cannot open include file 'pythonnt_rc.h'. [d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\pywlauncher.vcxproj]

(see e.g. http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6892/steps/compile/logs/stdio )

----------
components: Windows
messages: 163471
nosy: georg.brandl, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: Windows compile errors
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 22 22:02:48 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jun 2012 20:02:48 +0000
Subject: [New-bugs-announce] [issue15144] Possible integer overflow in
	operations with addresses	and sizes.
Message-ID: <1340395368.97.0.504662983992.issue15144@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

In unicodeobject.c and stringlib aligned addresses and sizes are used for optimization. pointer->integer and implicit integer->integer conversions may overflow or underflow on platforms with sizeof(size_t) != sizeof(void *) or sizeof(size_t) != sizeof(int). The proposed patch fixes such unsafe things in unicodeobject.c, stringlib and some other files.

There are still a few unsafe places in libffi, but in this library Py_uintptr_t nor uintptr_t are not available.

----------
components: Interpreter Core
files: align_operations.patch
keywords: patch
messages: 163473
nosy: storchaka
priority: normal
severity: normal
status: open
title: Possible integer overflow in operations with addresses and sizes.
type: security
versions: Python 3.3
Added file: http://bugs.python.org/file26091/align_operations.patch

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

From report at bugs.python.org  Fri Jun 22 22:51:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Jun 2012 20:51:58 +0000
Subject: [New-bugs-announce] [issue15145] Faster *_find_max_char
Message-ID: <1340398318.47.0.89388206382.issue15145@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Here is patch that speed up *_find_max_char stringlib functions.

Microbenchmarks:

./python -m timeit -s "s='A'*20+'\x80'" "s[:-1]"
./python -m timeit -s "s='A'*20+'\U00010000'" "s[:-1]"

Results on Intel Atom N570 @ 1.66GHz:

vanilla  patched

 0.819    0.73
 0.788    0.755

----------
components: Interpreter Core
files: find_max_char.patch
keywords: patch
messages: 163480
nosy: storchaka
priority: normal
severity: normal
status: open
title: Faster *_find_max_char
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file26093/find_max_char.patch

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

From report at bugs.python.org  Sat Jun 23 00:34:41 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Fri, 22 Jun 2012 22:34:41 +0000
Subject: [New-bugs-announce] [issue15146] Implemented
	PyType_FromSpecWithBases
Message-ID: <1340404481.13.0.60159663995.issue15146@psf.upfronthosting.co.za>


New submission from Robin Schreiber <robin.schreiber at me.com>:

Enhancement to the currently existing PyType_FromSpec() which creates and returns a heap type from a given spec. PyType_FromSpecWithBases() works similar to PyType_FromSpec(), however it sets the bases of the newly created heap type to the types contained inside the passed bases-tuple.
This allows the programmer to reference other heap-types as base types of  a new heap type. This is necessary as the slot-API, which is used for static declarations of the type-spec, currently relies on statically declared type objects as tp_base or tp_bases entries.

----------
components: Interpreter Core
files: PyType_FromSpecWithBases.patch
keywords: patch
messages: 163502
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: Implemented PyType_FromSpecWithBases
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26099/PyType_FromSpecWithBases.patch

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

From report at bugs.python.org  Sat Jun 23 01:58:09 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jun 2012 23:58:09 +0000
Subject: [New-bugs-announce] [issue15147] Remove packaging from the stdlib
Message-ID: <1340409489.91.0.102859663779.issue15147@psf.upfronthosting.co.za>


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

Eric, this is for you. If you do only one thing before the 3.3 beta, please do this.

----------
assignee: eric.araujo
components: Library (Lib)
messages: 163504
nosy: eric.araujo, georg.brandl, pitrou
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Remove packaging from the stdlib
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 03:16:29 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 01:16:29 +0000
Subject: [New-bugs-announce] [issue15148] shutul.which() docstring could be
	clearer
Message-ID: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I find this a little hard to parse (ignoring the obvious typo and the grammar error):

"""
Given a file, mode, and a path string, return the path whichs conform to the given mode on the path.
"""

One other suggestion: wouldn't 'file' read better as 'command'?

----------
assignee: docs at python
components: Documentation
messages: 163515
nosy: docs at python, hynek, tarek, tshepang
priority: normal
severity: normal
status: open
title: shutul.which() docstring could be clearer

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

From report at bugs.python.org  Sat Jun 23 04:30:13 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 02:30:13 +0000
Subject: [New-bugs-announce] [issue15149] Release Schedule needs updating
Message-ID: <1340418613.19.0.188267492101.issue15149@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I see some stuff marked 'planned' has been rejected for 3.3, while some has already been implemented.

----------
assignee: docs at python
components: Documentation
messages: 163521
nosy: anthonybaxter, barry, benjamin.peterson, docs at python, eric.araujo, georg.brandl, gvanrossum, lemburg, loewis, ned.deily, tarek, tshepang
priority: normal
severity: normal
status: open
title: Release Schedule needs updating
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 04:33:29 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jun 2012 02:33:29 +0000
Subject: [New-bugs-announce] [issue15150] Windows build does not link
Message-ID: <1340418809.0.0.92215340871.issue15150@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

6>python3.def : error LNK2001: unresolved external symbol PyState_AddModule
6>python3.def : error LNK2001: unresolved external symbol PyState_RemoveModule
6>C:\python-dev\cpython\PCbuild\python3.lib : fatal error LNK1120: 2 unresolved externals

----------
components: Build, Windows
messages: 163522
nosy: brian.curtin
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Windows build does not link
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 08:13:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Jun 2012 06:13:50 +0000
Subject: [New-bugs-announce] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
Message-ID: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The PEP 362 implementation has been committed, but the inspect module documentation still needs to be updated.

----------
assignee: docs at python
components: Documentation
messages: 163534
nosy: docs at python, ncoghlan
priority: deferred blocker
severity: normal
status: open
title: Documentation for Signature, Parameter and signature in inspect module
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 11:07:22 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Jun 2012 09:07:22 +0000
Subject: [New-bugs-announce] [issue15152] test_subprocess fqailures on
	awfully slow builtbots
Message-ID: <1340442442.66.0.972780604979.issue15152@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali <neologix at free.fr>:

Some test_subprocess tests are failing on really slow buildbots, such as the Ubtuntu ARM one:
"""
======================================================================
ERROR: test_wait_timeout (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 718, in test_wait_timeout
    self.assertEqual(p.wait(timeout=3), 0)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/subprocess.py", line 1494, in wait
    raise TimeoutExpired(self.args, timeout)
subprocess.TimeoutExpired: Command '['/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/python', '-c', 'import time; time.sleep(0.1)']' timed out after 3 seconds

======================================================================
FAIL: test_check_output_timeout (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 140, in test_check_output_timeout
    self.assertEqual(c.exception.output, b'BDFL')
AssertionError: b'' != b'BDFL'

======================================================================
FAIL: test_check_output_timeout (test.test_subprocess.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-arm/build/Lib/test/test_subprocess.py", line 140, in test_check_output_timeout
    self.assertEqual(c.exception.output, b'BDFL')
AssertionError: b'' != b'BDFL'
"""

The timeouts for those tests are already at 3 seconds.
We could double them to 6 seconds and see if things get better: that would increase the running time on all the buildbots, though. Any other idea?

----------
components: Tests
keywords: buildbot
messages: 163557
nosy: neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_subprocess fqailures on awfully slow builtbots
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 11:19:50 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Jun 2012 09:19:50 +0000
Subject: [New-bugs-announce] [issue15153] Add inspect.getgeneratorlocals
Message-ID: <1340443190.33.0.807153251972.issue15153@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Extracted from #13062, the proposal is add a simple API to inspect the local variables of a generator with an associated frame.

----------
components: Library (Lib)
messages: 163560
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add inspect.getgeneratorlocals
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 23 19:15:11 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jun 2012 17:15:11 +0000
Subject: [New-bugs-announce] [issue15154] remove "rmdir" argument from
	os.unlink, add "dir_fd" to os.rmdir
Message-ID: <1340471711.17.0.728294485033.issue15154@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

As Antoine noted in #14626, the "rmdir" argument to os.unlink doesn't really make sense since we already deviate from just mapping posix functionality one-on-one.

Attached is a patch removing "rmdir" from os.unlink, and instead adding "dir_fd" to os.rmdir.

----------
assignee: larry
files: move-dirfd-to-rmdir.patch
keywords: patch
messages: 163647
nosy: georg.brandl, larry, pitrou
priority: critical
severity: normal
stage: patch review
status: open
title: remove "rmdir" argument from os.unlink, add "dir_fd" to os.rmdir
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26111/move-dirfd-to-rmdir.patch

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

From report at bugs.python.org  Sun Jun 24 01:21:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jun 2012 23:21:44 +0000
Subject: [New-bugs-announce] [issue15155] sporadic failure in
	RecvmsgSCTPStreamTest
Message-ID: <1340493704.97.0.818384658063.issue15155@psf.upfronthosting.co.za>


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

Sometimes seen on buildbots (e.g. http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/309/steps/test/logs/stdio ). It seems it's always testRecvmsgEOF which fails.


$ ./python -m test -m RecvmsgSCTPStreamTest -unetwork -Fv test_socket

[...]

[ 36] test_socket
testRecvmsg (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgAfterClose (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgBadArgs (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest) ... ERROR
testRecvmsgExplicitDefaults (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgFromSendmsg (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgLongAncillaryBuf (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgOverflow (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgPeek (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgShortAncillaryBuf (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgShorter (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgTimeout (test.test_socket.RecvmsgSCTPStreamTest) ... ok
testRecvmsgTrunc (test.test_socket.RecvmsgSCTPStreamTest) ... ok

======================================================================
ERROR: testRecvmsgEOF (test.test_socket.RecvmsgSCTPStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_socket.py", line 2192, in testRecvmsgEOF
    msg, ancdata, flags, addr = self.doRecvmsg(self.serv_sock, 1024)
  File "/home/antoine/cpython/default/Lib/test/test_socket.py", line 1683, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
OSError: [Errno 107] Transport endpoint is not connected

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

----------
components: Library (Lib), Tests
messages: 163693
nosy: giampaolo.rodola, neologix, pitrou
priority: normal
severity: normal
status: open
title: sporadic failure in RecvmsgSCTPStreamTest
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 04:45:43 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Jun 2012 02:45:43 +0000
Subject: [New-bugs-announce] [issue15156] Refactor HTMLParser.unescape to
	use html.entities.html5
Message-ID: <1340505943.38.0.45190182563.issue15156@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

HTMLParser has an internal method called unescape [0] used to convert named character references to the equivalent characters, and it does so by using html.entities.name2codepoint to recreate the equivalent of html.entities.entityrefs with the addition of &apos;.
Now that the html5 entities have been added to html.entities, the parser should use them instead of name2codepoint.

[0]: see Lib/html/parser.py:500

----------
assignee: ezio.melotti
components: Library (Lib)
messages: 163702
nosy: eric.araujo, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Refactor HTMLParser.unescape to use html.entities.html5
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 04:47:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jun 2012 02:47:23 +0000
Subject: [New-bugs-announce] [issue15157] venvs should include pydoc
Message-ID: <1340506043.04.0.340918087163.issue15157@psf.upfronthosting.co.za>


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

To get documentation about a module installed in a venv, one needs to use ?python -m pydoc? instead of just ?pydoc?; I would like a pydoc script with the appropriate shebang to be installed in the venv?s bin dir.

Similar request in virtualenv for the reference: https://github.com/pypa/virtualenv/issues/149

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 163703
nosy: carljm, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: venvs should include pydoc
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 05:47:25 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 24 Jun 2012 03:47:25 +0000
Subject: [New-bugs-announce] [issue15158] Add support for multi-character
	delimiters in csv
Message-ID: <1340509645.86.0.375714044709.issue15158@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

It would be nice if csv supported multi-character delimiters.
I need it for my project.
 Another person had this problem: http://stackoverflow.com/questions/6352409/how-to-use-python-csv-module-for-splitting-double-pipe-delimited-data .

----------
components: Library (Lib)
messages: 163708
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: Add support for multi-character delimiters in csv
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jun 24 07:06:12 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 24 Jun 2012 05:06:12 +0000
Subject: [New-bugs-announce] [issue15159] Add failover for follow_symlinks
	and effective_ids where	possible
Message-ID: <1340514372.7.0.0626020739455.issue15159@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Serhiy Storchaka suggested (in private email, not on tracker or python-dev): why not make follow_symlinks and effective_ids failover where possible?

Let's take the example of effective_ids first, that's simpler.  Let's say the user calls
  os.access("x", os.F_OK, effective_ids=True)
But they doesn't have faccessat() for some reason.  IF euid==uid, and egid==gid, then it's harmless to ignore the effective_ids flag and just use normal access().

Supporting this is easy: if effective_ids=True, and !defined(HAVE_FACCESSAT), but we have all four of the get{e|}{u|g}id() functions, do the above comparison and if it is just call access().

It's a bit more complicated with follow_symlinks.  Let's say they call
  os.chmod("x", 0o644, follow_symlinks=False)
As it happens, they're on Linux so they don't have lchmod() and their fchmodat() doesn't support AT_SYMLINK_NOFOLLOW.  But!  "x" isn't a symbolic link!  In this case normal chmod would be fine fine.

How do we detect that the file is a symbolic link?  That's easy, call lstat().  On Windows, if they gave us a wide path, call win32_lstat_w().  If they passed in a non-default dir_fd, call fstatat() (if available).

The one place where we can't fail over gracefully: os.stat()  If we don't have the appropriate native stat function (lstat or fstatat), then obviously we can't stat nofollow the file to see if it's not a symbolic link and call normal stat().  Sad face.

The attached patch implements all of the above.  It passes the regression test suite on Linux 64-bit (with and without pydebug) and Windows 32-bit (Debug and Release).

----------
assignee: larry
files: larry.kinder.gentler.follow_symlinks.1.diff
keywords: patch
messages: 163713
nosy: georg.brandl, larry, pitrou, storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add failover for follow_symlinks and effective_ids where possible
type: behavior
Added file: http://bugs.python.org/file26122/larry.kinder.gentler.follow_symlinks.1.diff

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

From report at bugs.python.org  Sun Jun 24 10:53:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Jun 2012 08:53:08 +0000
Subject: [New-bugs-announce] [issue15160] Add support for MIME header
	parsing to the new	provisional email policies
Message-ID: <1340527988.81.0.399006538534.issue15160@psf.upfronthosting.co.za>


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

I've been working on this steadily for a while.  I think it is now all working correctly.  At least, it passes all the same tests that the existing RFC mime header parser passes, plus a bunch of additional ones.

There are a couple of commented out tests where there are issues with the folding.  The folding doesn't normally get invoked for headers parsed from source, and the cases are marginal anyway (headers with invalid binary data) so I'm not worried about them, but will fix them after the beta.

There are things that can be done to make this API even more convenient, but I think this is a solid foundation worth having.  And the parser is a full RFC parser, so it handles cases that the current parser doesn't.  (There are also probably cases where it fails when the current parser doesn't, but I haven't found them yet ;)

----------
components: email
files: mime_parsing.patch
keywords: patch
messages: 163751
nosy: barry, georg.brandl, r.david.murray
priority: normal
severity: normal
stage: commit review
status: open
title: Add support for MIME header parsing to the new provisional email policies
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26126/mime_parsing.patch

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

From report at bugs.python.org  Sun Jun 24 12:31:24 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Jun 2012 10:31:24 +0000
Subject: [New-bugs-announce] [issue15161] add new-style os API to two
	missing functions
Message-ID: <1340533884.88.0.13348326144.issue15161@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

For pathconf() / fpathconf() and truncate() / ftruncate() the former didn't support fds as path.  These two patches should fix it.

----------
assignee: larry
components: Extension Modules
files: pathconf.diff
keywords: patch
messages: 163760
nosy: georg.brandl, larry
priority: critical
severity: normal
status: open
title: add new-style os API to two missing functions
versions: Python 3.3
Added file: http://bugs.python.org/file26127/pathconf.diff

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

From report at bugs.python.org  Sun Jun 24 14:24:39 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 24 Jun 2012 12:24:39 +0000
Subject: [New-bugs-announce] [issue15162] help() says "This is the online
	help utility." even	though it isn't
Message-ID: <1340540679.64.0.68125783941.issue15162@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

help() says "This is the online help utility." even though it isn't.
I think this sentence should be hanged to "This is the offline help utility."

----------
components: Library (Lib)
messages: 163782
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: help() says "This is the online help utility." even though it isn't
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/issue15162>
_______________________________________

From report at bugs.python.org  Sun Jun 24 16:09:50 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Jun 2012 14:09:50 +0000
Subject: [New-bugs-announce] [issue15163] pydoc displays __loader__ as
	module data
Message-ID: <1340546990.34.0.0743968242792.issue15163@psf.upfronthosting.co.za>


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

Everything's in the title. __loader__ probably needs to be blacklisted.

----------
components: Library (Lib)
messages: 163788
nosy: brett.cannon, eric.snow, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: pydoc displays __loader__ as module data
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 19:32:50 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Jun 2012 17:32:50 +0000
Subject: [New-bugs-announce] [issue15164] add platform.uname() namedtuple
	interface?
Message-ID: <1340559170.31.0.985080804132.issue15164@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Followup to #15118.

See rev 75b818d7c50d -- the patch converted a usage of platform.uname(), which errored out on Mac.

Since os.uname() is supposed to be the "low-level" interface, it suggests that platform.uname() should also return an attribute-rich object; in this case probably a namedtuple.

----------
assignee: larry
components: Library (Lib)
messages: 163810
nosy: georg.brandl, larry
priority: deferred blocker
severity: normal
status: open
title: add platform.uname() namedtuple interface?
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 21:43:57 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jun 2012 19:43:57 +0000
Subject: [New-bugs-announce] [issue15165] test_email: failure on Windows
	64-bit
Message-ID: <1340567037.81.0.496566862614.issue15165@psf.upfronthosting.co.za>


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

I'm getting this failure in test_email (Windows 64-bit build):

======================================================================                                               
ERROR: test_localtime_epoch_notz_daylight_false (test_utils.LocaltimeTests)                                          
----------------------------------------------------------------------                                               
Traceback (most recent call last):                                                                                   
  File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 112, in test_localtime_epoch_notz_dayl
ight_false                                                                                                           
    t1 = utils.localtime(t0)                                                                                         
  File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime                                    
    seconds = time.mktime(tm)                                                                                        
OverflowError: mktime argument out of range                                                                          
                                                                                                                     
======================================================================                                               
ERROR: test_localtime_epoch_notz_daylight_true (test_utils.LocaltimeTests)                                           
----------------------------------------------------------------------                                               
Traceback (most recent call last):                                                                                   
  File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 105, in test_localtime_epoch_notz_dayl
ight_true                                                                                                            
    t1 = utils.localtime(t0)                                                                                         
  File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime                                    
    seconds = time.mktime(tm)                                                                                        
OverflowError: mktime argument out of range

----------
components: Tests
keywords: buildbot
messages: 163827
nosy: r.david.murray, skrah
priority: normal
severity: normal
status: open
title: test_email: failure on Windows 64-bit
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 21:50:12 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Jun 2012 19:50:12 +0000
Subject: [New-bugs-announce] [issue15166] Implement imp.get_tag() using
	sys.implementation
Message-ID: <1340567412.76.0.552732396402.issue15166@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Title says it all. This also implies updating importlib to use sys.implementation directly.

----------
components: Library (Lib)
keywords: easy
messages: 163829
nosy: brett.cannon, eric.snow
priority: deferred blocker
severity: normal
stage: needs patch
status: open
title: Implement imp.get_tag() using sys.implementation
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 21:51:26 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Jun 2012 19:51:26 +0000
Subject: [New-bugs-announce] [issue15167] Re-implement imp.get_magic() in
	pure Python
Message-ID: <1340567486.25.0.718240162307.issue15167@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Title says it all. Issue #13959 has a patch.

----------
messages: 163830
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: Re-implement imp.get_magic() in pure Python

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

From report at bugs.python.org  Sun Jun 24 21:55:30 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Jun 2012 19:55:30 +0000
Subject: [New-bugs-announce] [issue15168] Move importlib.test to
	test.importlib
Message-ID: <1340567730.83.0.639842949641.issue15168@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Should also update to use unittest discovery. Might also need to update tests to use both _frozen_importlib and importlib._bootstrap.

----------
messages: 163833
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Move importlib.test to test.importlib

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

From report at bugs.python.org  Sun Jun 24 21:59:16 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Jun 2012 19:59:16 +0000
Subject: [New-bugs-announce] [issue15169] Clear C code under
	PyImport_ExecCodeModuleObject()
Message-ID: <1340567956.17.0.18413889062.issue15169@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

import.c:PyImport_ExecCodeModuleObject() is holding on to a ton of C code thanks to get_sourcefile(). Should have PyImport_ExecCodeModuleWithPathnames() use get_sourcefile() only. And then get_sourcefile() should get re-implemented in Python code.

----------
components: Interpreter Core
messages: 163834
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Clear C code under PyImport_ExecCodeModuleObject()
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 22:28:54 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jun 2012 20:28:54 +0000
Subject: [New-bugs-announce] [issue15170] Fix 64-bit building for buildbot
	scripts (2.7)
Message-ID: <1340569734.61.0.00630889671182.issue15170@psf.upfronthosting.co.za>


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

[from #15102]

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7

----------
components: Build
messages: 163847
nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, python-dev, skrah, zach.ware
priority: normal
severity: normal
status: open
title: Fix 64-bit building for buildbot scripts (2.7)
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun 24 22:30:08 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jun 2012 20:30:08 +0000
Subject: [New-bugs-announce] [issue15171] Fix 64-bit building for buildbot
	scripts (3.2)
Message-ID: <1340569808.6.0.680025468258.issue15171@psf.upfronthosting.co.za>


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

[from #15102]
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.2

----------
messages: 163848
nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, skrah, zach.ware
priority: normal
severity: normal
status: open
title: Fix 64-bit building for buildbot scripts (3.2)

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

From report at bugs.python.org  Sun Jun 24 22:32:27 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jun 2012 20:32:27 +0000
Subject: [New-bugs-announce] [issue15172] SHA1 failures on the 64-bit
	Windows buildbot
Message-ID: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za>


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

[Antoine]
Ouch. The test failures on the buildbot now seem to point to problems with OpenSSL's SHA1 implementation.

Jeremy, perhaps you can try to run the OpenSSL self-tests?

----------
components: Tests
keywords: buildbot
messages: 163849
nosy: brian.curtin, jeremy.kloth, jkloth, loewis, pitrou, skrah, zach.ware
priority: normal
severity: normal
status: open
title: SHA1 failures on the 64-bit Windows buildbot
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Jun 24 22:32:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Jun 2012 20:32:39 +0000
Subject: [New-bugs-announce] [issue15173] Copyright/licensing statement in
	new venv module
Message-ID: <1340569959.64.0.251231198721.issue15173@psf.upfronthosting.co.za>


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

While reading the venv source I noticed a typo in the copyright/license line (?20011?); I propose a patch that removes that line in favor of the customary ?Licensed to the PSF? line, which is IMO much clearer (I never understand what the combination of ?all rights reserved? and a free software license means).  I have added a comment to preserve the mention of your authorship (as well as a reference to virtualenv?s authors, which sounds fair to me?but maybe it?s good enough that the PEP mention them).  I do hope this does not seem disrespectful to you; I really appreciate your work and don?t wish to diminish your merit, but I think the notice is strange and should be fixed.

Another minor edit in the diff is the removal of an obsolete mention of pythonv; could be another commit if you prefer.

----------
assignee: vinay.sajip
components: Library (Lib)
files: venv-licensing.diff
keywords: patch
messages: 163850
nosy: eric.araujo, vinay.sajip
priority: normal
severity: normal
stage: commit review
status: open
title: Copyright/licensing statement in new venv module
versions: Python 3.3
Added file: http://bugs.python.org/file26135/venv-licensing.diff

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

From report at bugs.python.org  Mon Jun 25 00:34:13 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Jun 2012 22:34:13 +0000
Subject: [New-bugs-announce] [issue15174] amd64\python_d.exe -m test fails
Message-ID: <1340577253.64.0.707739710326.issue15174@psf.upfronthosting.co.za>


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

I'm quite sure this worked before, but fails now:

C:\Users\stefan\pydev\cpython\PCbuild>amd64\python_d.exe -m test test_ssl                                       
Traceback (most recent call last):                                                                              
  File "C:\Users\stefan\pydev\cpython\lib\runpy.py", line 162, in _run_module_as_main                           
    "__main__", fname, loader, pkg_name)                                                                        
  File "C:\Users\stefan\pydev\cpython\lib\runpy.py", line 75, in _run_code                                      
    exec(code, run_globals)                                                                                     
  File "C:\Users\stefan\pydev\cpython\lib\test\__main__.py", line 1, in <module>                                
    from test import regrtest, support                                                                          
ImportError: cannot import name regrtest                                                                        
[84466 refs]                              


Calling *from* the amd64 directory is OK:

C:\Users\stefan\pydev\cpython\PCbuild\amd64>python_d.exe -m test test_ssl                                       
[1/1] test_ssl                                                                                                  
1 test OK.                                                                                                      
[155820 refs]

----------
components: Tests
messages: 163871
nosy: pitrou, skrah
priority: normal
severity: normal
status: open
title: amd64\python_d.exe -m test fails
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 25 01:44:48 2012
From: report at bugs.python.org (Shanker)
Date: Sun, 24 Jun 2012 23:44:48 +0000
Subject: [New-bugs-announce] [issue15175] pydoc -k zip throws segmentation
	fault
Message-ID: <1340581488.74.0.233169752541.issue15175@psf.upfronthosting.co.za>


New submission from Shanker <shank76 at gmail.com>:

user at test:~/learn/python$ pydoc -k zip
zipimport - zipimport provides support for importing Python modules from Zip archives.
gzip - Functions that read and write gzipped files.
lib2to3.fixes.fix_itertools - Fixer for itertools.(imap|ifilter|izip) --> (map|filter|zip) and
lib2to3.fixes.fix_itertools_imports - Fixer for imports of itertools.(imap|ifilter|izip|ifilterfalse)
lib2to3.fixes.fix_zip - Fixer that changes zip(seq0, seq1, ...) into list(zip(seq0, seq1, ...)
zipfile - Read and write ZIP files.

** (python2.7:2599): CRITICAL **: pyg_register_boxed: assertion `boxed_type != 0' failed
Segmentation fault (core dumped)
user at test:~/learn/python$ 

user at test:~/learn/python$ uname -a
Linux govinda 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
user at test:~/learn/python$

----------
components: None
messages: 163875
nosy: shank
priority: normal
severity: normal
status: open
title: pydoc -k zip throws segmentation fault
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 25 05:39:58 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Jun 2012 03:39:58 +0000
Subject: [New-bugs-announce] [issue15176] Clarify the behavior of
	listdir(fd) in both code and	documentation
Message-ID: <1340595598.31.0.249788206145.issue15176@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

When you pass in a file descriptor as the first argument to listdir, its output is a list of strings, not a list of bytes.  This should be mentioned in the documentation.  It's also worth making a pass over the other functions accepting an fd.

As it happens, the code that implements this behavior is obtuse.  So I propose also modifying it to be more intelligible.

----------
assignee: larry
messages: 163885
nosy: georg.brandl, larry, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify the behavior of listdir(fd) in both code and documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 25 06:13:22 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Jun 2012 04:13:22 +0000
Subject: [New-bugs-announce] [issue15177] Support os.walk(dir_fd=) and
	os.fwalk(dir_fd=)
Message-ID: <1340597602.46.0.0876148548933.issue15177@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Consider: should os.fwalk() support dir_fd?  I think so.  In fact, in retrospect it seems like a bug that os.fwalk *doesn't* already support this.

Georg: is this a feature or a bugfix?

(Wish I'd thought of this Saturday!)

I actually did a little experimenting, and got os.fwalk(fd) to work with very little trouble.  os.walk(fd) is harder because the recursive step appends a string to the existing path, and it really needs to be relative to the fd, and there's no way to pass both of those at once with the current signature.  It's doable but it would require a separate function for the recursive step that accepted a dir_fd anyway.

----------
assignee: larry
messages: 163886
nosy: georg.brandl, hynek, larry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Support os.walk(dir_fd=) and os.fwalk(dir_fd=)
type: behavior

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

From report at bugs.python.org  Mon Jun 25 13:01:45 2012
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Mon, 25 Jun 2012 11:01:45 +0000
Subject: [New-bugs-announce] [issue15178] Doctest should handle situations
	when test files are not	readable
Message-ID: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>:

Hi,
I think that doctest should be able to handle situations when the file that is being tested does not exist/is unreadable/etc...
Currently, doctest raises an IOError exception and the whole Python ends with an exception and backtrace.
I'm attaching a patch that fixes this and prints a simple description of what has gone wrong.

Thanks for considering!

----------
components: Library (Lib)
files: doctest-dont-end-with-exception-on-unreadable-files.patch
keywords: patch
messages: 163936
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Doctest should handle situations when test files are not readable
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26153/doctest-dont-end-with-exception-on-unreadable-files.patch

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

From report at bugs.python.org  Mon Jun 25 13:29:31 2012
From: report at bugs.python.org (Kazutaka Morita)
Date: Mon, 25 Jun 2012 11:29:31 +0000
Subject: [New-bugs-announce] [issue15179] An infinite loop happens when we
	use SysLogHandler with	eventlet
Message-ID: <1340623771.92.0.68954184969.issue15179@psf.upfronthosting.co.za>


New submission from Kazutaka Morita <morita.kazutaka at gmail.com>:

If we stop a syslog daemon when running the following program, it
leads to an infinite loop.

==
#!/usr/bin/env python

import eventlet
from logging.handlers import SysLogHandler
import time
import logging

eventlet.patcher.monkey_patch(all=False, socket=True)

logger = logging.getLogger('log')
logger.addHandler(SysLogHandler('/dev/log'))

while True:
    print "send a message to logger"
    logger.error("syslog test")
    time.sleep(1)
==

It is because there is a close leak in the python logging module, and
SysLogHandler continues to send a log message against the closed
connection forever.

The following patch seems to fix this problem:

diff -r 3b5545ba6432 Lib/logging/handlers.py
--- a/Lib/logging/handlers.py	Wed Jun 13 22:15:26 2012 -0400
+++ b/Lib/logging/handlers.py	Mon Jun 25 20:27:46 2012 +0900
@@ -801,7 +801,11 @@
         except socket.error:
             self.socket.close()
             self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
-            self.socket.connect(address)
+            try:
+                self.socket.connect(address)
+            except socket.error:
+                self.socket.close()
+                raise
 
     def encodePriority(self, facility, priority):
         """

----------
components: Library (Lib)
messages: 163939
nosy: Kazutaka.Morita
priority: normal
severity: normal
status: open
title: An infinite loop happens when we use SysLogHandler with eventlet
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jun 25 13:45:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Jun 2012 11:45:37 +0000
Subject: [New-bugs-announce] [issue15180] Cryptic traceback from
	os.path.join when mixing str &	bytes
Message-ID: <1340624737.77.0.388823323175.issue15180@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As seen in #4489, the traceback when mixing str and bytes in os.path.join is rather cryptic and hard to decipher if you've never encountered it before:

>>> import os.path
>>> os.path.join(b'', '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/posixpath.py", line 78, in join
    if b.startswith(sep):
TypeError: startswith first arg must be str or a tuple of str, not bytes

>>> os.path.join('', b'')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/posixpath.py", line 78, in join
    if b.startswith(sep):
TypeError: startswith first arg must be bytes or a tuple of bytes, not str

While it's slightly less cryptic with a real source file (since you can at least see the os.path.join call), you have to have some how idea of how os.path.join works to realise that:
- type(sep) == type(args[0])
- b in args[1:]

The challenge is to generate a more user friendly error message without making the normal case of correct types any slower.

----------
components: Library (Lib)
messages: 163945
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Cryptic traceback from os.path.join when mixing str & bytes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 25 14:00:26 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Jun 2012 12:00:26 +0000
Subject: [New-bugs-announce] [issue15181] importlib.h: suncc warnings
Message-ID: <1340625626.44.0.511955354059.issue15181@psf.upfronthosting.co.za>


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

suncc complains about negative values that are assigned to unsigned
char:

"Python/importlib.h", line 3634: warning: initializer does not fit or is out of range: -125
"Python/importlib.h", line 3635: warning: initializer does not fit or is out of range: -125
[...]

----------
components: Build
messages: 163954
nosy: skrah
priority: normal
severity: normal
status: open
title: importlib.h: suncc warnings
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jun 25 15:42:16 2012
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 25 Jun 2012 13:42:16 +0000
Subject: [New-bugs-announce] [issue15182] find_library_file() should try to
	link
Message-ID: <1340631736.41.0.714328941122.issue15182@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer <jdemeyer at cage.ugent.be>:

The find_library_function() in Lib/distutils/unixccompiler.py does a very simple-minded check to determine the existence of a library. It basically only checks that a certain .so file exists. This may lead to false positives: the mere existence of a .so file does not imply that we can actually link against that library.

In addition to (or even better: instead of) checking the existence of the file, you should try to (in the spirit of autoconf) compile a simple program using $CC -l$LIB prog.c -o prog

One particular instance of where things can go wrong is with a 32-bit/64-bit multilib installation. Python might find a 64-bit library in /usr/lib when we're actually compiling 32-bit with libraries in /usr/lib32.

----------
assignee: eric.araujo
components: Distutils
messages: 163968
nosy: eric.araujo, jdemeyer, tarek
priority: normal
severity: normal
status: open
title: find_library_file() should try to link
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 25 20:02:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 25 Jun 2012 18:02:00 +0000
Subject: [New-bugs-announce] [issue15183] it should be made clear that the
	statement in the	--setup option and the setup kw arg aren't
	included in the count
Message-ID: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I looked at 'python -m time -h' and the timeit doc, and it was not clear to me (after a quick read) that the statement(s) inside --setup option and setup keyword argument weren't included in the speed test. I had to check for myself by writing code.

----------
assignee: docs at python
components: Documentation
messages: 163999
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun 25 21:15:34 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Jun 2012 19:15:34 +0000
Subject: [New-bugs-announce] [issue15184] Test failure in
	test_sysconfig_module
Message-ID: <1340651734.76.0.42100141309.issue15184@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

On default, have this single failure on my box (Gentoo amd64):

======================================================================
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/distutils/tests/test_sysconfig.py", line 105, in test_sysconfig_module
    self.assertEqual(global_sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('LDSHARED'))
AssertionError: 'gcc -pthread -shared' != '/usr/bin/clang -shared'
- gcc -pthread -shared
+ /usr/bin/clang -shared


While clang is installed, I haven't set anything to clang while configuring, or in my environment.

----------
components: Tests
messages: 164005
nosy: eric.araujo, georg.brandl
priority: high
severity: normal
status: open
title: Test failure in test_sysconfig_module
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 26 00:31:40 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 25 Jun 2012 22:31:40 +0000
Subject: [New-bugs-announce] [issue15185] Validate callbacks in
	'contextlib.ExitStack.callback()'
Message-ID: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

With this patch 'contextlib.ExitStack.callback(callback, *args, **kwds)' will validate that the passed callback actually accept the passed '*args' and '**kwds'.

P.S. If this patch comes through - I'll create two more issues for 'atexit.register' and 'unittest.TestCase.addCleanup'.  (I'll also look through the stdlib to find if there are some other places where this is needed.)

----------
components: Library (Lib)
files: contextlib.patch
keywords: patch
messages: 164021
nosy: Yury.Selivanov, ncoghlan
priority: normal
severity: normal
status: open
title: Validate callbacks in 'contextlib.ExitStack.callback()'
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26159/contextlib.patch

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

From report at bugs.python.org  Tue Jun 26 01:39:45 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Jun 2012 23:39:45 +0000
Subject: [New-bugs-announce] [issue15186] Support os.walk(dir_fd=)
Message-ID: <1340667585.2.0.886069096281.issue15186@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Adds dir_fd support to os.walk().  Just re-yields from os.fwalk(), removing the last element.

Note: Python 3.4.

----------
assignee: larry
files: larry.os.walk.dir_fd.1.diff
keywords: patch
messages: 164023
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: Support os.walk(dir_fd=)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26160/larry.os.walk.dir_fd.1.diff

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

From report at bugs.python.org  Tue Jun 26 03:54:54 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jun 2012 01:54:54 +0000
Subject: [New-bugs-announce] [issue15187] test_shutil does not clean up
	after itself
Message-ID: <1340675694.27.0.969403918163.issue15187@psf.upfronthosting.co.za>


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

test_shutil leaves several (six) directories in /tmp.  This eventually fills /tmp on my buildbots and causes subsequent test runs to fail.

----------
components: Tests
keywords: buildbot
messages: 164026
nosy: hynek, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil does not clean up after itself
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 26 08:52:27 2012
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Jun 2012 06:52:27 +0000
Subject: [New-bugs-announce] [issue15188] test_ldshared_value failure on OS
	X using python.org	Pythons
Message-ID: <1340693547.43.0.234356884387.issue15188@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

======================================================================
FAIL: test_ldshared_value (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_sysconfig.py", line 288, in test_ldshared_value
    self.assertIn(ldflags, ldshared)
AssertionError: '-arch i386 -arch x86_64   -g -L/tmp/_py/libraries/usr/local/lib' not found in 'gcc-4.2 -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -isysroot /Developer/SDKs/MacOSX10.6.sdk -g -L/tmp/_py/libraries/usr/local/lib'

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


There is code in Mac/BuildScript/build-installer.py to remove the temporary build library path (/tmp/_py/libraries/usr/local/lib) from the Makefile after the build is complete and before the files are packaged.  In 3.3 there is now also a Makefile cache file, _sysconfigdata.py, which is produced as a build target.  build-installer.py needs to learn how to clean it up as well.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 164049
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
status: open
title: test_ldshared_value failure on OS X using python.org Pythons
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 26 09:19:48 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 26 Jun 2012 07:19:48 +0000
Subject: [New-bugs-announce] [issue15189] tkinter.messagebox does not use
	the application's icon
Message-ID: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

The tkinter.messagebox functions, e.g., askyesno(), do not use the application's icon (if it has one). Nor do they accept a bitmapicon option, so ISTM that it is "impossible" to set one.

The same is true of tkinter.dialog, but for that it is easy enough to write one's own replacement with the code like this:

        try:
            tkinter._default_root.iconbitmap(iconName)
        except tk.TclError as err:
            print(err)

(where iconName is "path/to/icon.ico" on windows, "@path/to/icon.xbm" on Unix; and this isn't done on Mac).

----------
components: Tkinter
messages: 164053
nosy: mark
priority: normal
severity: normal
status: open
title: tkinter.messagebox does not use the application's icon
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun 26 10:22:25 2012
From: report at bugs.python.org (Ztatik Light)
Date: Tue, 26 Jun 2012 08:22:25 +0000
Subject: [New-bugs-announce] [issue15190] Allow whitespace and comments
	after line line	continuation character \
Message-ID: <1340698945.14.0.356106357277.issue15190@psf.upfronthosting.co.za>


New submission from Ztatik Light <ztatik.light at gmail.com>:

See Title

----------
components: Interpreter Core
messages: 164055
nosy: Ztatik.Light
priority: normal
severity: normal
status: open
title: Allow whitespace and comments after line line continuation character \
type: enhancement
versions: 3rd party

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

From report at bugs.python.org  Tue Jun 26 10:41:34 2012
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 26 Jun 2012 08:41:34 +0000
Subject: [New-bugs-announce] [issue15191] tkinter convenience dialogs don't
	use themed widgets
Message-ID: <1340700094.05.0.57171486761.issue15191@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

Some of the tkinter convenience dialogs, e.g., tkinter.filedialog.FileDialog, tkinter.scrolledtext.ScrolledText, tkinter.simpledialog.SimpleDialog, tkinter.simpledialog.Dialog, and tkinter.simpledialog._QueryDialog. Ideally they should use ttk.Frame, ttk.Button, etc. Or if that is risky for compatibility, then couldn't they be copied to tkinter.ttk and the copies themized?

----------
components: Tkinter
messages: 164057
nosy: mark
priority: normal
severity: normal
status: open
title: tkinter convenience dialogs don't use themed widgets
versions: Python 3.2

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

From report at bugs.python.org  Tue Jun 26 14:53:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jun 2012 12:53:29 +0000
Subject: [New-bugs-announce] [issue15192] test_bufio failures on Win64
	buildbot
Message-ID: <1340715209.45.0.994879492682.issue15192@psf.upfronthosting.co.za>


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

test_bufio fails sporadically on the AMD64 Windows7 SP1 buildbot, e.g.:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/161/steps/test/logs/stdio

test_nullpat (test.test_bufio.CBufferSizeTest) ... ok
test_primepat (test.test_bufio.CBufferSizeTest) ... ERROR
test_nullpat (test.test_bufio.PyBufferSizeTest) ... ok
test_primepat (test.test_bufio.PyBufferSizeTest) ... ok

======================================================================
ERROR: test_primepat (test.test_bufio.CBufferSizeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 59, in test_primepat
    self.drive_one(b"1234567890\00\01\02\03\04\05\06")
  File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 52, in drive_one
    self.try_one(teststring)
  File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bufio.py", line 20, in try_one
    support.unlink(support.TESTFN)
  File "C:\Users\Buildbot\buildbot.python.org\3.x.kloth-win64\build\lib\test\support.py", line 229, in unlink
    os.unlink(filename)
PermissionError: [Error 5] Access is denied: '@test_2420_tmp'


Is there some kind of anti-virus installed on the machine?

----------
components: Tests
keywords: buildbot
messages: 164072
nosy: jkloth, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_bufio failures on Win64 buildbot
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 26 15:05:21 2012
From: report at bugs.python.org (Mithilesh Kumar)
Date: Tue, 26 Jun 2012 13:05:21 +0000
Subject: [New-bugs-announce] [issue15193] Exception AttributeError:
	"'NoneType' object has no	attribute
Message-ID: <1340715921.04.0.519471476982.issue15193@psf.upfronthosting.co.za>


New submission from Mithilesh Kumar <thesixthprime at gmail.com>:

Behavior of the program changes with number of charaters used in variable name. Attached file shows a simple example.

----------
files: objectvar.py
messages: 164073
nosy: prime
priority: normal
severity: normal
status: open
title: Exception AttributeError: "'NoneType' object has no attribute
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26168/objectvar.py

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

From report at bugs.python.org  Tue Jun 26 17:06:58 2012
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 26 Jun 2012 15:06:58 +0000
Subject: [New-bugs-announce] [issue15194] libffi-3.0.11 update
Message-ID: <1340723218.62.0.173444932066.issue15194@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

here is an update for libffi 3.0.11.  For now, only tested on x86-linux and arm-linux-gnueabi.  Proposing the check it in, and then test again, if the libffi_osx and libffi_msvc copies can be removed, if 3.0.11 works on these platforms (however I can't test on these myself).

----------
components: ctypes
files: libffi-3.0.11.diff.xz
keywords: patch
messages: 164080
nosy: doko
priority: normal
severity: normal
status: open
title: libffi-3.0.11 update
versions: Python 3.3
Added file: http://bugs.python.org/file26169/libffi-3.0.11.diff.xz

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

From report at bugs.python.org  Tue Jun 26 17:26:08 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Tue, 26 Jun 2012 15:26:08 +0000
Subject: [New-bugs-announce] [issue15195] test_distutils fails when
	ARCHFLAGS is set on a Mac
Message-ID: <1340724368.12.0.314472087482.issue15195@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

$ export ARCHFLAGS="-arch i386 -arch x86_64"
$ ./python.exe -m test -v test_distutils

[last: 0] marca at scml-marca:~/dev/hg-repos/cpython$ ./python.exe
Python 3.3.0a4+ (default:6af0535b5e3a, Jun 25 2012, 16:59:49) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
[59901 refs]
>>> sysconfig.get_config_var('LDSHARED')
'gcc -bundle -undefined dynamic_lookup'
[59906 refs]
>>> import distutils.sysconfig
[61596 refs]
>>> distutils.sysconfig.get_config_var('LDSHARED')
'gcc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64'
[77979 refs]

----------
components: Tests
messages: 164081
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: test_distutils fails when ARCHFLAGS is set on a Mac
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun 26 21:04:02 2012
From: report at bugs.python.org (Ben Longbons)
Date: Tue, 26 Jun 2012 19:04:02 +0000
Subject: [New-bugs-announce] [issue15196] os.path.realpath gets confused
	when symlinks include '..'
Message-ID: <1340737442.15.0.365871986623.issue15196@psf.upfronthosting.co.za>


New submission from Ben Longbons <b.r.longbons at gmail.com>:

I encountered this bug with the following filesystem layout

project/build/bin/main-gdb.py -> ../src/main-gdb.py
project/build/src -> ../src/
project/src/main-gdb.py -> ../py/main-gdb.py
project/py/main-gdb.py

where root/py/main-gdb.py contains
import os
print(os.path.realpath(__file__))

Actual Result:
project/build/py/main-gdb.py
instead of 
project/py/main-gdb.py

The cause of this bug is the fact that os.path._resolve_link calls os.path.normpath, which is not symlink-safe.
Specically, this is bad:
os.path.normpath('project/build/src/../py/main-gdb.py')

The correct thing to do is never call normpath; instead leave .. components and pop off the last element after ensuring that the preceding directory is not a symlink.

This bug seems pretty severe to me, because it prevents imports from working.

Exact python --version and Debian package versions:
Python 2.6.7    (2.6.7-4)
Python 2.7.3rc2 (2.7.3~rc2-2.1)
Python 3.2.3    (3.2.3-1)

----------
components: Library (Lib)
messages: 164090
nosy: o11c
priority: normal
severity: normal
status: open
title: os.path.realpath gets confused when symlinks include '..'
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jun 26 23:39:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Jun 2012 21:39:19 +0000
Subject: [New-bugs-announce] [issue15197] test_gettext failure on Win64
	buildbot
Message-ID: <1340746759.25.0.721381261355.issue15197@psf.upfronthosting.co.za>


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

Another weird failure that isn't common on other buildbots:


test test_gettext failed -- Traceback (most recent call last):
  File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\test\test_gettext.py", line 80, in tearDown
    shutil.rmtree(os.path.split(LOCALEDIR)[0])
  File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\shutil.py", line 289, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\Users\Buildbot\buildbot.python.org\3.2.kloth-win64\build\lib\shutil.py", line 287, in rmtree
    os.rmdir(path)
WindowsError: [Error 145] The directory is not empty: 'xx'

----------
components: Tests
keywords: buildbot
messages: 164112
nosy: jeremy.kloth, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_gettext failure on Win64 buildbot
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 27 05:25:49 2012
From: report at bugs.python.org (Ian Bell)
Date: Wed, 27 Jun 2012 03:25:49 +0000
Subject: [New-bugs-announce] [issue15198] multiprocessing Pipe send of
	non-picklable objects	doesn't raise error
Message-ID: <1340767549.24.0.475642908305.issue15198@psf.upfronthosting.co.za>


New submission from Ian Bell <ian.h.bell at gmail.com>:

When a non-picklable object is sent through a multiprocessing.Pipe, no exception is raised, instead when trying to read the other end of the pipe, a TypeError is raised:

TypeError: Required argument 'handle' (pos 1) not found

----------
components: Windows
messages: 164118
nosy: Ian.Bell
priority: normal
severity: normal
status: open
title: multiprocessing Pipe send of non-picklable objects doesn't raise error
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 27 09:10:19 2012
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 27 Jun 2012 07:10:19 +0000
Subject: [New-bugs-announce] [issue15199] Default mimetype for javascript
	should be	application/javascript
Message-ID: <1340781019.87.0.733806504492.issue15199@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>:

Hi,
when using Python's Lib/mimetypes.py and none of the default files is present, there are some defaults used. For javascript, the default is application/x-javascript. However, according to IANA specification [1], this is not a registered type, and application/javascript should be used (see section 7).
I'm attaching a simple patch that fixes this.


[1] http://www.rfc-editor.org/rfc/rfc4329.txt

----------
components: Library (Lib)
files: python-correct-default-js-mimetype.patch
keywords: patch
messages: 164126
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Default mimetype for javascript should be application/javascript
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26174/python-correct-default-js-mimetype.patch

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

From report at bugs.python.org  Wed Jun 27 10:11:22 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 08:11:22 +0000
Subject: [New-bugs-announce] [issue15200] Faster os.walk
Message-ID: <1340784682.62.0.274796197077.issue15200@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Using os.fwalk (if it is available) we can make os.walk more fast.

Microbenchmark:
./python -m timeit -s "from os import walk"  "for x in walk('Lib'): pass"

Results:
Vanilla: 112 msec
Patched: 90.5 msec

----------
components: Library (Lib)
files: faster_walk.patch
keywords: patch
messages: 164127
nosy: storchaka
priority: normal
severity: normal
status: open
title: Faster os.walk
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file26175/faster_walk.patch

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

From report at bugs.python.org  Wed Jun 27 10:59:22 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 27 Jun 2012 08:59:22 +0000
Subject: [New-bugs-announce] [issue15201] C argument errors and Python
	arguments error are	different
Message-ID: <1340787562.9.0.381014932259.issue15201@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

C argument errors and Python arguments error are different.
For example:
all(4,4,4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: all() takes exactly one argument (3 given)
def func(a):pass
a(4,4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: func() takes exactly 1 positional argument (2 given)
I do not know which error message is better.
I think the second example's (func) error message is better.
Though feel free to vote by commenting on this bug.
Another example with not enough arguments given:
hasattr(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: hasattr expected 2 arguments, got 1
func()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: func() takes exactly 1 argument (0 given)
I don't know which of this error messages are better.
You can vote on this by commenting.

----------
components: Interpreter Core
messages: 164129
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: C argument errors and Python arguments error are different
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun 27 10:59:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 08:59:38 +0000
Subject: [New-bugs-announce] [issue15202]
	followlinks/follow_symlinks/symlinks flags unification.
Message-ID: <1340787578.87.0.498110156216.issue15202@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Now three different flag are used to denote the same behavior. followlinks is used in os.(f)walk, symlinks is used in shutil functions (with opposite meaning), and follow_symlinks is just added to many os functions. Unfortunately, symlinks, like followlinks, is used prior to 3.3. But follow_symlinks appeared only in 3.3 (besides, it's too long a name for this frequently used parameter) and it can be unified with one of the earlier spelling. Replacing follow_symlinks to followlinks is simpler than to symlinks.

----------
components: Library (Lib)
files: followlinks.patch
keywords: patch
messages: 164130
nosy: storchaka
priority: normal
severity: normal
status: open
title: followlinks/follow_symlinks/symlinks flags unification.
Added file: http://bugs.python.org/file26176/followlinks.patch

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

From report at bugs.python.org  Wed Jun 27 11:27:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 09:27:19 +0000
Subject: [New-bugs-announce] [issue15203] Accepting of os functions of (path,
	dir_fd) pair as argument
Message-ID: <1340789239.97.0.934534609374.issue15203@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Since many of os functions were polymorphic in its first argument (path or fd), the logical continuation is to add a (path, dir_fd) pair as yet one case of this argument. In any case dir_fd is incopatible with fd. This simplifies the code of certain functions which takes patch and dir_fd and pass them to lower level without changes, or that use same patch and dir_fd in calls of several functions. This freely adds support of dir_fd to many functions, such as os.path.isdir. This solves the problem of naming multiple dir_fd arguments (src_dir_fd/dst_dir_fd looks ugly). This saves a pre-3.3 signature of some functions, which will facilitate the use of decorators and improve compatibility with alternative implementations.

----------
components: Library (Lib)
messages: 164132
nosy: storchaka
priority: normal
severity: normal
status: open
title: Accepting of os functions of (path, dir_fd) pair as argument
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 27 12:29:51 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 10:29:51 +0000
Subject: [New-bugs-announce] [issue15204] Deprecate the 'U' open mode
Message-ID: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Since Python 2.3 many open functions supports "Universal line mode" (PEP 278). Since 3.0 (and 2.6) PEP 3116 suggests better alternative -- io.TextWrapper.

Now support for the 'U' mode in the different open functions is heterogeneous. Some functions simply ignore the 'U' mode (but accept it), others perceive it as a synonym for text-mode, others just pass it on lower lever, other attempt to implement it, but the implementation is obtained imperfect and contradictory (as in ZipExtFile). The documentation for built-in open does not advise the use of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 'U' mode. If someone wanted to work with the universal line support, he'll surely need to work with encodings too, and io.TextWrapper provides is better choise.

The deprecation plan for the 'U' mode of open functions might be as follow:

3.3.  Deprecating the 'U' mode in docs for all opens (building open, io.open, codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper.
3.4.  Raise a warning on use of the 'U' mode.
3.5.  Raise an exception on use of the 'U' mode.
3.6 (or 4.0?).  Remove the 'U' mode processing code.

As the first stage involves only the changes to the documentation, I hope deprecation can starts in 3.3.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 164142
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Deprecate the 'U' open mode
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 27 14:53:41 2012
From: report at bugs.python.org (Ollie Walsh)
Date: Wed, 27 Jun 2012 12:53:41 +0000
Subject: [New-bugs-announce] [issue15205] distutils dereferences symlinks on
	Mac OS X but not on	Linux
Message-ID: <1340801621.17.0.778641533675.issue15205@psf.upfronthosting.co.za>


New submission from Ollie Walsh <ollie.walsh at gmail.com>:

Hi,

This is related to #12585.

Distutils sdist builds a package tree using hardlinks to the source if supported by the OS. This is then tarred/zipped/etc...

If the source contains symbolic links to external files:

On Linux (and apparently Solaris) they are not dereferenced and the resulting package is broken.

On OSX (and apparently all BSD kernels) a hardlink to a symlink will dereference the symlink first and the resulting tgz package is ok. However I would expect issue #8876 to be more likely as the symlink could references a different filesystem which would case hardlinking to fail.


In #12585 I assume that zip dereferences the symlinks which masks the issue.

distutils2 appears to always copy instead of hardlinking resolving all of these issues.

distutils can be monkey patched to do the same: 
http://article.gmane.org/gmane.comp.python.distutils.devel/2078

----------
assignee: eric.araujo
components: Distutils
messages: 164149
nosy: eric.araujo, ollie.walsh at gmail.com, tarek
priority: normal
severity: normal
status: open
title: distutils dereferences symlinks on Mac OS X but not on Linux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 27 16:01:39 2012
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 27 Jun 2012 14:01:39 +0000
Subject: [New-bugs-announce] [issue15206] uuid module falls back to
	unsuitable RNG
Message-ID: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The uuid module uses Mersenne Twister from the random module as last fallback. However a MT isn't suitable for cryptographic purposes. The module should first try to use os.urandom() and then perhaps use its own instance of random.Random, similar to uuid_generate_* [1]

The problem doesn't apply to most modern platforms as the uuid module uses either libuuid or the Windows API with ctypes. Therefore I consider the real world severity as low. It may not require a backport to Python 2.x.

[1] http://linux.die.net/man/3/uuid_generate

----------
components: Library (Lib)
messages: 164157
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: uuid module falls back to unsuitable RNG
type: security
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/issue15206>
_______________________________________

From report at bugs.python.org  Wed Jun 27 18:03:29 2012
From: report at bugs.python.org (Dave Chambers)
Date: Wed, 27 Jun 2012 16:03:29 +0000
Subject: [New-bugs-announce] [issue15207] mimetypes.read_windows_registry()
	uses the wrong regkey, creates wrong mappings
Message-ID: <1340813009.36.0.80214060404.issue15207@psf.upfronthosting.co.za>


New submission from Dave Chambers <dlchambers at aol.com>:

The current mimetypes.read_windows_registry() enums the values under HKCR\MIME\Database\Content Type
However, this is the key for mimetype to extension lookups, NOT for extension to mimetype lookups.
As a result, when >1 MIME types are mapped to a particular extension, the last-found entry is used.
For example, both "image/png" and "image/x-png" map to the ".png" file extension.
Unfortunately, what happens is this code finds "image/png", then later finds "image/x-png" and this steals the ".png" extension.


The solution is to use the correct regkey, which is the HKCR root.
This is the correct location for extension-to-mimetype lookups.
What we should do is enum the HKCR root, find all subkeys that start with a dot (i.e. file extensions), then inspect those for a 'Content Type' value.


The attached ZIP contains:
mimetype_flaw_demo.py  - this demonstrates the error (due to wrong regkey) and my fix (uses the correct regkey)
mimetypes_fixed.py   -   My suggested fix to the standard mimetypes.py module.

----------
components: Windows
files: mimetype_flaw_demo.zip
messages: 164167
nosy: dlchambers
priority: normal
severity: normal
status: open
title: mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26180/mimetype_flaw_demo.zip

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

From report at bugs.python.org  Wed Jun 27 19:33:04 2012
From: report at bugs.python.org (kracekumar ramaraju)
Date: Wed, 27 Jun 2012 17:33:04 +0000
Subject: [New-bugs-announce] [issue15208] Uparrow doesn't show previously
	typed variable or	character
Message-ID: <1340818384.4.0.370220221204.issue15208@psf.upfronthosting.co.za>


New submission from kracekumar ramaraju <me at kracekumar.com>:

Below is the copy & paste from the Interpreter.

kracekumar at python-lover:~/codes/python/Python-3.3.0b1$ python3.3
Python 3.3.0b1 (default, Jun 27 2012, 22:27:38) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> __builtins__
<module 'builtins'>
>>> ^[[A^[[A 

On pressing the up arrow inside 3.3 b1 interpreter doesn't show previously typed variable or statement.

This test was carried out in ubuntu 12.04.

----------
components: Interpreter Core
messages: 164175
nosy: kracekumar
priority: normal
severity: normal
status: open
title: Uparrow doesn't show previously typed variable or character
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 27 20:27:46 2012
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 27 Jun 2012 18:27:46 +0000
Subject: [New-bugs-announce] [issue15209] Re-raising exceptions from an
	expression
Message-ID: <1340821665.84.0.121596566188.issue15209@psf.upfronthosting.co.za>


New submission from Tyler Crompton <gtr053 at gmail.com>:

As you know, a caught exception can be re-raised with a simple `raise` statement. Plain and simple. However, one cannot re-raise an error with this new `"from" expression` clause.

For example:

    def getch(prompt=''):
        '''Get and return a character (similar to `input()`).'''

        print(prompt, end='')
        try:
            return windows_module.getch()
        except NameError:
            try:
                fallback_module.getch()
            except Exception:
                raise from None

Output:

      File "getch.py", line 11
        raise from None
                 ^
    SyntaxError: invalid syntax

A quick look at the documentation about [raise](http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement) confirms that this is the intended behavior. In my opinion, one should be able to still re-raise from an expression.

----------
components: Interpreter Core
files: getch.py
messages: 164184
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: Re-raising exceptions from an expression
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26183/getch.py

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

From report at bugs.python.org  Wed Jun 27 21:21:10 2012
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Jun 2012 19:21:10 +0000
Subject: [New-bugs-announce] [issue15210] importlib.__init__ checks for the
	wrong exception when	looking for _frozen_importlib
Message-ID: <1340824870.13.0.773166317416.issue15210@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at http://hg.python.org/cpython/file/abcd29c9a791/Lib/importlib/__init__.py you will notice that the try/except block for seeing if _frozen_importlib exists catches ImportError, not KeyError like it should since it is checking sys. modules and not performing an import.

----------
components: Library (Lib)
messages: 164188
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: importlib.__init__ checks for the wrong exception when looking for _frozen_importlib
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 27 21:28:38 2012
From: report at bugs.python.org (j)
Date: Wed, 27 Jun 2012 19:28:38 +0000
Subject: [New-bugs-announce] [issue15211] Test
Message-ID: <1340825318.64.0.0530853129884.issue15211@psf.upfronthosting.co.za>


New submission from j <jeffrey.gatto at bwater.com>:

asdf fsa sads f

----------
assignee: collinwinter
components: Benchmarks
messages: 164190
nosy: collinwinter, jgbw
priority: normal
severity: normal
status: open
title: Test
type: crash
versions: Python 3.1

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

From report at bugs.python.org  Thu Jun 28 02:41:13 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 28 Jun 2012 00:41:13 +0000
Subject: [New-bugs-announce] [issue15212] Rename SC_GLOBAL_EXPLICT to
	SC_GLOBAL_EXPLICIT in	compiler module
Message-ID: <1340844073.78.0.438515570461.issue15212@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Revision 4809afa85a9b introduced a typo in compiler module:
SC_GLOBAL_EXPLICT instead of SC_GLOBAL_EXPLICIT

The attached patch fixes this typo.

----------
components: Library (Lib)
files: compiler-SC_GLOBAL_EXPLICIT.patch
keywords: easy, patch
messages: 164215
nosy: Arfrever
priority: normal
severity: normal
stage: patch review
status: open
title: Rename SC_GLOBAL_EXPLICT to SC_GLOBAL_EXPLICIT in compiler module
versions: Python 2.7
Added file: http://bugs.python.org/file26192/compiler-SC_GLOBAL_EXPLICIT.patch

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

From report at bugs.python.org  Thu Jun 28 02:57:03 2012
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Jun 2012 00:57:03 +0000
Subject: [New-bugs-announce] [issue15213] _PyOS_URandom documentation
Message-ID: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The comment for Python/random.c:_PyOS_URandom() states

> Fill buffer with size pseudo-random bytes, not suitable for cryptographic use, from the operating random number generator (RNG).

which is not correct as all paths use a RNG that is suitable for most cryptographic purposes except long living private keys for asymmetric encryption.

Also the function isn't documented although it's an official API function and plays a vital role on the new hash randomization.

----------
assignee: docs at python
components: Documentation
messages: 164218
nosy: christian.heimes, docs at python, haypo, pitrou
priority: low
severity: normal
status: open
title: _PyOS_URandom documentation
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 28 05:44:53 2012
From: report at bugs.python.org (Isaac)
Date: Thu, 28 Jun 2012 03:44:53 +0000
Subject: [New-bugs-announce] [issue15214] list.startswith() and
	list.remove() fails to catch	consecutive items in a list.
Message-ID: <1340855093.79.0.494705749272.issue15214@psf.upfronthosting.co.za>


New submission from Isaac <isaacloves2run at yahoo.com>:

The simple repro below, shows that if a list of strings has two consecutive items that begin with the same letter, an iteration over the list to find and remove all strings that start with that letter fails.  The second string that starts with the same letter to remove remains in the list.

In the example below, both "bananna" and "blueberry" should be removed from the list, but only "bananna" is removed.

I verified this on both 2.7 and 3.2.

-----------------------------------------------------
--- Output ---
--------------
Before: ['apple', 'bananna', 'blueberry', 'coconut']
After:  ['apple', 'blueberry', 'coconut']

-----------------------------------------------------
--- Repro ---
-------------
itemList = ["apple", "bananna", "blueberry", "coconut"]
print("Before: {0}".format(itemList))

for item in itemList:
    if(item.startswith("b")):
        itemList.remove(item)

print("After:  {0}".format(itemList))

----------
files: listRemovalBug.py
messages: 164219
nosy: Eklutna
priority: normal
severity: normal
status: open
title: list.startswith() and list.remove() fails to catch consecutive items in a list.
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file26193/listRemovalBug.py

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

From report at bugs.python.org  Thu Jun 28 09:26:19 2012
From: report at bugs.python.org (Frank Ling)
Date: Thu, 28 Jun 2012 07:26:19 +0000
Subject: [New-bugs-announce] [issue15215] socket module setblocking and
	settimeout problem
Message-ID: <1340868379.68.0.473827205648.issue15215@psf.upfronthosting.co.za>


New submission from Frank Ling <ufwtlsb at gmail.com>:

i use socket such as :
        self.socket.setblocking(1)
        self.socket.settimeout(1)
but this socket is no-block ,i find socketmodule.c sock_settimeout

    s->sock_timeout = timeout;
    internal_setblocking(s, timeout < 0.0);

if timeout >0, so internal_setblocking(s,false=0),so socket is no-block

by the way:
  in sock_settimeout,call internal_setblocking params have error?

init_sockobject:
    if (defaulttimeout >= 0.0)
        internal_setblocking(s, 0);

----------
messages: 164225
nosy: Frank.Ling
priority: normal
severity: normal
status: open
title: socket module setblocking and settimeout problem
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 28 12:49:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Jun 2012 10:49:18 +0000
Subject: [New-bugs-announce] [issue15216] Support setting the encoding on a
	text stream after	creation
Message-ID: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As discussed on python-ideas, swapping out the sys.std* streams can be fraught with peril. This can make writing code that wants to support an "--encoding" option for pipeline processing difficult.

The proposal [1] is that TextIOWrapper support a set_encoding() method that is only supported between creation of the stream and the first read or write operation. Once the stream is "dirty", you can no longer change the encoding - you must replace the stream (e.g. by passing stream.fileNo() to open())

[1] http://mail.python.org/pipermail/python-ideas/2012-June/015535.html

----------
messages: 164239
nosy: ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Support setting the encoding on a text stream after creation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 28 14:04:20 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 28 Jun 2012 12:04:20 +0000
Subject: [New-bugs-announce] [issue15217] os.listdir is missing in
	os.supports_dir_fd
Message-ID: <1340885060.86.0.0519538467215.issue15217@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

>>> n = os.open('/tmp', os.O_RDONLY)
>>> l = os.listdir(n)
>>> os.listdir in os.supports_dir_fd
False

----------
assignee: larry
components: Library (Lib)
messages: 164249
nosy: hynek, larry
priority: release blocker
severity: normal
stage: needs patch
status: open
title: os.listdir is missing in os.supports_dir_fd
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 28 16:35:59 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Thu, 28 Jun 2012 14:35:59 +0000
Subject: [New-bugs-announce] [issue15218] Check for all necessary dir_fd and
	follow_symlinks	functions
Message-ID: <1340894159.39.0.860885591292.issue15218@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

Currently not all functions are checked. As soon as #15217 is fixed, we have to add the rest.

----------
assignee: hynek
components: Library (Lib)
files: fd-protection.diff
keywords: patch
messages: 164259
nosy: hynek
priority: release blocker
severity: normal
status: open
title: Check for all necessary dir_fd and follow_symlinks functions
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26199/fd-protection.diff

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

From report at bugs.python.org  Thu Jun 28 18:45:53 2012
From: report at bugs.python.org (=?utf-8?q?Michael_F=C3=B6tsch?=)
Date: Thu, 28 Jun 2012 16:45:53 +0000
Subject: [New-bugs-announce] [issue15219] Leak in "_hashlib.new()" if
	argument is not a string
Message-ID: <1340901953.6.0.903394800639.issue15219@psf.upfronthosting.co.za>


New submission from Michael F?tsch <foetsch at yahoo.com>:

If the "name" argument to "_hashlib.new()" is not a string, the reference count for the "string" argument is not decremented.

In the file "Modules/_hashopenssl.c", function "EVP_new()", a call to "PyBuffer_Release()" is missing:

  if (!PyArg_Parse(name_obj, "s", &name)) {
+     PyBuffer_Release(&view);
      PyErr_SetString(PyExc_TypeError, "name must be a string");
      return NULL;
  }

----------
components: Library (Lib)
messages: 164274
nosy: mfoetsch
priority: normal
severity: normal
status: open
title: Leak in "_hashlib.new()" if argument is not a string
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 28 23:19:24 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Jun 2012 21:19:24 +0000
Subject: [New-bugs-announce] [issue15220] Reduce parsing overhead
	in	email.feedparser.BufferedSubFile
Message-ID: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za>


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

The idea for the attached patch comes from the QNX development team.  In their measurements, replacing the re.split-plus-line-reassembly code in BufferedSubFile with str.splitlines provided a 30% reduction in email parsing time.  The code is also a lot more readable, which is a plus.

The patch is simple enough, and the improvement is large enough, that I'd like to apply this to all active branches.

----------
components: email
files: feedparser_performance.patch
keywords: patch
messages: 164295
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Reduce parsing overhead in email.feedparser.BufferedSubFile
type: performance
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26204/feedparser_performance.patch

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

From report at bugs.python.org  Fri Jun 29 02:19:49 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 29 Jun 2012 00:19:49 +0000
Subject: [New-bugs-announce] [issue15221] os.path.is*() may return False if
	path can't be accessed
Message-ID: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>


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

It seems a doc fix is the best way to go, in which case I leave this one to a native English speaker:
http://mail.python.org/pipermail/python-dev/2012-June/120788.html

Alternatively a new 'strict' parameter has been proposed as a workaround:
http://mail.python.org/pipermail/python-dev/2012-June/120800.html

----------
assignee: docs at python
components: Documentation
messages: 164307
nosy: christian.heimes, docs at python, eric.araujo, ezio.melotti, georg.brandl, giampaolo.rodola, ncoghlan
priority: normal
severity: normal
status: open
title: os.path.is*() may return False if path can't be accessed
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun 29 07:47:05 2012
From: report at bugs.python.org (lilydjwg)
Date: Fri, 29 Jun 2012 05:47:05 +0000
Subject: [New-bugs-announce] [issue15222] mailbox.mbox writes without
	end-of-line at the file end.
Message-ID: <1340948825.65.0.977158180544.issue15222@psf.upfronthosting.co.za>


New submission from lilydjwg <lilydjwg at gmail.com>:

I find that when mbox writes mails back, it loses the last end-of-line, making appending new mails to the mbox becomes incorrect.

I'm using Linux. In _singlefileMailbox.flush(), when writing the mbox, it loses the last byte ('\n') at the end of each message (because the position from '_toc' is inclusive), and mbox._pre_message_hook() adds it back, but only between two messages. So the last message ends without a '\n'.

----------
components: Library (Lib)
messages: 164313
nosy: lilydjwg
priority: normal
severity: normal
status: open
title: mailbox.mbox writes without end-of-line at the file end.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 29 18:05:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 29 Jun 2012 16:05:27 +0000
Subject: [New-bugs-announce] [issue15223] datetime instances lack __module__
	attribute
Message-ID: <1340985927.81.0.282972335734.issue15223@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Instances of datetime.datetime don't seem to have the '__module__' attribute even though the datetime class itself does.

This seems to contradict Section 3.2 of the Python documentation about the standard type hierarchy (in the subsection called "Class instances"): http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy

"A class instance has a namespace implemented as a dictionary which is the first place in which attribute references are searched. When an attribute is not found there, and the instance?s class has an attribute by that name, the search continues with the class attributes."

Instances of other classes defined in the standard library do have the attribute.

The session below illustrates the issue:

Python 3.3.0a4 (v3.3.0a4:7c51388a3aa7, May 30 2012, 16:58:42) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.__module__
'datetime'
>>> d = datetime(2000, 1, 1)
>>> d.__class__ 
<class 'datetime.datetime'>
>>> d.__module__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'datetime.datetime' object has no attribute '__module__'

----------
components: Library (Lib)
messages: 164332
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: datetime instances lack __module__ attribute
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 29 18:37:03 2012
From: report at bugs.python.org (Yclept Nemo)
Date: Fri, 29 Jun 2012 16:37:03 +0000
Subject: [New-bugs-announce] [issue15224] Range: Additional Methods
	(min/max/__and__)
Message-ID: <1340987823.51.0.113696334515.issue15224@psf.upfronthosting.co.za>


New submission from Yclept Nemo <orbisvicis at gmail.com>:

Python 3.3 expands the range class but I would find some additional methods useful:

min/max: provides O(1) time
__and__: provides intersection: Range(...) & Range(...)

examples:
intersection #1:
a=Range.Range(9,58,4)
b=Range.Range(15,69,6)
c=a&b
print(c)
Range(21, 69, 12)
list(c)
[21, 33, 45, 57]

intersection #2:
a=Range.Range(-75,-7,4)
b=Range.Range(-111, -26, 6)
c=a&b
print(c)
Range(-75, -15, 12)
list(c)
[-75, -63, -51, -39, -27]

intersection #3:
a=Range.Range(58,9,-4)
b=Range.Range(15,69,6)
c=a&b
print(c)
Range(0, 0, 1)
list(c)
[]

I've attached an example Range class implemented in python that includes the min, max, and __and__ functions. It should be useful because the intersection algorithm is complicated. Extending the range class was a requirement for a python 3.2 project and hopefully python 3.4 can benefit.

----------
components: None
files: Range.py
messages: 164333
nosy: Yclept.Nemo
priority: normal
severity: normal
status: open
title: Range: Additional Methods (min/max/__and__)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26209/Range.py

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

From report at bugs.python.org  Fri Jun 29 20:49:40 2012
From: report at bugs.python.org (Marc Abramowitz)
Date: Fri, 29 Jun 2012 18:49:40 +0000
Subject: [New-bugs-announce] [issue15225] Add negative tests for passing str
	to hmac.HMAC and	hmac.new
Message-ID: <1340995780.51.0.208862174905.issue15225@psf.upfronthosting.co.za>


New submission from Marc Abramowitz <msabramo at gmail.com>:

I had been thinking of improving the error message for this case slightly -- and then couldn't find a test for this case so I'm adding one in the attached patch...

----------
components: Tests
files: test_hmac.py.patch
keywords: patch
messages: 164348
nosy: Marc.Abramowitz
priority: normal
severity: normal
status: open
title: Add negative tests for passing str to hmac.HMAC and hmac.new
versions: Python 3.3
Added file: http://bugs.python.org/file26212/test_hmac.py.patch

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

From report at bugs.python.org  Fri Jun 29 21:53:25 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 29 Jun 2012 19:53:25 +0000
Subject: [New-bugs-announce] [issue15226] max( str ) should be fast with PEP
	393
Message-ID: <1340999605.61.0.988726046922.issue15226@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

This is stupid code, but it should be faster with PEP 393 than before, should it not?


str = ' ' * 5000000 + "this is really a string example....wow!!!";
for ix in range( 9000 ):
    z = max(str)
print("Max character: " + max(str))


While the new C API seems to support quickly finding the max character in a string, Python code does not benefit.

----------
components: Interpreter Core
messages: 164351
nosy: v+python
priority: normal
severity: normal
status: open
title: max( str ) should be fast with PEP 393
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 30 06:25:56 2012
From: report at bugs.python.org (Thomas Maslach)
Date: Sat, 30 Jun 2012 04:25:56 +0000
Subject: [New-bugs-announce] [issue15227] Fatal Python error:
	PyEval_RestoreThread: NULL tstate on	example script..
Message-ID: <1341030356.65.0.710942348238.issue15227@psf.upfronthosting.co.za>


New submission from Thomas Maslach <tommaslach at gmail.com>:

I've been running into a bug recently and reduced the code to the following:

import Tkinter                    
tk = Tkinter.Tk()
window = Tkinter.Frame(tk)
def onDestroy (event):
  pass
window.bind ("<Destroy>", onDestroy)


Just run and the following will be displayed: 
Fatal Python error: PyEval_RestoreThread: NULL tstate

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

If you add window.mainloop(), the issue goes aware.  However, I don't do that in my case.  window.update(), by the way, still causes the crash if that is of any interest (I found this tinkering)..

I'm running with:
 - Window 7
 - Python 2.7.2
 - 64-bit machine, but 32-bit Python

Thanks!

----------
components: Tkinter
messages: 164367
nosy: tmaslach
priority: normal
severity: normal
status: open
title: Fatal Python error: PyEval_RestoreThread: NULL tstate on example script..
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 30 21:55:23 2012
From: report at bugs.python.org (Daniel Grace)
Date: Sat, 30 Jun 2012 19:55:23 +0000
Subject: [New-bugs-announce] [issue15228] os.utime() docs not clear on
	behavior on nonexistant	files
Message-ID: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>


New submission from Daniel Grace <thisgenericname at gmail.com>:

The documentation for os.utime() at http://docs.python.org/py3k/library/os.html#os.utime states:

"Set the access and modified times of the file specified by path. [...] The effect is similar to running the Unix program touch on the path.)"

Unlike 'touch', os.utime() will not create an empty file if called on a file that does not exist.  IMO the current behavior is correct, but the comparison of os.utime() to touch implies that it would create empty files.

I suggest clarifying the documentation to emphasize that os.utime() will not create new files and raises OSError in the event that the file does not exist.

----------
assignee: docs at python
components: Documentation
messages: 164422
nosy: dewin, docs at python
priority: normal
severity: normal
status: open
title: os.utime() docs not clear on behavior on nonexistant files
type: enhancement

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

From report at bugs.python.org  Sat Jun 30 22:09:42 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 30 Jun 2012 20:09:42 +0000
Subject: [New-bugs-announce] [issue15229] stringification of subclasses of
	OSError can cause crash
Message-ID: <1341086982.43.0.276121851076.issue15229@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

If you subclass OSError without calling OSError.__init__() then you can get a crash.  For example

  Python 3.3.0b1 (default:cfbe51e66749, Jun 30 2012, 20:50:54) [MSC v.1600 32 bit
  (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> class MyError(OSError):
  ...   def __init__(self):
  ...     pass
  ...
  [61116 refs]
  >>> repr(MyError())
  Assertion failed: obj, file ..\Objects\unicodeobject.c, line 2646

Note that str(MyError()) results in a crash without hitting a failed assertion.

The problem does not occur in Python 3.2, and it does not affect subclasses of Exception.

----------
components: Interpreter Core
messages: 164423
nosy: sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: stringification of subclasses of OSError can cause crash
type: crash
versions: Python 3.3

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