From report at bugs.python.org  Wed May  1 00:52:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Apr 2013 22:52:46 +0000
Subject: [New-bugs-announce] [issue17884] Try to reuse stdint.h types like
	int32_t
Message-ID: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In different places, macros like SIZEOF_VOID_P or SIZEOF_LONG to choose a type, whereas the C language proposes standard types since ISO C99: intXX_t and uintXX_t (8, 16, 32, 64), intptr_t, etc.

Python should rely on these new types instead of trying to reimplement this standard. autotools provides missing types if needed. On Windows, stdint.h is supported in Microsoft Visual Studio 2010.

Attached patch reuses stdint.h types in different places. I only tested it on Linux Fedora 11.

sha3 module should also be modified.

I don't know if int64_t and uint64_t are always supported, nor if we can rely on them. Does Python support platform without 64-bit integer type?

The md5 module uses PY_LONG_LONG to get a 64-bit type. Does anyone know a platform where the md5 module is not compiled?

----------
files: reuse_stdint_types.patch
keywords: patch
messages: 188192
nosy: Devin Jeanpierre, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Try to reuse stdint.h types like int32_t
versions: Python 3.4
Added file: http://bugs.python.org/file30083/reuse_stdint_types.patch

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

From eliswilson at hushmail.com  Wed May  1 01:16:42 2013
From: eliswilson at hushmail.com (eliswilson at hushmail.com)
Date: Tue, 30 Apr 2013 19:16:42 -0400
Subject: [New-bugs-announce] Biggest Fake Conference in Computer Science
Message-ID: <20130430231642.DFFD2E6736@smtp.hushmail.com>

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on the world?s biggest 
bogus computer science conference WORLDCOMP  http://sites.google.com/site/worlddump1 
organized by Prof. Hamid Arabnia from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to 
WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that 
paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it was accepted both the times 
without any modifications (and without any reviews) and we were invited to submit the final paper 
and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than 
making Prof. Hamid Arabnia richer. After that, we received few reminders from WORLDCOMP to pay 
the fee but we never responded. This fake paper is different from the two fake papers already published 
(see https://sites.google.com/site/worlddump4 for details) in WORLDCOMP.


We MUST say that you should look at the above website if you have any thoughts of participating in
WORLDCOMP.  DBLP and other indexing agencies have stopped indexing WORLDCOMP?s proceedings 
since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for
of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers about 
WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or 
non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the 
resume and peace of mind forever!


Our study revealed that WORLDCOMP is money making business, using University of Georgia mask, for 
Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper 
published in WORLDCOMP?s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes 
WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses 
fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous 
phone calls and threatens the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That 
is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get 
more money into his (and Prof. Hamid Arabnia?s) pockets. Prof. Hamid Arabnia makes a lot of tricks. For 
example, he appeared in a newspaper to fool the public, claiming him a victim of cyber-attack (see Item 
8 in Section 5 of above website).


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to 
provide the venue for WORLDCOMP?13 because of the fears of their image being tarnished due to 
WORLDCOMP?s fraudulent activities. That is why WORLDCOMP?13 is taking place at a different resort. 
WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee members, no reviewers, 
and there is no conference Chairman. The only contact details available on WORLDCOMP?s website is 
just an email address! 

We ask Prof. Hamid Arabnia to publish all reviews for all the papers (after blocking identifiable details) 
since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how 
many papers each reviewer had reviewed on average. We also ask him to look at the Open Challenge 
(Section 6) at https://sites.google.com/site/moneycomp1 and respond if he has any professional values.


Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. 
Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet?s activities at
http://worldcomp-fake-bogus.blogspot.com   Search Google using the keyword worldcomp fake for 
additional links.


From report at bugs.python.org  Wed May  1 03:28:02 2013
From: report at bugs.python.org (HCT)
Date: Wed, 01 May 2013 01:28:02 +0000
Subject: [New-bugs-announce] [issue17885] multiprocessing.Process child
	process imports package	instead of parent file
Message-ID: <1367371682.48.0.908300768897.issue17885@psf.upfronthosting.co.za>


New submission from HCT:

created a project with the following content
CODEC/
CODEC/video.py
CODEC/audio.py
CODEC/__init__.py
CRC/
CRC/crc24.py
CRC/crc32.py
CRC/__init__.py
TEST/test_crc.py
TEST/test_codec.py
TEST/__init__.py
__init__.py
test.py
main.py


test.py contain tests that launches multiple multiprocessing.Process to test diffferent module in parallel, but always fail to launch child processes for test with AttributeError. I spent lots of time trying to figure out why my code don't work. I also tried to use the examples from http://docs.python.org/dev/library/multiprocessing.html#the-process-class and they also gives AttributeError when launching child process. in the end, I figured out it's because Pythong file test.py has same name as package TEST. change test.py to test_all.py and everything worked.

It looks multiprocessing import defaults to import package, not the parent file when file name without suffix is same as package.

----------
components: Library (Lib)
messages: 188197
nosy: hct
priority: normal
severity: normal
status: open
title: multiprocessing.Process child process imports package instead of parent file
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Wed May  1 04:20:00 2013
From: report at bugs.python.org (Hank Christian)
Date: Wed, 01 May 2013 02:20:00 +0000
Subject: [New-bugs-announce] [issue17886] Invitation to connect on LinkedIn
Message-ID: <1812581655.1517967.1367374798003.JavaMail.app@ela4-app0132.prod>


New submission from Hank Christian:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Henry

Henry Christian
ADJUNCT PROFESSOR at Central Texas College
Greater Los Angeles Area

Confirm that you know Henry Christian:
https://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/isd/10674146693/f8KKDSuG/?hs=false&tok=0pSa4dW8LbLlI1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4269541394_1/?hs=false&tok=3ubW__G4DbLlI1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 188200
nosy: hankchristian
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed May  1 08:34:47 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 01 May 2013 06:34:47 +0000
Subject: [New-bugs-announce] [issue17887] docs: summary page - generator vs
	iterator vs iterable
Message-ID: <1367390087.97.0.0883934646573.issue17887@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Docs lack a good summary page comparing three concepts. The main question is how do I tell if something is a sequence, generator, iterator or iterable? I found myself puzzled that range() is neither generator or iterator.

----------
assignee: docs at python
components: Documentation
messages: 188203
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: summary page - generator vs iterator vs iterable

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

From report at bugs.python.org  Wed May  1 14:55:14 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 01 May 2013 12:55:14 +0000
Subject: [New-bugs-announce] [issue17888] docs: more information on
	documentation team
Message-ID: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

To help people understand that they can actually improve Python docs themselves, how about the following changes:

http://docs.python.org/3/bugs.html - rename from "Reporting Bugs" to "Dealing with Bugs".

Explain that sometimes fixing bug is easier than reporting, because it involves less time from all people in total. Link to step-by-step documentation for the process and include channel for proposals how to make the process more streamlined.

Add links to archive and docs at python.org mailing list info
http://mail.python.org/mailman/listinfo/docs

On this info page make it clear that "Python documentation team" is not a team in common narrow sense, but a group of volunteers open for everybody. Either by providing a link to team page with listed members, or by replacing the text:
- "Mailing list for the Python documentation team"
+ "Mailing list for people collaborating on Python docs"

----------
assignee: docs at python
components: Documentation
messages: 188218
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: more information on documentation team

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

From report at bugs.python.org  Wed May  1 16:38:47 2013
From: report at bugs.python.org (SilentGhost)
Date: Wed, 01 May 2013 14:38:47 +0000
Subject: [New-bugs-announce] [issue17889] argparse subparsers break without
	without argument
Message-ID: <1367419127.75.0.745110638267.issue17889@psf.upfronthosting.co.za>


New submission from SilentGhost:

If you run attached file w/ 3.2 and 3.3 (and later) versions, you'll notice that the new version of parser doesn't handle empty argument list:

$ python3.2 test.py
usage: test.py [-h] {demo} ...
test.py: error: too few arguments
$ python3.3 test.py
Namespace()

Everything is naturally failing in 3.3 version as the execution continues with the empty Namespace. I suspect this is due to the issue10424 that removed explicit check for positionals.

----------
components: Library (Lib)
files: test.py
keywords: 3.3regression
messages: 188228
nosy: SilentGhost, bethard, maker, r.david.murray
priority: normal
severity: normal
status: open
title: argparse subparsers break without without argument
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30095/test.py

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

From report at bugs.python.org  Thu May  2 02:43:02 2013
From: report at bugs.python.org (Garrett Holmstrom)
Date: Thu, 02 May 2013 00:43:02 +0000
Subject: [New-bugs-announce] [issue17890] argparse: mutually exclusive
	groups full of suppressed	args can cause AssertionErrors
Message-ID: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za>


New submission from Garrett Holmstrom:

When it goes to format a usage message, argparse seems to (correctly) fail to satisfy one of its assertions when all of the following are true:

1. A mutually exclusive group contains only args that are suppressed
2. An unsuppressed arg follows that group
3. The usage is long enough to need to line-wrap

The cause seems to be that the set of regular expressions that argparse uses to clean up mutually exclusive groups' separators doesn't handle the space that follows what would otherwise be an empty pair of square braces, sort of like this:

1. [-h] [ ] [--spam] ...
2. [-h] [] [--spam] ...
3. [-h]  [--spam] ...

A test case is attached.  I was able to reproduce this with python-2.7.3-13.fc18.x86_64 on Fedora as well as with commit 83588:e6b962fa44bb in 3.4 mainline.  I have a small patch for the latter that I'll submit shortly.

Sorry if I missed anything.  This is my first bug report against python proper.

----------
components: Library (Lib)
files: argparse-assertfail.py
messages: 188250
nosy: gholms
priority: normal
severity: normal
status: open
title: argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file30102/argparse-assertfail.py

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

From report at bugs.python.org  Thu May  2 10:08:09 2013
From: report at bugs.python.org (Alonso Vidales)
Date: Thu, 02 May 2013 08:08:09 +0000
Subject: [New-bugs-announce] [issue17891] Wrong MD5 calculation on really
	long strings and the	Hashlib
Message-ID: <1367482089.28.0.00515501399845.issue17891@psf.upfronthosting.co.za>


New submission from Alonso Vidales:

Taking part on a contest I found a bug working with a string of 6227020800 characters, all the characters are the 'a' char.
When I execute:
   hashlib.md5(string).hexdigest()
On Python, is takes a pair of seconds (need more to calculate this md5, I think that it crashes without launch any exception), and returns the hash:
   8adbd18519be193db41dd5341a260963
When I execute the same code using Pypy the hash is:
   38fe0c01bfa0eb9d153b034f8408a8b7
In order to know witch one is the correct hash, I created a file with 6227020800 characters on my system and I executed the "md5" of OpenSSL, I think that we can trust on it, obtaining the same result as Pypy:
    unknown7cd1c3ecbb9b:Downloads socialpoint$ wc -c md5_test
     6227020800 md5_test
    unknown7cd1c3ecbb9b:Downloads socialpoint$ md5 md5_test
    MD5 (md5_test) = 38fe0c01bfa0eb9d153b034f8408a8b7
Then Python are doing something wrong.
Pls, find attached a screenshot that shows the result of the tests. If you can't reproduce it, or need more information, please let me know.

My Python version:
Python 2.7.1 (r271:86832, Aug  5 2011, 03:30:24) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin

Pypy version:
Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54)
[PyPy 1.9.0 with GCC 4.2.1] on darwin

----------
components: Library (Lib)
files: Screen Shot 2013-05-02 at 3.13.48 AM.png
messages: 188255
nosy: Alonso.Vidales
priority: normal
severity: normal
status: open
title: Wrong MD5 calculation on really long strings and the Hashlib
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file30103/Screen Shot 2013-05-02 at 3.13.48 AM.png

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

From report at bugs.python.org  Thu May  2 10:45:28 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 02 May 2013 08:45:28 +0000
Subject: [New-bugs-announce] [issue17892] Fix the name of
	_PyObject_CallMethodObjIdArgs
Message-ID: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The changeset 2dd046be2c88 introduced _PyObject_CallMethodObjIdArgs. This API should have been named _PyObject_CallMethodIdObjArgs since it is the variant of _PyObject_CallMethodId which takes object arguments instead of building arguments from a format string.

I would fix it myself. However, I am not sure how we should proceed with regard to backward incompatibility.

----------
assignee: brett.cannon
components: Interpreter Core
files: rename_PyObject_CallMethodIdObjArgs.patch
keywords: patch
messages: 188257
nosy: alexandre.vassalotti, brett.cannon
priority: normal
severity: normal
stage: patch review
status: open
title: Fix the name of _PyObject_CallMethodObjIdArgs
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file30104/rename_PyObject_CallMethodIdObjArgs.patch

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

From report at bugs.python.org  Thu May  2 11:53:07 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 02 May 2013 09:53:07 +0000
Subject: [New-bugs-announce] [issue17893] Refactor reduce protocol
	implementation
Message-ID: <1367488387.09.0.179973942781.issue17893@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

I have tried to clean up a bit of the implementation of the reduce protocol in typeobject.c in preparation for PEP 3154's support of classes with __new__ using keyword-only arguments. I am not quite done yet with the refactorings, but I would appreciate some early feedback about whether  the changes looks right or other refactoring ideas you might have.

----------
assignee: alexandre.vassalotti
components: Interpreter Core
files: refactor_reduce.patch
keywords: patch
messages: 188261
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Refactor reduce protocol implementation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30105/refactor_reduce.patch

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

From report at bugs.python.org  Fri May  3 04:11:52 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 03 May 2013 02:11:52 +0000
Subject: [New-bugs-announce] [issue17894] Edits to descriptor howto
Message-ID: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

I find the explanations in the Descriptor howto to be difficult to understand.  I took a stab at changing the first few sections to introduce the concepts in an easier-to-grasp style.

Issue 12077 also covers a little bit of this.

----------
assignee: docs at python
components: Documentation
files: descriptor_howto.patch
keywords: patch
messages: 188289
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Edits to descriptor howto
versions: Python 3.4
Added file: http://bugs.python.org/file30111/descriptor_howto.patch

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

From report at bugs.python.org  Fri May  3 18:54:17 2013
From: report at bugs.python.org (Julian Taylor)
Date: Fri, 03 May 2013 16:54:17 +0000
Subject: [New-bugs-announce] [issue17895] TemporaryFile name returns an
	integer in python3
Message-ID: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za>


New submission from Julian Taylor:

sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0)
In [3]: type(tempfile.TemporaryFile().name)
Out[3]: builtins.int

in python2 it returned a string, this is a somewhat pointless api change which breaks some third party code, e.g. numpy (https://github.com/numpy/numpy/issues/3302)

----------
components: Library (Lib)
messages: 188305
nosy: jtaylor
priority: normal
severity: normal
status: open
title: TemporaryFile name returns an integer in python3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri May  3 19:18:26 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 03 May 2013 17:18:26 +0000
Subject: [New-bugs-announce] [issue17896] Move Windows external libs from
	<src>\..\ to	<src>\externals
Message-ID: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>


New submission from Zachary Ware:

PCbuild\readme.txt has a comment from Trent Nelson dated 2-April-2008 suggesting moving the external library location for Windows from "<cpython checkout>\..\" to "<cpython checkout>\external\" to make switching between versions easier.  I've gotten rather annoyed with having all of the external libs cluttering the folder holding my cpython checkout, so I've written a patch that moves them :).

The patch actually moves the external libs into "<checkout>\external-34", because in most cases it's best to have separately built externals for each Python version.  The idea is to then have an "external-35" after 3.4 is released, and possibly "external-27" and "external-33" if it is permissible to backport this kind of change.  There are only four places that would need to be changed in other versions; PCbuild/pyproject.props:19, PCbuild/rt.bat:41, Tools/buildbot/external-common.bat:4 and 5, and Lib/tkinter/_fix.py:52.  All four are simple replacements which I believe could be automated by the release script.  PCbuild/build_ssl.py is patched to find the externals dir in PCbuild/pyproject.props while finding the OpenSSL version there.

A few of the benefits to this that have occurred to me are:
- the fact that the dir holding your cpython checkout doesn't get cluttered up with external libs
- it becomes very easy to rebuild all of the externals (just `rmdir /s /q external-34` and run external(-amd64).bat again)
- no possibility of problems arising from one version trying to use an external lib built by/for another version

The only real downsides I'm aware of are that it is a change from what everyone is accustomed to, and that it will use up a bit more disk space (which could be mitigated by using junctions, as Trent suggested in the comment in readme.txt).  Also, committing this would cause an extra long build time on the buildbots due to having to recompile Tcl/Tk and OpenSSL.

Everything builds and works for me using the buildbot scripts after the patch.  All comments welcome :)

Thanks,

Zach

----------
components: Build, Extension Modules, Windows
files: move_externals.diff
keywords: patch
messages: 188309
nosy: brian.curtin, tim.golden, trent, zach.ware
priority: normal
severity: normal
status: open
title: Move Windows external libs from <src>\..\ to <src>\externals
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30113/move_externals.diff

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

From report at bugs.python.org  Fri May  3 20:16:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 May 2013 18:16:39 +0000
Subject: [New-bugs-announce] [issue17897] Optimize unpickle prefetching
Message-ID: <1367604999.94.0.501171592637.issue17897@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When C implementation of the unpickle reads a data, it also prefetches some data using peek() (if available) and then concatenates read and peeked chunks in the one input buffer. This causes an additional copying when a large data is read. The proposed patch gets rid of concatenating by moving a peeking before reading.

----------
components: Extension Modules
files: pickle_peek.patch
keywords: patch
messages: 188317
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize unpickle prefetching
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file30114/pickle_peek.patch

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

From report at bugs.python.org  Fri May  3 20:19:46 2013
From: report at bugs.python.org (Steve Strassmann)
Date: Fri, 03 May 2013 18:19:46 +0000
Subject: [New-bugs-announce] [issue17898] gettext bug while parsing
	plural-forms metadata
Message-ID: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za>


New submission from Steve Strassmann:

The gettext.py parser used by django (lib/python2.7/gettext.py),
GNUTranslations._parse(), around line 313 does not use clean values for k,v on each
iteration ("for item in tmsg.splitlines():")

To reproduce the problem (see traceback, below), try parsing a .PO file containing two headers like this, with a comment header immediately following a plurals header. This example was created by calling msgcat to combine several .po files into a single .po file. Msgcat inserted the comment line.

"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  messages.po (EdX Studio)  #-#-#-#-#\n"

Parsing the first header binds the inner loop variables:
  k= plural-forms v= ['nplurals=2', ' plural=(n != 1)', '']

Parsing the second header leaves k,v untouched, which then causes an improper
attempt to parse (since it's a comment, no further parsing of k,v should occur)
 v = v.split(';')

Bug workaround: I use polib to read and immediately save the file. This reorders the metadata to avoid presenting the parser with something that will break it.

Recommended bug fix: on each iteration over tmsg.splitlines, reset the values of k,v = (None, None)

--------------------
Traceback:
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
89.                     response = middleware_method(request)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/middleware/locale.py" in process_request
24.         translation.activate(language)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/__init__.py" in activate
105.     return _trans.activate(language)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in activate
201.     _active.value = translation(language)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in translation
191.     current_translation = _fetch(language, fallback=default_translation)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _fetch
180.                 res = _merge(localepath)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _merge
156.             t = _translation(path)
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _translation
138.                 t = gettext_module.translation('django', path, [loc], DjangoTranslation)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in translation
480.                 t = _translations.setdefault(key, class_(fp))
File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in __init__
76.         gettext_module.GNUTranslations.__init__(self, *args, **kw)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in __init__
180.             self._parse(fp)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in _parse
315.                         v = v.split(';')

Exception Type: AttributeError at /
Exception Value: 'list' object has no attribute 'split'

----------
components: Library (Lib)
messages: 188318
nosy: straz
priority: normal
severity: normal
status: open
title: gettext bug while parsing plural-forms metadata
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri May  3 21:16:26 2013
From: report at bugs.python.org (Evgeny Kapun)
Date: Fri, 03 May 2013 19:16:26 +0000
Subject: [New-bugs-announce] [issue17899] os.listdir() leaks FDs if invoked
	on FD pointing to a	non-directory
Message-ID: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

When called with a file descriptor as an argument, os.listdir() duplicates it to pass to fdopendir(3). If this call fails, the new file descriptor is not closed, which leads to file descriptor leak.

----------
components: Library (Lib)
messages: 188322
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: os.listdir() leaks FDs if invoked on FD pointing to a non-directory
type: resource usage
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May  3 21:40:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 May 2013 19:40:16 +0000
Subject: [New-bugs-announce] [issue17900] Recursive OrderedDict pickling
Message-ID: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which allows pickling of recursive OrderedDicts. Actually it simplifies __reduce__() code.

----------
components: Library (Lib)
files: OrderedDict_pickle_recursive.patch
keywords: patch
messages: 188325
nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Recursive OrderedDict pickling
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30116/OrderedDict_pickle_recursive.patch

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

From report at bugs.python.org  Fri May  3 21:56:56 2013
From: report at bugs.python.org (Aaron Oakley)
Date: Fri, 03 May 2013 19:56:56 +0000
Subject: [New-bugs-announce] [issue17901] _elementtree.TreeBuilder raises
	IndexError on end if	constructed with element_factory=None
Message-ID: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za>


New submission from Aaron Oakley:

When the _elementtree module is in use, the TreeBuilder class will raise an IndexError in treebuilder_handle_end if __init__ was passed "None".

I discovered this while writing a subclass of TreeBuilder with a modified __init__ method that delegated to TreeBuilder:

    class MyTreeBuilder(ET.TreeBuilder):
        def __init__(self, element_factory=None):
            super().__init__(element_factory)

Used as a target, this class (and also simply "TreeBuilder(None)") will cause the IndexError when "parser.feed(data)" is called.

>>> import xml.etree.ElementTree as ET
>>> parser = ET.XMLParser(target=ET.TreeBuilder(None))
>>> parser.feed('<file><line>22</line></file>')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: pop from empty stack

The error is raised from treebuilder_handle_end, but the cause appears to be in treebuilder_handle_start.

    if (self->element_factory) {
        node = PyObject_CallFunction(self->element_factory, "OO", tag, attrib);
    } else {
        node = create_new_element(tag, attrib);
    }

I included a patch adding a check against Py_None to the "if" test above which seems to fix the issue. I also included a simple test case for it.

----------
components: XML
files: _elementtree.c-340a0.patch
keywords: patch
messages: 188326
nosy: Aaron.Oakley
priority: normal
severity: normal
status: open
title: _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30117/_elementtree.c-340a0.patch

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

From report at bugs.python.org  Fri May  3 22:56:18 2013
From: report at bugs.python.org (Aaron Oakley)
Date: Fri, 03 May 2013 20:56:18 +0000
Subject: [New-bugs-announce] [issue17902] Document that _elementtree C API
	cannot use custom	TreeBuilder for iterparse or IncrementalParser
Message-ID: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za>


New submission from Aaron Oakley:

It would really help to document that the C API can only use the default xml.etree.ElementTree.TreeBuilder for targets with iterparse (and by extension, IncrementalParser).

I got a nice surprise about that when I went from 3.2 to 3.3 and started getting "TypeError: event handling only supported for ElementTree.TreeBuilder targets".

I included a patch to add notes to iterparse and IncrementalParser, but I'm not sure what to refer to the C module as since xml.etree.cElementTree is deprecated.

----------
assignee: docs at python
components: Documentation, XML
files: elementtree.rst-340a0.patch
keywords: patch
messages: 188329
nosy: Aaron.Oakley, docs at python
priority: normal
severity: normal
status: open
title: Document that _elementtree C API cannot use custom TreeBuilder for iterparse or IncrementalParser
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file30119/elementtree.rst-340a0.patch

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

From report at bugs.python.org  Sat May  4 12:12:42 2013
From: report at bugs.python.org (Paul Moore)
Date: Sat, 04 May 2013 10:12:42 +0000
Subject: [New-bugs-announce] [issue17903] Python launcher for windows should
	search path for	#!/usr/bin/env
Message-ID: <1367662362.6.0.575670511803.issue17903@psf.upfronthosting.co.za>


New submission from Paul Moore:

The Python launcher for windows should recognise a hashbang line of #!/usr/bin/env python, and use the python executable found on PATH to run the script. If no python executable is present on PATH the launcher should fall back to the current behaviour (using the default python, as if #!/usr/bin/python were present).

This matches the behaviour on other platforms where env is used to ensure that the script uses the user's currently activated Python, and is particularly important when virtualenvs are being used.

----------
assignee: vinay.sajip
components: Windows
messages: 188347
nosy: pmoore, vinay.sajip
priority: normal
severity: normal
status: open
title: Python launcher for windows should search path for #!/usr/bin/env
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat May  4 12:34:39 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 04 May 2013 10:34:39 +0000
Subject: [New-bugs-announce] [issue17904] bytes should be listed as built-in
	function for 2.7
Message-ID: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

Looking into the summary table, there's no information about the `bytes` built-in alias for `str`:
http://docs.python.org/2/library/functions.html

IMHO it should appear in this table (as str, unicode, bytearray) with the appropriate `.. versionadded:`.

----------
assignee: docs at python
components: Documentation
messages: 188349
nosy: docs at python, flox
priority: normal
severity: normal
status: open
title: bytes should be listed as built-in function for 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat May  4 16:09:13 2013
From: report at bugs.python.org (Antonio Cavallo)
Date: Sat, 04 May 2013 14:09:13 +0000
Subject: [New-bugs-announce] [issue17905] Add check for locale.h
Message-ID: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za>


New submission from Antonio Cavallo:

This patch adds autoconf.ac check for the locale.h file in addition to langinfo.h. The patch contains also a fix to Python/fileutils.c file.

The android ndk provides locale.h but no langinfo.h: this fixes the issue.

BTW bionic doesn't have any runtime support for locale at the moment in the standard build at least.

----------
components: Build, Cross-Build
files: locale_h_configure.ac.patch
keywords: patch
messages: 188362
nosy: benjamin.peterson, cavallo71, doko, haypo
priority: normal
severity: normal
status: open
title: Add check for locale.h
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file30123/locale_h_configure.ac.patch

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

From report at bugs.python.org  Sat May  4 16:38:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 May 2013 14:38:28 +0000
Subject: [New-bugs-announce] [issue17906] Add a string error handler to JSON
	encoder/decoder
Message-ID: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Inspired by simplejson issue [1] which is related to standard json module too. JSON parser 3.3+ and wide builds of 3.2- raise an error on invalid strings (i.e. with unpaired surrogate), while narrow builds and some third-party parsers. Wide builds are right, such JSON data is invalid. However it will be good to be optionally more permissive to input data. Otherwise it is not easy process such invalid data.

I propose to add an "error" parameter to JSON decoder and encoder with the same meaning as in string decoding/encoding. "strict" is default and "surrogatepass" corresponds to narrow builds (and non-strict third-party parsers).

[1] https://github.com/simplejson/simplejson/issues/62

----------
assignee: serhiy.storchaka
components: Extension Modules, Library (Lib), Unicode
messages: 188364
nosy: bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a string error handler to JSON encoder/decoder
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat May  4 20:25:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 04 May 2013 18:25:08 +0000
Subject: [New-bugs-announce] [issue17907] Deprecate imp.new_module() in
	favour of types.ModuleType
Message-ID: <1367691908.58.0.339991159831.issue17907@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp.new_module() does not need to exist since code can use types.ModuleType's constructor.

----------
components: Library (Lib)
keywords: easy
messages: 188388
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Deprecate imp.new_module() in favour of types.ModuleType
versions: Python 3.4

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

From report at bugs.python.org  Sun May  5 04:20:44 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 May 2013 02:20:44 +0000
Subject: [New-bugs-announce] [issue17908] Unittest runner needs an option to
	call gc.collect()	after each test
Message-ID: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

It would be nice if there was a command-line option to tell the test runner to call gc.collect() after each test.

See https://groups.google.com/d/msg/python-tulip/tstjvOQowIU/IRihc8NCHZUJ -- Glyph points out that always doing this is problematic because it slows down tests too much; OTOH it's a useful option to have in case you're tracking down something that happens (or doesn't happen) when an object is collected (e.g. in __del__).

----------
components: Library (Lib)
keywords: easy
messages: 188420
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Unittest runner needs an option to call gc.collect() after each test
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun May  5 15:10:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 May 2013 13:10:30 +0000
Subject: [New-bugs-announce] [issue17909] Autodetecting JSON encoding
Message-ID: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

RFC 4627 specifies a method to determine an encoding (one of UTF-8, UTF-16(BE|LE) or UTF-32(BE|LE)) of encoded JSON text. The proposed preliminary patch (it doesn't include the documentation yet) allows load() and loads() functions accept bytes data when it is encoded with standard Unicode encoding. Also accepted data with BOM (this doesn't specified in RFC 4627, but is widely used).

There is only one case where the method can give a misfire. Serialized string "\x00..." encoded in UTF-16LE may be erroneously detected as encoded in UTF-32LE. This case violates the two rules of RFC 4627: the string was serialized instead of a an object or an array, and the control character U+0000 was not escaped. The standard encoded JSON always detected correctly.

This patch requires "surrogatepass" error handler for utf-16/32 (see issue12892 and issue13916).

----------
assignee: serhiy.storchaka
components: Library (Lib), Unicode
files: json_detect_encoding.patch
keywords: patch
messages: 188442
nosy: ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Autodetecting JSON encoding
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30133/json_detect_encoding.patch

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

From report at bugs.python.org  Sun May  5 22:03:50 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sun, 05 May 2013 20:03:50 +0000
Subject: [New-bugs-announce] [issue17910] Usage error in multiprocessing
	documentation
Message-ID: <1367784230.19.0.495557167576.issue17910@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

"As mentioned above, when doing concurrent programming it is usually best to avoid using shared state as far as possible" should say "as much as possible" in multiprocessing.rst.

----------
assignee: docs at python
components: Documentation
messages: 188461
nosy: amysyk, docs at python
priority: normal
severity: normal
status: open
title: Usage error in multiprocessing documentation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun May  5 23:31:26 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 05 May 2013 21:31:26 +0000
Subject: [New-bugs-announce] [issue17911] Extracting tracebacks does too
	much work
Message-ID: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

For Tulip I may have to extract tracebacks and store the extracted data, in order to avoid cycles created by the frames referenced in the traceback.  I'll be extracting the traceback every time an exception is raised, and in most cases I won't be using the extracted info, because usually the exception is caught (or logged) by user code.  But it's very important to ensure that if the user code doesn't catch or log it, I can log a traceback, and I won't know that this is the case until a destructor is called, which may be quite a bit later.  (Reference: http://code.google.com/p/tulip/source/browse/tulip/futures.py#38)

Unfortunately it looks like the public APIs do a lot more work than needed.  Ideally, there'd be something similar to _extract_tb_or_stack_iter() that doesn't call linecache.getline() -- it should just return triples of (filename, lineno, functionname), and enough structure to tell apart the __cause__, __context__, and __traceback__ (the first two possibly repeated).  Given this info it would be simple enough to format and log the actual traceback, and storing just this would take less space and time than computing the lines of the fully-formatted traceback.

----------
components: Library (Lib)
messages: 188467
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Extracting tracebacks does too much work
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May  6 00:02:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 May 2013 22:02:39 +0000
Subject: [New-bugs-announce] [issue17912] thread states should use a
	doubly-linked list
Message-ID: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Thread states are stored in a singly linked list, which makes some operations more cumbersome than they should be. Since memory consumption is far from critical here, it would be easier to handle them with a doubly linked list.

----------
components: Interpreter Core
messages: 188471
nosy: pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: thread states should use a doubly-linked list
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May  6 11:11:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 06 May 2013 09:11:20 +0000
Subject: [New-bugs-announce] [issue17913] stat.filemode returns "-" for
	sockets and unknown types
Message-ID: <1367831480.84.0.461149512803.issue17913@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The function stat.filemode() has a fallback to "-" for file type when it is unable to properly detect the type of a file. This gives wrong results for any file type that is not in the lookup table.

For example it doesn't check for S_ISSOCK:

>>> s = os.stat("/var/run/sdp") t
>>> stat.filemode(s.st_mode)
'-rw-rw-rw-'
$ ls -la /var/run/sdp
srw-rw-rw- 1 root root 0 Mai  2 16:08 /var/run/sdp

Also see #11016 for more file types.

I'm going to work on the matter soonish.

----------
messages: 188496
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: stat.filemode returns "-" for sockets and unknown types
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May  6 13:06:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 May 2013 11:06:47 +0000
Subject: [New-bugs-announce] [issue17914] add os.cpu_count()
Message-ID: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

multiprocessing.cpu_count() implementation should be made available in the os module, where it belongs.

----------
keywords: easy
messages: 188506
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May  6 13:14:06 2013
From: report at bugs.python.org (Simon Conseil)
Date: Mon, 06 May 2013 11:14:06 +0000
Subject: [New-bugs-announce] [issue17915] Encoding error with sax and codecs
Message-ID: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za>


New submission from Simon Conseil:

There is an encoding issue between codecs.open and sax (see attached file). The issue is reproducible on Python 3.3.1, it is working fine on Python 3.3.0

----------
components: Library (Lib)
files: report.txt
messages: 188508
nosy: sconseil
priority: normal
severity: normal
status: open
title: Encoding error with sax and codecs
versions: Python 3.3
Added file: http://bugs.python.org/file30146/report.txt

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

From report at bugs.python.org  Mon May  6 14:54:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 06 May 2013 12:54:24 +0000
Subject: [New-bugs-announce] [issue17916] Provide dis.Bytecode based
	equivalent of dis.distb
Message-ID: <1367844864.14.0.49825143621.issue17916@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 11816 adds a new dis.Bytecode API that replaces most of the dis functions, but doesn't cover dis.distb.

A dis.Bytecode.from_tb class method, or a TracebackBytecode subclass to handle that use case may be desirable.

----------
messages: 188528
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide dis.Bytecode based equivalent of dis.distb
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May  6 15:10:37 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 06 May 2013 13:10:37 +0000
Subject: [New-bugs-announce] [issue17917] use PyModule_AddIntMacro() instead
	of	PyModule_AddIntConstant() when applicable
Message-ID: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

In many cases, PyModule_AddIntMacro() could be used instead of PyModule_AddIntConstant(), e.g. in socketmodule.c and posixmodule.c:

PyModule_AddIntMacro(m, AF_INET6);

vs (currently)

PyModule_AddIntConstant(m, "AF_INET6", AF_INET6);

It reduces the possibility of typo and is less verbose.

----------
keywords: easy
messages: 188531
nosy: neologix
priority: low
severity: normal
stage: needs patch
status: open
title: use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May  6 16:27:32 2013
From: report at bugs.python.org (Peter Saveliev)
Date: Mon, 06 May 2013 14:27:32 +0000
Subject: [New-bugs-announce] [issue17918] failed incoming SSL connection
	stays open forever
Message-ID: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za>


New submission from Peter Saveliev:

Important: only Python2 versions are affected. Python3 works OK.
Possibly related issue: http://bugs.python.org/issue12378 (differs: see the line above)


Having a server with SSLSocket waiting for connections, the incoming connection, failed on automatic do_handshake(), stays open forever ? accept() raises the SSLError and does not return client connection socket.

Steps to reproduce
==================

server side:

1. create a SOCK_STREAM socket
2. wrap it with wrap_socket()
3. listen()
4. accept()

client side:

1. telnet to this port
2. enter any random text

How reproducible
================

In all 146%

Expected results
================

1. Incoming connection is closed and client disconnected

Actual results
==============

1. On the server side, due to exception, the reference to the incoming connection gets lost.
2. The client stays connected as long as the server operates.

----------
files: ssl_handshake_testcase.py
messages: 188544
nosy: Peter.Saveliev
priority: normal
severity: normal
status: open
title: failed incoming SSL connection stays open forever
type: resource usage
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file30150/ssl_handshake_testcase.py

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

From report at bugs.python.org  Mon May  6 17:06:57 2013
From: report at bugs.python.org (Delhallt)
Date: Mon, 06 May 2013 15:06:57 +0000
Subject: [New-bugs-announce] [issue17919] AIX POLLNVAL definition causes
	problems
Message-ID: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>


New submission from Delhallt:

I encounted exactly the same issue http://bugs.python.org/issue923315 with test_asyncore, test_asynchat and test_poll.

On AIX6.1, POLLNVAL=0x8000=SHRT_MIN=SHRT_MAX+1 (on 2 bytes) and parsing events with PyArg_ParseTuple as a signed short 'h' do not work, i.e
"OverflowError: signed short integer is greater than maximum" occurs.

I changed 'h' to 'H' in the attached patch, and delete associated Overflow test.

Perhaps, they're a better way to handle that ?

----------
components: Extension Modules
files: Python-2.7.4-pollnval.patch
keywords: patch
messages: 188558
nosy: delhallt
priority: normal
severity: normal
status: open
title: AIX POLLNVAL definition causes problems
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30151/Python-2.7.4-pollnval.patch

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

From report at bugs.python.org  Mon May  6 22:22:51 2013
From: report at bugs.python.org (abcdef)
Date: Mon, 06 May 2013 20:22:51 +0000
Subject: [New-bugs-announce] [issue17920] Documentation: "complete ordering"
	should be "total	ordering"
Message-ID: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za>


New submission from abcdef:

The set documentation [http://docs.python.org/3.4/library/stdtypes.html] states

"The subset and equality comparisons do not generalize to a complete ordering function. For example, any two disjoint sets are not equal and are not subsets of each other..."

Could "complete ordering" be changed to "total ordering"? This is the correct mathematical terminology. A total ordering is one where every pair is comparable. A complete ordering is one where each bounded subset has a supremum/infimum (for example, reals form a complete ordered field). This can be verified at Wikipedia [http://en.wikipedia.org/wiki/Total_order] and essentially every set theory book.

----------
assignee: docs at python
components: Documentation
messages: 188585
nosy: abcdef, docs at python
priority: normal
severity: normal
status: open
title: Documentation: "complete ordering" should be "total ordering"
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue May  7 04:18:17 2013
From: report at bugs.python.org (lesmana)
Date: Tue, 07 May 2013 02:18:17 +0000
Subject: [New-bugs-announce] [issue17921] explicit empty check instead of
	implicit booleaness
Message-ID: <1367893097.98.0.624454967229.issue17921@psf.upfronthosting.co.za>


New submission from lesmana:

Python should have a builtin method `isempty()` which calls the special method name `__isempty__()` for explicit emptiness check.

The special method `__isempty__()` should return `True` if the object is "empty" and `False` if the object is "not empty".

Observe emptiness check using implicit booleaness:

    if not somecollection:
      foo()

Note that this code also handles `None`, `0` and `False` silently. If those are possible values then I have to test explicitly:

    if somecollection is not None and not somecollection:
      foo()

Also handling the `0` and `False` cases will make the code really really ugly.

Usually the `None`, `0` or `False` cases only happen in case of a programming error. But if I do not test for them explicitly then they will be handled silently and the error will occur somewhere else in the code.

Compare against explicit emptiness check:

    if not isempty(somecollection):
      foo()

This code will break immediately if somecollection does not have `__isempty__()`. If `None`, `0` or `False` are possible values they will not be handled silently, instead an error will be reported at `isempty()`.

Advantage of explicit emptiness check:

* More explicit and fluently readable code
* No silent implicit booleaness check when code should do emptiness check
* Clearer separation of meaning for the special methods `__len__()` and `__empty__()`

Possible use case for explicit emptiness check: a list with memory effect.

    >>> ml = MemoryEffectList()
    >>> ml.charge()
    >>> ml.discharge()
    >>> isempty(ml)
    True
    >>> len(ml) == 0
    False

----------
components: Interpreter Core
messages: 188617
nosy: lesmana
priority: normal
severity: normal
status: open
title: explicit empty check instead of implicit booleaness
type: enhancement

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

From report at bugs.python.org  Tue May  7 09:38:00 2013
From: report at bugs.python.org (Jan Safranek)
Date: Tue, 07 May 2013 07:38:00 +0000
Subject: [New-bugs-announce] [issue17922] Crash in clear_weakref
Message-ID: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za>


New submission from Jan Safranek:

I have Python 2.7.4 running on Fedora Rawhide and I get segmentation fault with following backtrace:

#0  0x00007f73f69ca5f1 in clear_weakref (self=0x7f73ff515c00) at Objects/weakrefobject.c:56
#1  weakref_dealloc (self=0x7f73ff515c00) at Objects/weakrefobject.c:106
#2  0x00007f73f698ea27 in PyList_SetItem (op=<optimized out>, i=<optimized out>, newitem=<optimized out>) at Objects/listobject.c:218
#3  0x00007f73f69ba9db in add_subclass (type=type at entry=0x7f73e00456b0, base=<optimized out>) at Objects/typeobject.c:4155
#4  0x00007f73f69c440e in PyType_Ready (type=type at entry=0x7f73e00456b0) at Objects/typeobject.c:4120
#5  0x00007f73f69c6d4b in type_new (metatype=<optimized out>, args=<optimized out>, kwds=<optimized out>) at Objects/typeobject.c:2467
#6  0x00007f73f69be7d3 in type_call (type=0x7f73f6cdad00 <PyType_Type>, args=0x7f73f61e1550, kwds=0x0) at Objects/typeobject.c:725
#7  0x00007f73f6954833 in PyObject_Call (func=func at entry=0x7f73f6cdad00 <PyType_Type>, arg=arg at entry=0x7f73f61e1550, kw=kw at entry=0x0) at Objects/abstract.c:2529
#8  0x00007f73f69553c9 in PyObject_CallFunctionObjArgs (callable=callable at entry=0x7f73f6cdad00 <PyType_Type>) at Objects/abstract.c:2760
#9  0x00007f73f6a06bf3 in build_class (name=<optimized out>, bases=0x7f73f61e3910, methods=0x7f73e0045590) at Python/ceval.c:4632
#10 PyEval_EvalFrameEx (f=f at entry=0x7f73e0043a40, throwflag=throwflag at entry=0) at Python/ceval.c:1928
#11 0x00007f73f6a0b46d in PyEval_EvalCodeEx (co=co at entry=0x7f73f61f50b0, globals=globals at entry=0x7f73e003bf00, locals=locals at entry=0x7f73e003bf00, args=args at entry=0x0, argcount=argcount at entry=0, 
    kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#12 0x00007f73f6a0b5a2 in PyEval_EvalCode (co=co at entry=0x7f73f61f50b0, globals=globals at entry=0x7f73e003bf00, locals=locals at entry=0x7f73e003bf00) at Python/ceval.c:667
#13 0x00007f73f6a22cfc in PyImport_ExecCodeModuleEx (name=name at entry=0x7f73e003d760 "warnings", co=co at entry=0x7f73f61f50b0, 
    pathname=pathname at entry=0x7f73e003ac90 "/usr/local/lib/python2.7/warnings.pyc") at Python/import.c:709
#14 0x00007f73f6a2305e in load_source_module (name=0x7f73e003d760 "warnings", pathname=0x7f73e003ac90 "/usr/local/lib/python2.7/warnings.pyc", fp=<optimized out>) at Python/import.c:1099
#15 0x00007f73f6a23f59 in import_submodule (mod=mod at entry=0x7f73f6cd2ec0 <_Py_NoneStruct>, subname=subname at entry=0x7f73e003d760 "warnings", fullname=fullname at entry=0x7f73e003d760 "warnings")
    at Python/import.c:2700
#16 0x00007f73f6a24b93 in load_next (p_buflen=<synthetic pointer>, buf=0x7f73e003d760 "warnings", p_name=<synthetic pointer>, altmod=0x7f73f6cd2ec0 <_Py_NoneStruct>, 
    mod=0x7f73f6cd2ec0 <_Py_NoneStruct>) at Python/import.c:2515
#17 import_module_level (locals=<optimized out>, level=<optimized out>, fromlist=0x7f73f6cd2ec0 <_Py_NoneStruct>, globals=<optimized out>, name=0x0) at Python/import.c:2224
#18 PyImport_ImportModuleLevel (name=0x7f73ff54fbf4 "warnings", globals=<optimized out>, locals=<optimized out>, fromlist=0x7f73f6cd2ec0 <_Py_NoneStruct>, level=<optimized out>)
    at Python/import.c:2288
#19 0x00007f73f6a033af in builtin___import__ (self=<optimized out>, args=<optimized out>, kwds=<optimized out>) at Python/bltinmodule.c:49
...
#61 0x00007f73f6a37dbc in initsite () at Python/pythonrun.c:721
#62 Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:265

(full back trace is attached, it's quite long).

(gdb) py-bt
#10 Frame 0x7f4bf8043df0, for file /usr/lib64/python2.7/warnings.py, line 281, in <module> ()
    class WarningMessage(object):
#23 Frame 0x7f4bf803d300, for file /usr/lib64/python2.7/posixpath.py, line 17, in <module> ()
    import warnings
#36 Frame 0x7f4bf8024fc0, for file /usr/lib64/python2.7/os.py, line 49, in <module> ()
    import posixpath as path
#49 Frame 0x7f4bf801c520, for file /usr/lib64/python2.7/site.py, line 62, in <module> ()
    import os

I get the same crash with vanilla Python 2.7.4 without Fedora patches. Python 2.7.3 works well and doesn't crash.

----------
components: Interpreter Core
files: full-bt.txt
messages: 188629
nosy: jsafrane
priority: normal
severity: normal
status: open
title: Crash in clear_weakref
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file30161/full-bt.txt

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

From report at bugs.python.org  Tue May  7 10:30:10 2013
From: report at bugs.python.org (Delhallt)
Date: Tue, 07 May 2013 08:30:10 +0000
Subject: [New-bugs-announce] [issue17923] test glob with trailing slash fail
Message-ID: <1367915410.77.0.862505044661.issue17923@psf.upfronthosting.co.za>


New submission from Delhallt:

test_glob's trailing_slash tests fails on AIX 6.1/Python 2.7.4:

The code section for no_magic/slash case seems to be the issue.

Attached patch resolves issue.

FAIL: test_glob_directory_with_trailing_slash (test.test_glob.GlobTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/test/test_glob.py", line 120, in test_glob_directory_with_trailing_slash
    self.assertEqual(res, [])
AssertionError: Lists differ: ['@test_7602318_tmp_dir/ZZZ/'] != []

First list contains 1 additional elements.
First extra element 0:
@test_7602318_tmp_dir/ZZZ/

- ['@test_7602318_tmp_dir/ZZZ/']
+ []

======================================================================
FAIL: test_glob_unicode_directory_with_trailing_slash (test.test_glob.GlobTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/freeware/lib/python2.7/test/test_glob.py", line 137, in test_glob_unicode_directory_with_trailing_slash
    self.assertEqual(res, [])
AssertionError: Lists differ: [u'@test_7602318_tmp_dir/ZZZ/'... != []

First list contains 1 additional elements.
First extra element 0:
@test_7602318_tmp_dir/ZZZ/

- [u'@test_7602318_tmp_dir/ZZZ/']
+ []

----------
components: Tests
files: Python-2.7.4-glob.patch
keywords: patch
messages: 188635
nosy: delhallt
priority: normal
severity: normal
status: open
title: test glob with trailing slash fail
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30162/Python-2.7.4-glob.patch

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

From report at bugs.python.org  Tue May  7 14:05:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 07 May 2013 12:05:20 +0000
Subject: [New-bugs-announce] [issue17924] Deprecate stat.S_IF* integer
	constants
Message-ID: <1367928320.73.0.37418131168.issue17924@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Related to #11016
I like to deprecate the S_IF* constants in favor of the S_IS*() functions.

rationals:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html

No new S_IFMT symbolic names for the file type values of mode_t will be defined by POSIX.1-2008; if new file types are required, they will only be testable through S_ISxx() or S_TYPEISxxx() macros instead.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 188641
nosy: christian.heimes, docs at python
priority: normal
severity: normal
status: open
title: Deprecate stat.S_IF* integer constants
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue May  7 15:45:56 2013
From: report at bugs.python.org (Pierrick Koch)
Date: Tue, 07 May 2013 13:45:56 +0000
Subject: [New-bugs-announce] [issue17925] asynchat.async_chat.initiate_send
	: del deque[0] is not	safe
Message-ID: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za>


New submission from Pierrick Koch:

Dear,

del deque[0] is not safe, see the attached patch for the asynchat.async_chat.initiate_send method.
fix the "IndexError: deque index out of range" of "del self.producer_fifo[0]"

Best,
Pierrick Koch

----------
components: Library (Lib)
files: asynchat.async_chat.initiate_send.deldeque.patch
keywords: patch
messages: 188652
nosy: Pierrick.Koch
priority: normal
severity: normal
status: open
title: asynchat.async_chat.initiate_send : del deque[0] is not safe
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file30165/asynchat.async_chat.initiate_send.deldeque.patch

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

From report at bugs.python.org  Tue May  7 17:30:25 2013
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 07 May 2013 15:30:25 +0000
Subject: [New-bugs-announce] [issue17926] PowerLinux dbm failure in 2.7
Message-ID: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za>


New submission from David Edelsohn:

The PowerLinux buildslave fails in test_dbm:test_keys() because of a problem with the "in" operator.

>>> import dbm
>>> d = dbm.open('t','c')
>>> a = [('a', 'b'), ('12345678910', '019237410982340912840198242')]
>>> for k,v in a:
...     d[k] = v
... 
>>> print d
<dbm.dbm object at 0x3fff93073110>
>>> print d.keys()
['a', '12345678910']
>>> print 'a' in d
False      <--- This apparently should be True
>>> print 'a' in d.keys()
True

----------
components: Interpreter Core
messages: 188666
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: PowerLinux dbm failure in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Tue May  7 18:02:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 07 May 2013 16:02:23 +0000
Subject: [New-bugs-announce] [issue17927] Argument copied into cell still
	referenced by frame
Message-ID: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

This came out of some investigations into Tulip reference cycles.  I've only confirmed this with 3.3 and 3.4, but I suspect it's a problem in earlier versions too.

The scenario is as follows.

Consider a object with a method that ends up catching an exception and storing the exception on the object.  We know that the __traceback__ attribute of the exception references the stack frame where the exception was caught, so there is a cycle: self -> exception -> traceback -> frame -> self.  To break this cycle without disturbing the __traceback__ on the exception, the method sets "self = None" before it returns.  (The point of breaking the cycle is that at some later point when the object is deleted the traceback can be printed by the __del__ method.)

This works beautifully...  Except if the function happens to contain a nested function or a lambda that references 'self'.  *Even if the function is never created* (e.g. "if 0: lambda: self").  Then setting "self = None" does not break the cycle.  It's not a real leak, because gc.collect() will collect the cycle.  But it's still annoying that I can't break the cycle (I don't want to break it at any other point because it would reduce the usefulness of the exception stored on the object).

After two days of investigations and thinking about it I found the cause: the presence of the lambda cause a cell to be created into which self is copied, but the original self argument is still referenced by the frame.  Setting "self = None" clears the cell but doesn't affect the original self argument.  (FWIW, this indicates it's not specifically about self, it's about any argument that gets copied into a cell.)

I thought I had a one-line fix (see cellfree.diff attached) but it breaks argument-less super(), which looks at the original first argument.  I think I can fix super() (it must introspect the code object to find out into which cell self has been copied, if it finds it NULL), but I have to think about that more.  If anyone wants to jump in and suggest an approach to that I'd appreciate it.

----------
assignee: gvanrossum
components: Interpreter Core
files: cellfree.diff
keywords: patch
messages: 188672
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument copied into cell still referenced by frame
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file30166/cellfree.diff

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

From report at bugs.python.org  Tue May  7 20:29:22 2013
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 07 May 2013 18:29:22 +0000
Subject: [New-bugs-announce] [issue17928] PowerLinux getargs.c FETCH_SIZE
	endianness bug
Message-ID: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za>


New submission from David Edelsohn:

Another endianness bug that causes a failure in test_structmembers.py.

_testcapi reports "string too long" because getargs.c:PyArg_ParseTupleAndKeywords() incorrectly returns a huge value for string_len.

The problem is FETCH_ARGS is passing the wrong type to va_arg.  It grabs an "int" for the size arg, but that is the not the argument type on 64 bit platforms.  This happens to work for little endian because the low part of the 64 bit argument overlaps correctly.  Big endian is not as fortuitous.

If I change "int" to "long", the testcase succeeds.

diff -r a285ce18bd55 Python/getargs.c
--- a/Python/getargs.c	Mon May 06 18:21:10 2013 -0700
+++ b/Python/getargs.c	Tue May 07 11:26:21 2013 -0700
@@ -582,9 +582,9 @@
               char *msgbuf, size_t bufsize, PyObject **freelist)
 {
     /* For # codes */
-#define FETCH_SIZE      int *q=NULL;Py_ssize_t *q2=NULL;\
+#define FETCH_SIZE      long *q=NULL;Py_ssize_t *q2=NULL;\
     if (flags & FLAG_SIZE_T) q2=va_arg(*p_va, Py_ssize_t*); \
-    else q=va_arg(*p_va, int*);
+    else q=va_arg(*p_va, long*);
 #define STORE_SIZE(s)   \
     if (flags & FLAG_SIZE_T) \
         *q2=s; \

I am not certain exactly what type it should be, but it definitely needs to be a matching 64 bit type of 64 bit platforms.

I believe that this bug exists in all versions.

----------
components: Interpreter Core
messages: 188677
nosy: David.Edelsohn, pitrou
priority: normal
severity: normal
status: open
title: PowerLinux getargs.c FETCH_SIZE endianness bug
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue May  7 21:18:21 2013
From: report at bugs.python.org (Firstname Lastname)
Date: Tue, 07 May 2013 19:18:21 +0000
Subject: [New-bugs-announce] [issue17929] TypeError using tarfile.addfile()
	with io.StringIO	replacing StringIO.StringIO()
Message-ID: <1367954301.44.0.758275221698.issue17929@psf.upfronthosting.co.za>


New submission from Firstname Lastname:

Trying to work with tarfile library and python 3.3 (Ubuntu 13.04 64-bit)

While everything works quite well using StringIO.StringIO() and python 2.7.4, the equivalent code with io.StringIO() and python 3.3.1 doesn't. Is that a bug or am I doing something wrong ?

----------
components: Library (Lib)
files: showbug.py
messages: 188682
nosy: Firstname.Lastname
priority: normal
severity: normal
status: open
title: TypeError using tarfile.addfile() with io.StringIO replacing StringIO.StringIO()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30169/showbug.py

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

From report at bugs.python.org  Tue May  7 23:38:43 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 07 May 2013 21:38:43 +0000
Subject: [New-bugs-announce] [issue17930] Search not needed in
	combinations_with_replacement
Message-ID: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za>


New submission from Tim Peters:

Each time thru, CWR searches for the rightmost position not containing the maximum index.  But this is wholly determined by what happened the last time thru - search isn't really needed.  Here's Python code:

def cwr2(iterable, r):
    pool = tuple(iterable)
    n = len(pool)
    if not n and r:
        return
    indices = [0] * r
    yield tuple(pool[i] for i in indices)
    j = r-1 if n > 1 else -1
    while j >= 0:
        newval = indices[j] + 1
        indices[j:] = [newval] * (r - j)
        yield tuple(pool[i] for i in indices)
        j = r-1 if newval < n-1 else j-1

There `j` is the rightmost position not containing the maximum index.  A little thought suffices to see that the next j is either r-1 (if newval is not the maximum index) or j-1 (if newval is the maximum index:  since the indices vector is non-decreasing, if indices[j] was r-2 then indices[j-1] is also at most r-2).

I don't much care if this goes in, but Raymond should find it amusing so assigning it to him ;-)

----------
assignee: rhettinger
components: Extension Modules
keywords: easy
messages: 188686
nosy: rhettinger, tim_one
priority: low
severity: normal
stage: needs patch
status: open
title: Search not needed in combinations_with_replacement
type: performance
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Wed May  8 00:11:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 May 2013 22:11:49 +0000
Subject: [New-bugs-announce] [issue17931] PyLong_FromPid() is not correctly
	defined on Windows	64-bit
Message-ID: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #1983 was not fixed on Windows: pid_t is HANDLE on Windows, which is a pointer. SIZEOF_PID_T is not defined in PC/pyconfig.h and so longobject.h takes the default implementation (use C long type):

/* Issue #1983: pid_t can be longer than a C long on some systems */
#if !defined(SIZEOF_PID_T) || SIZEOF_PID_T == SIZEOF_INT
#define _Py_PARSE_PID "i"
#define PyLong_FromPid PyLong_FromLong
#define PyLong_AsPid PyLong_AsLong
#elif SIZEOF_PID_T == SIZEOF_LONG
...

The consequence is a compiler warning:

..\Modules\posixmodule.c(6603): warning C4244: 'function' : conversion from 'Py_intptr_t' to 'long', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj]

It would be safer to define SIZEOF_PID_T on Windows:

#define SIZEOF_PID_T SIZEOF_VOID_P

I didn't test attached patch on Windows.

Python 3.2 is affected, but I don't think that the issue is important enough to touch this branch (which now only accept security fixes).

See also issue #17870.

----------
components: Windows
files: win_sizeof_pid_t.patch
keywords: patch
messages: 188688
nosy: haypo, serhiy.storchaka, tim.golden
priority: normal
severity: normal
status: open
title: PyLong_FromPid() is not correctly defined on Windows 64-bit
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30170/win_sizeof_pid_t.patch

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

From report at bugs.python.org  Wed May  8 00:38:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 May 2013 22:38:35 +0000
Subject: [New-bugs-announce] [issue17932] Win64: possible integer overflow
	in iterobject.c
Message-ID: <1367966315.05.0.262623510238.issue17932@psf.upfronthosting.co.za>


New submission from STINNER Victor:

seqiterobject.it_index type is long, whereas iter_setstate() uses a Py_ssize_t. It would be safer to use Py_ssize_t type for seqiterobject.it_index.

The issue emits a compiler warning on Windows 64-bit.

iterator.__getstate__() was introduced in Python 3.3, so older versions are not affected.

----------
files: iter_ssize_t.patch
keywords: patch
messages: 188691
nosy: haypo
priority: normal
severity: normal
status: open
title: Win64: possible integer overflow in iterobject.c
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30171/iter_ssize_t.patch

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

From report at bugs.python.org  Wed May  8 02:50:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 May 2013 00:50:24 +0000
Subject: [New-bugs-announce] [issue17933] test_ftp failure / ftplib error
	formatting issue
Message-ID: <1367974224.67.0.224732033427.issue17933@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The following error appeared on some buildbots:
http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/4195/steps/test/logs/stdio

======================================================================
ERROR: test_ftp (test.test_urllib2net.OtherNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 2337, in retrfile
    self.ftp.cwd(file)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 622, in cwd
    return self.voidcmd(cmd)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 272, in voidcmd
    return self.voidresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 245, in voidresp
    resp = self.getresp()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 240, in getresp
    raise error_perm(resp)
ftplib.error_perm: 550 Failed to change directory.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 112, in test_ftp
    self._test_urls(urls, self._extra_handlers())
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 218, in _test_urls
    f = urlopen(url, req, TIMEOUT)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 33, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice
    return func(*args, **kwargs)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 462, in open
    response = self._open(req, data)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 480, in _open
    '_open', req)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 440, in _call_chain
    result = func(*args)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 1464, in ftp_open
    fp, retrlen = fw.retrfile(file, type)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 2339, in retrfile
    raise URLError('ftp error: %d' % reason) from reason
TypeError: %d format: a number is required, not error_perm

----------
components: Library (Lib), Tests
messages: 188699
nosy: giampaolo.rodola, pitrou, r.david.murray
priority: high
severity: normal
stage: needs patch
status: open
title: test_ftp failure / ftplib error formatting issue
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May  8 13:54:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 May 2013 11:54:02 +0000
Subject: [New-bugs-announce] [issue17934] Add a frame method to clear
	expensive details
Message-ID: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I think we may want to add a finalize() or close() method on frame objects which would clear all local variables (as well as dereference the globals dict, perhaps), after having optionally run a generator's close() method (if the frame belongs to a generator).

If I'm not mistaken, it should allow breaking reference cycles, and remove the need for complex traceback processing, which Twisted currently also does: http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py#L89

Note that generator cleanup through the frame has a patch in issue17807.

(spinned off from issue17911)

----------
components: Interpreter Core
messages: 188718
nosy: ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a frame method to clear expensive details
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed May  8 14:03:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 May 2013 12:03:24 +0000
Subject: [New-bugs-announce] [issue17935] Failed compile on XP buildbot
Message-ID: <1368014604.67.0.545390884341.issue17935@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

OpenSSL fails compiling on the XP-4 buildbot. Judging by the errors below (snipped), the nasm version may be too old (?) to understand some of the assembler instructions used in the source. David, could you perhaps take a look?

http://buildbot.python.org/all/buildslaves/bolen-windows


Build:
  cd "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\"
  "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\python_d.exe" build_ssl.py Release Win32 -a
  
  Found a working perl at 'c:\Perl\bin\perl.exe'
  Executing ssl makefiles: nmake /nologo -f "ms\nt.mak"
  Building OpenSSL
  	nasm -f win32 -o tmp32\sha1-586.obj tmp32\sha1-586.asm
  tmp32\sha1-586.asm:2646: warning: label alone on a line without a colon might be in error
  tmp32\sha1-586.asm:2647: error: parser: instruction expected
  tmp32\sha1-586.asm:2648: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2648: error: parser: instruction expected
  tmp32\sha1-586.asm:2649: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2649: error: parser: instruction expected
  tmp32\sha1-586.asm:2650: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2650: error: parser: instruction expected
  tmp32\sha1-586.asm:2651: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2651: error: parser: instruction expected
  tmp32\sha1-586.asm:2658: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2658: error: parser: instruction expected
  tmp32\sha1-586.asm:2659: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2659: error: parser: instruction expected
  tmp32\sha1-586.asm:2660: error: symbol `vmovdqa' redefined
  tmp32\sha1-586.asm:2660: error: parser: instruction expected
  tmp32\sha1-586.asm:2662: error: symbol `vmovdqa' redefined

----------
components: Build
keywords: buildbot
messages: 188720
nosy: db3l, loewis, pitrou
priority: high
severity: normal
status: open
title: Failed compile on XP buildbot
type: compile error
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May  8 17:58:46 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 08 May 2013 15:58:46 +0000
Subject: [New-bugs-announce] [issue17936] O(2) behaviour when
	adding/removing classes
Message-ID: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

We came across this curious phenomenon, when our progam was leaking dynamically created classes.  It started spending CPU, to be fixed when gc  was increased.  The attached .py file demonstrates the problem.

The problem is due to how child classes are added to the parent class, in this case, "object".  Obsolete code tries to look for a NULL pointer in the entire list of children.

In addition, removing child classes is unnecessarily slow.

the attached patch fixes these performance issues.

----------
components: Interpreter Core
files: slowness.py
keywords: patch
messages: 188724
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: O(2) behaviour when adding/removing classes
type: performance
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30178/slowness.py

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

From report at bugs.python.org  Wed May  8 23:14:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 08 May 2013 21:14:26 +0000
Subject: [New-bugs-announce] [issue17937] Collect garbage harder at shutdown
Message-ID: <1368047666.23.0.340381721586.issue17937@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a patch to collect cyclic garbage one more time when all modules have been cleared.

----------
components: Interpreter Core
files: gc_hard.patch
keywords: patch
messages: 188736
nosy: pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Collect garbage harder at shutdown
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file30180/gc_hard.patch

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

From report at bugs.python.org  Wed May  8 23:27:10 2013
From: report at bugs.python.org (Stefan Chrobot)
Date: Wed, 08 May 2013 21:27:10 +0000
Subject: [New-bugs-announce] [issue17938] Duplicate text in
	docs/reference/import statement
Message-ID: <1368048430.97.0.564979420355.issue17938@psf.upfronthosting.co.za>


New submission from Stefan Chrobot:

http://docs.python.org/3/reference/simple_stmts.html#the-import-statement

After the "Examples", there's a duplicated paragraph:

The public names defined by a module are determined by checking the module?s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module?s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module).

The from form with * may only occur in a module scope. Attempting to use it in class or function definitions will raise a SyntaxError.

The public names defined by a module are determined by checking the module?s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module?s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module).

The from form with * may only occur in a module scope. The wild card form of import ? import * ? is only allowed at the module level. Attempting to use it in class or function definitions will raise a SyntaxError.

----------
assignee: docs at python
components: Documentation
messages: 188737
nosy: docs at python, stefanchrobot
priority: normal
severity: normal
status: open
title: Duplicate text in docs/reference/import statement
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed May  8 23:31:39 2013
From: report at bugs.python.org (Stefan Chrobot)
Date: Wed, 08 May 2013 21:31:39 +0000
Subject: [New-bugs-announce] [issue17939] Misleading information about slice
	assignment in docs
Message-ID: <1368048699.98.0.203661524608.issue17939@psf.upfronthosting.co.za>


New submission from Stefan Chrobot:

http://docs.python.org/3/reference/simple_stmts.html#assignment-statements

The docs says:

"If the target is a slicing: The primary expression in the reference is evaluated. It should yield a mutable sequence object (such as a list). The assigned object should be a sequence object of the same type."

This seems wrong, because the assigned object can be any iterable:

a = [4, 5, 6]
a[0:0] = range(1, 4)
# a is now [1, 2, 3, 4, 5, 6]

----------
assignee: docs at python
components: Documentation
messages: 188738
nosy: docs at python, stefanchrobot
priority: normal
severity: normal
status: open
title: Misleading information about slice assignment in docs
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May  9 00:32:30 2013
From: report at bugs.python.org (Alex)
Date: Wed, 08 May 2013 22:32:30 +0000
Subject: [New-bugs-announce] [issue17940] extra code in argparse.py
Message-ID: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za>


New submission from Alex:

In class HelpFormatter, class _Section, format_help(self)
(lines 199 & 200), the two lines

            for func, args in self.items:
                func(*args)

aren't necessary; the results of func are ignored.
"func" is applied (again) on the next line when the
output is joined into item_help.

Cheers
.a

----------
components: Library (Lib)
messages: 188742
nosy: aho
priority: normal
severity: normal
status: open
title: extra code in argparse.py
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu May  9 05:46:56 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 09 May 2013 03:46:56 +0000
Subject: [New-bugs-announce] [issue17941] namedtuple should support fully
	qualified name for more	portable pickling
Message-ID: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

[this came up as part of the Enum discussions. Full details in this thread: http://mail.python.org/pipermail/python-dev/2013-May/126076.html]

namedtuple currently uses this code to obtain the __module__ for the class it creates dynamically so that pickling works:

  result.__module__ = _sys._getframe(1).f_globals.get('__name__', '__main__')

This may not work correctly on all Python implementations, for example IronPython.

To support some way to pickle on all implementations, namedtuple should support a fully qualified name for the class: 

  Point = namedtuple('mymodule.Point', ['x', 'y'])

If the name is a qualified dotted name, it will be split and the first part becomes the __module__.

----------
components: Library (Lib)
messages: 188748
nosy: eli.bendersky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: namedtuple should support fully qualified name for more portable pickling
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu May  9 07:20:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 May 2013 05:20:18 +0000
Subject: [New-bugs-announce] [issue17942] IDLE Debugger: names,
	values misaligned
Message-ID: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The IDLE debugger has subwindows to display name-object bindings for locals and (optionally) globals. They have a gray background. Text is black, object strings get a white background box. The issue is that the white box and text for each name is slightly raised relative to the name. This is somehow especially noticeable to me for something like 'd = 3', resulting in
d3
with 3 boxed and raised a bit so it almost looks like a superscript.

This is a fairly minor issue, so low priority now unless trivially fixed. But it should be part of polishing IDLE. I am hoping that this is not a tk bug that is terrible to work around.

----------
components: IDLE
messages: 188752
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE Debugger: names, values misaligned
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu May  9 08:13:39 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 May 2013 06:13:39 +0000
Subject: [New-bugs-announce] [issue17943] AttributeError: 'long' object has
	no attribute 'release'	in Queue.put()
Message-ID: <1368080019.56.0.453263213436.issue17943@psf.upfronthosting.co.za>


New submission from Georg Brandl:

I'm a bit puzzled by this exception in a long-running process
(running on Python 2.7.3):

...
  File "/usr/lib/python2.7/Queue.py", line 138, in put
    self.not_empty.notify()
        item                 = ('message', '\x80\x02]q\x01(U\x05nicosq\x02GA\xd4b\xccu\xb0\xc0\xcaK\x15U\x01\nNU\x00e.')
        self                 = <Queue.Queue instance at 0x7f1d9c1c9e18>
        block                = False
        timeout              = None

  File "/usr/lib/python2.7/threading.py", line 288, in notify
    waiter.release()
        waiter               = 7128680L
        self                 = <Condition(<thread.lock object at 0x24a5590>, 1)>
        _Condition__waiters  = [7128680L]
        waiters              = [7128680L]
        n                    = 1

AttributeError: 'long' object has no attribute 'release'


As far as I can see, there should only ever be lock objects in the self.__waiters list.  Does anyone see a possible reason for the long object to end up there?  (Sadly I can't debug the process anymore.)

----------
messages: 188753
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: AttributeError: 'long' object has no attribute 'release' in Queue.put()
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu May  9 11:57:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 May 2013 09:57:50 +0000
Subject: [New-bugs-announce] [issue17944] Refactor test_zipfile
Message-ID: <1368093470.65.0.477520947191.issue17944@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which refactors test_zipfile, decreases it's size by 269 lines, makes adding tests for new compression types and new tests for all compression types simpler, and makes test_zipfile discoverable.

----------
components: Tests
files: test_zipfile.patch
keywords: patch
messages: 188760
nosy: alanmcintyre, ezio.melotti, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Refactor test_zipfile
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30182/test_zipfile.patch

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

From report at bugs.python.org  Thu May  9 16:36:22 2013
From: report at bugs.python.org (Gregory HOULDSWORTH)
Date: Thu, 09 May 2013 14:36:22 +0000
Subject: [New-bugs-announce] [issue17945] tkinter/Python 3.3.0: peer_create
	doesn't instantiate	Text
Message-ID: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za>


New submission from Gregory HOULDSWORTH:

Python version: 3.3.0 32bit
OS: Windows 7 Service Pack 1 64bit

The peer_create method of the Text class, introduced in changeset
<71041c0dedd5> in response to issue <2843> creates a tk text widget
but does not instantiate Text. Because they don't exist as Python
objects, we have to use tk.call() to manipulate them. This also breaks
the nametowidget method used with Text's peer_names, again because
these widgets don't exist in Python.

Following the inheritance of Text in /Lib/tkinter/__init__.py:2039
Text > Widget > BaseWidget, where the actual widget creation occurs
with a call to self.tk.call:

self.tk.call(
            (widgetName, self._w) + extra + self._options(cnf))

We cannot smuggle in the tk command '.myoriginaltext peer create' as
a tuple in place of the widgetName ('text') because we end up with the
malformed argument:

((.myoriginaltext, 'peer', 'create'), .peer.path ...)

The attached file is my second attempt, using subclassing.
Lot of code duplication, ugly and not thoroughly tested: I'm hoping a
more elegant solution can be found.

----------
components: Tkinter
files: pythonlevelpeers.py
messages: 188778
nosy: ghoul, gpolo
priority: normal
severity: normal
status: open
title: tkinter/Python 3.3.0: peer_create doesn't instantiate Text
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30183/pythonlevelpeers.py

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

From report at bugs.python.org  Thu May  9 20:05:16 2013
From: report at bugs.python.org (Lucas Clemente Vella)
Date: Thu, 09 May 2013 18:05:16 +0000
Subject: [New-bugs-announce] [issue17946] base64 encoding result should be
	str, not bytes
Message-ID: <1368122716.0.0.40098064467.issue17946@psf.upfronthosting.co.za>


New submission from Lucas Clemente Vella:

As stated in RFC 3548:

   Base encoding of data is used in many situations to store or transfer
   data in environments that, perhaps for legacy reasons, are restricted
   to only US-ASCII [9] data.

thus, I was surprised to see, when I used base64 for the first time in python 3, that the encodig result was bytes, not str. Well, if I am encoding something to base64, I am most certainly needing it as a printable ASCII string, not as an binary byte array.

Thus, I suggest that the output of:
   base64.b64encode(data)
to be, instead, the output of:
   base64.b64encode(data).decode('ascii')

----------
components: Library (Lib)
messages: 188786
nosy: Lucas.Vella
priority: normal
severity: normal
status: open
title: base64 encoding result should be str, not bytes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri May 10 08:50:00 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 10 May 2013 06:50:00 +0000
Subject: [New-bugs-announce] [issue17947] Code, test,
	and doc review for PEP-0435 Enum
Message-ID: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za>


New submission from Ethan Furman:

PEP-0435 has been approved!

Now for lots of code review.

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: ref435.py
hgrepos: 189
messages: 188812
nosy: barry, docs at python, eli.bendersky, stoneleaf
priority: normal
severity: normal
status: open
title: Code, test, and doc review for PEP-0435 Enum
versions: Python 3.4
Added file: http://bugs.python.org/file30191/ref435.py

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

From report at bugs.python.org  Fri May 10 09:43:49 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIFZpZGFsIFBhbmFsw6lz?=)
Date: Fri, 10 May 2013 07:43:49 +0000
Subject: [New-bugs-announce] [issue17948] HTTPS and sending a big file size
	hangs.
Message-ID: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za>


New submission from Jes?s Vidal Panal?s:

This bug was found using Mercurial. All the information it's on this bug link http://bz.selenic.com/show_bug.cgi?id=3905

The bug was introduced on 2.7.3, previous versions works fine.

----------
components: Windows
messages: 188816
nosy: jesusvpct
priority: normal
severity: normal
status: open
title: HTTPS and sending a big file size hangs.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri May 10 18:26:22 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 10 May 2013 16:26:22 +0000
Subject: [New-bugs-announce] [issue17949] operator documentation mixup
Message-ID: <1368203182.3.0.318883699217.issue17949@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

Rev 83684 (http://hg.python.org/cpython/rev/5885c02120f0) managed to move the `attrgetter()` `versionadded` and `versionchanged` notes down to the `itemgetter()` documentation instead, by moving the `itemgetter()` signature *up* above these lines.

Now the docs claim `itemgetter()` gained support for dotted attributes in version 2.6, which makes no sense, and there is another set of added and changed notes lower down in the same section.

This patch puts the `itemgetter()` signature back in the correct location.

----------
assignee: docs at python
components: Documentation
files: operator_documentation_fix.patch
keywords: patch
messages: 188846
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: operator documentation mixup
versions: Python 2.7
Added file: http://bugs.python.org/file30198/operator_documentation_fix.patch

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

From report at bugs.python.org  Fri May 10 22:22:24 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 10 May 2013 20:22:24 +0000
Subject: [New-bugs-announce] [issue17950] Dynamic classes contain
	non-breakable reference cycles
Message-ID: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

Classes contain two kinds of cycles back to themselves:
1) in their __mro_  list, the class itself is typically the first member.
2) in the descriptors for various fields such as __dict__.

The problem here is that there is no way to break the cycle.  A class that is dynamically created (e.g. in a function) and then not needed, will stick around until garbage collection is performed.

This happens in spite of attempts within the core to avoid such cycles.  For instance, the type's tp_subclasses list contains to avoid a cycle between a baseclass and its parent.

A .py file demonstrating the problem is attached.

A patch is attached that resolves the issue:
1) the mro tuple in the type object is "nerfed" to contain a Py_None reference in its first place, where it previously held the cyclic reference to the type object itself.  This is then "fixed" in place where required.  the __mro__ attribute becomes a getter that duplicates the tuple.

2) the descriptors are modified to hold a weak-reference to the target type, rather than a strong reference.

3) Fix process cleanup.  The thread state cannot be released until after the cleanup of e.g. PySet_Fini() because the freeing of objects in there requires the DUSTBIN_SAFE macros that require the thread state.  Cleanup behaviour probably changed since objects go away on their own now.

4) changes to test_gc.py in the testsuite reflecting the changed behaviour

The patched code passes all the testsuite.

----------
components: Interpreter Core
files: classleak.patch
keywords: patch
messages: 188875
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Dynamic classes contain non-breakable reference cycles
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file30207/classleak.patch

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

From report at bugs.python.org  Sat May 11 01:23:24 2013
From: report at bugs.python.org (Catalin Patulea)
Date: Fri, 10 May 2013 23:23:24 +0000
Subject: [New-bugs-announce] [issue17951] TypeError during gdb backtracing
Message-ID: <1368228204.29.0.543705311064.issue17951@psf.upfronthosting.co.za>


New submission from Catalin Patulea:

With libpython.py loaded in gdb, when backtracing and trying to pretty-print frame objects along the way, this error is sometimes raised:

Python Exception <type 'exceptions.TypeError'> object of type 'FakeRepr' has no len()

See attached patch against tip.

----------
components: Demos and Tools
files: libpython-typeerror-str.patch
keywords: patch
messages: 188888
nosy: Catalin.Patulea, dmalcolm
priority: normal
severity: normal
status: open
title: TypeError during gdb backtracing
type: behavior
Added file: http://bugs.python.org/file30212/libpython-typeerror-str.patch

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

From report at bugs.python.org  Sat May 11 09:45:52 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 May 2013 07:45:52 +0000
Subject: [New-bugs-announce] [issue17952] setup#editors-and-tools
Message-ID: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

2nd paragraph of http://docs.python.org/devguide/setup#editors-and-tools does not look accurate. It implies that there would be some mention of text editor in the given link, but I could not find it.

----------
components: Devguide
messages: 188900
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: setup#editors-and-tools

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

From report at bugs.python.org  Sat May 11 10:23:33 2013
From: report at bugs.python.org (ProgVal)
Date: Sat, 11 May 2013 08:23:33 +0000
Subject: [New-bugs-announce] [issue17953] sys.modules cannot be reassigned
Message-ID: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za>


New submission from ProgVal:

In Python 3.3 (I did not test with 3.4), sys.modules cannot be reassigned without breaking the import mechanism; while it works with Python <= 3.2.

Here is how to reproduce the bug:

progval at Andromede:/tmp$ mkdir test_imports
progval at Andromede:/tmp$ echo "from . import module" > test_imports/__init__.py
progval at Andromede:/tmp$ echo "print('foo')" > test_imports/module.py
progval at Andromede:/tmp$ python3.3
Python 3.3.1 (default, Apr  6 2013, 13:58:40) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules = dict(sys.modules)
>>> import test_imports
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./test_imports/__init__.py", line 1, in <module>
    from . import module
SystemError: Parent module 'test_imports' not loaded, cannot perform relative import
>>> 
progval at Andromede:/tmp$ python3.2
Python 3.2.3 (default, May  6 2013, 01:46:35) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules = dict(sys.modules)
>>> import test_imports
foo
>>>

----------
components: Interpreter Core
messages: 188901
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: sys.modules cannot be reassigned
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May 11 15:55:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 May 2013 13:55:34 +0000
Subject: [New-bugs-announce] [issue17954] Support creation of extensible
	enums through metaclass	subclassing
Message-ID: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Guido chose to follow Java in enforcing the invariant "Enum members are instances of that Enum" for PEP 435 (i.e. "assert (all(isinstance(x, SomeEnum) for x in SomeEnum)"). As a consequence, the Enum metaclass prevents subclassing of Enums with defined members.

This is a reasonable design choice, but one that limits the applicability of the standard library enum solution for use cases that currently rely on this feature of a custom enum implementation (including flufl.enum, the original inspiration for this feature).

An alternative reasonable design choice is to allow extension of enumerations (similar to flufl.enum) and relax the invariant to "Enum members are an instance of that Enum or an Enum-derived parent class of that Enum" (i.e. "assert (all(issubclass(type(x), Enum) and type(x) in SomeEnum.mro() for x in SomeEnum)")

There is no need to support this directly in the standard library, but it would be valuable to make it straightforward to support in an Enum variant by subclassing the standard metaclass (similar to the customisation mechanisms provided to support things like autonumbered enums through a derived metaclass). Currently, implementing this behaviour involves overriding a private method of the metaclass (EnumMetaclass._get_mixins)

----------
messages: 188920
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Support creation of extensible enums through metaclass subclassing
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat May 11 17:59:22 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 11 May 2013 15:59:22 +0000
Subject: [New-bugs-announce] [issue17955] Minor updates to Functional HOWTO
Message-ID: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

I read through the 3.x Functional HOWTO, and it only seems to require a few minor updates.  The attached patch:

* adds a forward link to skip the theoretical discussion in the first section.
* remove stray extra comma
* clarify what filterfalse() is the opposite of.
* (more significant) Describe compress(), the combinatoric functions in their own section, and accumulate().

----------
assignee: docs at python
components: Documentation
files: functional.txt
messages: 188931
nosy: akuchling, docs at python
priority: low
severity: normal
stage: patch review
status: open
title: Minor updates to Functional HOWTO
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30219/functional.txt

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

From report at bugs.python.org  Sat May 11 19:45:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 11 May 2013 17:45:42 +0000
Subject: [New-bugs-announce] [issue17956] add ScheduledExecutor
Message-ID: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Here's an implementation of a new ScheduledExecutor abstract class, with a concrete ScheduledThreadPoolExecutor implementation (see #995907).
The aim is to provide a flexible, efficient and consistent framework for delayed and periodic tasks, leveraging on futures. Incidentally, this supersedes threading.Timer, which is quite fragile and inefficient.

Here's a patch with test (I didn't write the documentation, I prefer to have some feedback first :-), the API is complete.

There's one thing that bothers me with the current implementation: when a future is cancelled, like for regular ThreadPoolExecutor, it doesn't get removed from the work queue right away, but only when it gets dequeued. For a delayed future, this means that one has to wait for the next scheduled execution (i.e. worst case <now> + future.period) for it to be  effectively cancelled and removed from the queue, and for the executor to be shutdown. I'm considering using a callback (Future.add_done_callback()), that's kind of hackish but I don't see any other way.

----------
components: Library (Lib)
files: scheduled-1.diff
keywords: needs review, patch
messages: 188935
nosy: neologix, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: add ScheduledExecutor
type: enhancement
Added file: http://bugs.python.org/file30221/scheduled-1.diff

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

From report at bugs.python.org  Sun May 12 00:20:43 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 11 May 2013 22:20:43 +0000
Subject: [New-bugs-announce] [issue17957] remove outdated (and unexcellent)
	paragraph in whatsnew
Message-ID: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

The first part looks incomplete, and the second part is outdated. The whole paragraph doesn't add much value I believe, so should just go.

----------
assignee: docs at python
components: Documentation
files: diff
messages: 188962
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: remove outdated (and unexcellent) paragraph in whatsnew
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30227/diff

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

From report at bugs.python.org  Sun May 12 07:36:48 2013
From: report at bugs.python.org (Alex Rhatushnyak)
Date: Sun, 12 May 2013 05:36:48 +0000
Subject: [New-bugs-announce] [issue17958] int(math.log(2**i, 2))
Message-ID: <1368337008.23.0.437998264924.issue17958@psf.upfronthosting.co.za>


New submission from Alex Rhatushnyak:

In Python 2.7.4:

import math
for i in range(40, 55):  print int(math.log(2**i, 2)),

output:

40 41 42 43 44 45 46 46 48 49 49 50 52 53 53

----------
messages: 188976
nosy: Alex.Rhatushnyak
priority: normal
severity: normal
status: open
title: int(math.log(2**i, 2))
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun May 12 08:51:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 May 2013 06:51:37 +0000
Subject: [New-bugs-announce] [issue17959] Alternate approach to aliasing for
	PEP 435
Message-ID: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Creating this as a separate issue so as not to delay incorporation of the accepted PEP.

One legitimate criticism of the accepted PEP 435 is that the combination of requiring explicit assignment of values *and* allowing aliasing by default is that aliases may be created inadvertently. I believe we can actually do better than the initial implementation by making the following work:

>>> class Shape(Enum):
...   square = 2
...   diamond = 1
...   circle = 3
...   alias_for_square = square
...
>>> Shape.square
<Shape.square: 2>
>>> Shape.alias_for_square
<Shape.square: 2>
>>> Shape(2)
<Shape.square: 2>

While *disallowing* the following: 

>>> class Shape(Enum):
...   square = 2
...   diamond = 1
...   circle = 3
...   alias_for_square = 2
...

How, do you ask? By wrapping non-descriptors on assignment in a placeholder type, and keeping track of which values we have already seen. If a new attribute is mapped to a placeholder, then that's fine, we accept it as an explicit declaration of an alias. However, if it's mapped directly to a repeat value, then that would be disallowed (as it was in earlier versions of the PEP).

----------
messages: 188981
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Alternate approach to aliasing for PEP 435
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun May 12 09:46:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 May 2013 07:46:47 +0000
Subject: [New-bugs-announce] [issue17960] Clarify the required behaviour of
	locals()
Message-ID: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As proposed at [1], I would like to tighten up the definition of locals so that defining enum members programmatically is officially supported behaviour.

I'll come up with a patch soonish.

[1] http://mail.python.org/pipermail/python-dev/2013-May/125917.html

----------
assignee: ncoghlan
components: Documentation
messages: 188986
nosy: benjamin.peterson, gvanrossum, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify the required behaviour of locals()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun May 12 12:57:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 May 2013 10:57:02 +0000
Subject: [New-bugs-announce] [issue17961] Use enum names as values in
	enum.Enum convenience API
Message-ID: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I encountered an interesting suggestion [1] regarding the enum.Enum convenience API: use the member names as their values, rather than the current integers starting from one.

Since we're now using definition order rather than value order for iteration, this suggestion makes a lot of sense to me.

(again, posting this as something to consider after the accepted PEP is incorporated)

[1] http://www.acooke.org/cute/Pythonssad0.html

----------
messages: 189013
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Use enum names as values in enum.Enum convenience API
type: enhancement

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

From report at bugs.python.org  Sun May 12 13:24:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 May 2013 11:24:05 +0000
Subject: [New-bugs-announce] [issue17962] Broken OpenSSL version in Windows
	builds
Message-ID: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

3.3 and default are currently fetching OpenSSL 1.0.1d for the Windows builds.

It seems OpenSSL 1.0.1d was a kind of "brown paper bag" release, they've released 1.0.1e since (some of test_ssl can fail on 1.0.1d and succeed on 1.0.1e, as experienced on my Linux setup; the Windows buildbots also exhibit similar failures).

Following is their description of the fix:

?Changes between 1.0.1d and 1.0.1e [11 Feb 2013]

  *) Correct fix for CVE-2013-0169. The original didn't work on AES-NI
     supporting platforms or when small records were transferred.
     [Andy Polyakov, Steve Henson]?

----------
components: Build, Windows
messages: 189018
nosy: georg.brandl, larry, loewis, pitrou
priority: release blocker
severity: normal
status: open
title: Broken OpenSSL version in Windows builds
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 12 15:09:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 May 2013 13:09:13 +0000
Subject: [New-bugs-announce] [issue17963] Deprecate the frame hack for
	implicitly getting module	details
Message-ID: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

(Split off from issue 17947)

collections.namedtuple includes a frame hack that attempts to make the functional API work for ordinary module level assignments:

    try:
        result.__module__ = _sys._getframe(1).f_globals.get('__name__', '__main__')
    except (AttributeError, ValueError):
        pass


I *really* don't like the fact that this hack is being incorporated into the PEP 435 implementation as well, when that API has been designed to include an explicit cross-implementation workaround for this case.

Eli asked me to move the discussion over to a new issue to allow the implementation issue to focus on incorporating the PEP as is.

Issue 17941 (the explicit module keyword-only argument) suggest incorporating PEP 435's robust, cross-implementation way to support pickling in the functional API into collection namedtuple as well, suggesting to me that the frame hack should be deprecated, not propagated further.

The main reason I don't like it is not the fact it doesn't work reliably on other implementations, but the fact it doesn't work reliably in CPython either - if you create a helper function, then the frame hack will pick up the module where the helper function lives rather than where you ultimately store the created object. Without some explicit way of telling the created object the final destination (whether through an argument or through new syntax and a name binding protocol), I don't see a way to resolve this dilemna in a robust way.

However, Guido tells me that he really wants to keep the frame hack (and include it for PEP 435 as well), so this issue is basically about documenting that rationale somewhere.

----------
assignee: gvanrossum
messages: 189028
nosy: eli.bendersky, gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Deprecate the frame hack for implicitly getting module details
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May 13 01:58:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 May 2013 23:58:36 +0000
Subject: [New-bugs-announce] [issue17964] os.sysconf(): return type of the C
	function sysconf() is	long, not int
Message-ID: <1368403116.83.0.700816018997.issue17964@psf.upfronthosting.co.za>


New submission from STINNER Victor:

According to POSIX and my manual page on Linux, sysconf() return type is long (and not int).
http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html

It may not mater in practice because most sysconf() results are smaller than 1000, and I failed to find a value bigger than 2 millions.

----------
files: sysconf_long.patch
keywords: patch
messages: 189078
nosy: haypo
priority: normal
severity: normal
status: open
title: os.sysconf(): return type of the C function sysconf() is long, not int
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30242/sysconf_long.patch

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

From report at bugs.python.org  Mon May 13 04:23:29 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 13 May 2013 02:23:29 +0000
Subject: [New-bugs-announce] [issue17965] argparse does not dest.replace('-',
	'_')  for postionals
Message-ID: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za>


New submission from paul j3:

"16.4.3.11. dest
For optional argument actions,... Any internal - characters will be converted to _ characters to make sure the string is a valid attribute name."

In _get_optional_kwargs(), dest = dest.replace('-', '_'); but there is nothing like this in _get_positional_kwargs()

Thus if

   parser.add_argument('foo-bar',...)

this attribute can only be accessed with 

   getattr(namespace, 'foo-bar').

Alternatives:
- ignore this since no one has complained about it
- stress in the documentation that the positionals name should be a valid python attribute name
- test the name during add_argument
- add the dest.replace('-','_') to positionals

But as things stand, even an optional can be given a weird dest - 

    a=p.add_argument('--foo*[]-bar')

requiring

    getattr(args,'foo*[]_bar')

I assume that optionals have this dash replacement because historically some unix (or other) programs have accepted options like '--foo-bar' (though off hand I can't think of any).

----------
components: Library (Lib)
messages: 189090
nosy: paul.j3
priority: normal
severity: normal
status: open
title: argparse does not dest.replace('-', '_')  for postionals
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May 13 06:08:36 2013
From: report at bugs.python.org (Paul Jurczak)
Date: Mon, 13 May 2013 04:08:36 +0000
Subject: [New-bugs-announce] [issue17966] Lack of consistency in PEP 8 --
	Style Guide for Python	Code
Message-ID: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za>


New submission from Paul Jurczak:

This may be too subjective, but here it goes:

PEP 8 discourages vertical alignment: "More than one space around an assignment (or other) operator to align it with another", but contrary to this rule, vertical alignment is used many times in the same paragraph, e.g.:
Yes: spam(1)
No:  spam (1)
If vertical alignment is so evil, the above should be changed to:
Yes: spam(1)
No: spam (1)

Disclosure: I use vertical alignment in my code quite often.

http://www.python.org/dev/peps/pep-0008/

----------
assignee: docs at python
components: Documentation
messages: 189093
nosy: docs at python, pauljurczak
priority: normal
severity: normal
status: open
title: Lack of consistency in PEP 8 -- Style Guide for Python Code
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon May 13 07:50:09 2013
From: report at bugs.python.org (zhaoqifa)
Date: Mon, 13 May 2013 05:50:09 +0000
Subject: [New-bugs-announce] [issue17967] urllib2.open failed to access a
	url when a perent	directory of the url is permission denied
Message-ID: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za>


New submission from zhaoqifa:

urllib2.open failed to access a url when a perent directory of the url is permission denied.

I had a file in a ftp, the address is like ftp://host/home/work/123.txt which can be access by wget.
When I urllib2.open to access the file, it always tell me that:
urllib2.URLError: <urlopen error ftp error: 550 home: No such file or directory>

I found that the path /home is denied for anonymouse access but the path /home/work is not. 
urllib2.open try to call ftp.cwd("home") and then ftp.cwd("work") which failed when ftp.cwd("home").

I tried to fix this by changing "for dir in self.dirs: self.ftp.cwd(dir)" to "self.ftp.cwd(os.path.join(*self.dirs)" in urllib.py. And it works fine for this situation.

----------
messages: 189097
nosy: foxkiller
priority: normal
severity: normal
status: open
title: urllib2.open failed to access a url when a perent directory of the url is permission denied
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon May 13 11:48:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 13 May 2013 09:48:46 +0000
Subject: [New-bugs-announce] [issue17968] memory leak in listxattr()
Message-ID: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

os.listxattr() leaks its internal buffer when the first call to C listxattr() fails with ERANGE. This wasn't caught by the refleak bot, probably because xattrs are not enabled on it.

----------
files: listxattr_leak.patch
keywords: patch
messages: 189114
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: memory leak in listxattr()
type: resource usage
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30248/listxattr_leak.patch

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

From report at bugs.python.org  Mon May 13 13:31:34 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 13 May 2013 11:31:34 +0000
Subject: [New-bugs-announce] [issue17969] multiprocessing crash on exit
Message-ID: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

We have observed this crash with some frequency when running our compilation scripts using multiprocessing.Pool()

By analysing the crashes, this is what is happening:
1) The Pool has a "daemon" thread managing the pool.
2) the worker is asleep, waiting for the GIL
3) The main thread exits.  The system starts its shutdown. During PyInterpreterState_Clear, it has cleared among other things the sys dict.  During this, it clears an old traceback.  The traceback contains a multiprocessing.connection object.
4) The connection object is cleared.  It it contains this code:
        Py_BEGIN_ALLOW_THREADS
        CLOSE(self->handle);
        Py_END_ALLOW_THREADS
5) The sleeping daemon thread is woken up and starts prancing around.  Upon calling sys.exc_clear() it crashes, since the tstate->interp->sysdict == NULL.


I have a workaround in place in our codebase:


static void
connection_dealloc(ConnectionObject* self)
{
    if (self->weakreflist != NULL)
        PyObject_ClearWeakRefs((PyObject*)self);

    if (self->handle != INVALID_HANDLE_VALUE) {
        /* CCP Change.  Cannot release threads here, because this
         * deallocation may be running during process shutdown, and
         * releaseing a daemon thread will cause a crash
        Py_BEGIN_ALLOW_THREADS
        CLOSE(self->handle);
        Py_END_ALLOW_THREADS
         */
        CLOSE(self->handle);
    }
    PyObject_Del(self);
}


In general, deallocators should have no side effects, I think.  Releaseing the GIL is certainly a side effect.

I realize that process shutdown is a delicate matter.  One delicate thing is that we cannot allow worker threads to run anymore.  I see no general mechanism for ensuring this, but surely at least not releasing the GIL for deallocators is a first step?

----------
messages: 189123
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: multiprocessing crash on exit
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon May 13 15:52:38 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Mon, 13 May 2013 13:52:38 +0000
Subject: [New-bugs-announce] [issue17970] Mutlithread XML parsing cause
	segfault
Message-ID: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za>


New submission from mrDoctorWho0 .:

Linux i386, Python 2.7.4. Multithread xml parsing via pyexpat cause segmentation fault

----------
components: XML
files: pyexpat_crash_multithread.py
messages: 189131
nosy: mrDoctorWho0..
priority: normal
severity: normal
status: open
title: Mutlithread XML parsing cause segfault
versions: Python 2.7
Added file: http://bugs.python.org/file30250/pyexpat_crash_multithread.py

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

From report at bugs.python.org  Mon May 13 23:54:13 2013
From: report at bugs.python.org (Eric Promislow)
Date: Mon, 13 May 2013 21:54:13 +0000
Subject: [New-bugs-announce] [issue17971] Weird interaction between Komodo
	Python debugger C	module & Python 3
Message-ID: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za>


New submission from Eric Promislow:

While much of Komodo's source code has been released under MIT/GPL/LGPL, the Python debugger hasn't, so I can't post it here.  We can work out an arrangement later, although it might not be necessary once I describe 
the problem:

Komodo's Python debugger was a pure-Python debugger, based on pdb. To make it possible to debug the Chandler app, one of the components was written in C against the CPython API, for performance, and all was good. 

With Python 3, breakpoints no longer work after an exec with an explicit
globals arg, where globals is a user-supplied dict, not "globals()" or 
"locals()".  For example, in this code:

print("I'm line 1")
namespace = {}
exec("a = 42", namespace)
print("I'm line 4")
print("Done")

Set breakpoints at lines 1 and 4. Start the debugger in
"Run" mode (stops at first breakpoint).  The debugger
stops at line 1.  Press continue. The debugger runs to
end, without stopping.

If the namespace arg to exec is deleted, or replaced with
"globals()" or "locals()",  (quotes are typographic, not literal),
the breakpoint at line 4 is honored. It only fails when globals
is set to a new dict.

Additionally, if the namespace is defined like so:
namespace = {"DBGPHide": 1}, the breakpoint is honored.
The debugger marks its internal frames with directives like
"DBGPHide" to avoid stepping into them.  Yes, it's a hack.

Adding more diagnostics to the C file shows that the first
time the debugger finds a frame with a global named DBGPHide,
__name__ is "dbgp.common".  This makes sense, because that
module sets DBGPHide to 1, but after every other time, __name__ is "__main__" , and DBGPHide isn't set on it.

I had a look at the implementation of exec in Python 3.3 in
bltinmodule.c and ceval.c, but don't see anything obvious.

Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98951

----------
components: Interpreter Core
messages: 189183
nosy: ericp
priority: normal
severity: normal
status: open
title: Weird interaction between Komodo Python debugger C module & Python 3
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 14 05:11:08 2013
From: report at bugs.python.org (xiaobing jiang)
Date: Tue, 14 May 2013 03:11:08 +0000
Subject: [New-bugs-announce] [issue17972] inspect module leak docs
Message-ID: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>


New submission from xiaobing jiang:

the inspect module leak docs.
all these functions have no doc.
getlineno
getabsfile
getblock
formatannotation
walktree
findsource
indentsize
getargs
formatannotationrelativeto
classify_class_attrs

----------
assignee: docs at python
components: Documentation
messages: 189193
nosy: docs at python, s7v7nislands at gmail.com
priority: normal
severity: normal
status: open
title: inspect module leak docs
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue May 14 10:19:37 2013
From: report at bugs.python.org (Andy Chugunov)
Date: Tue, 14 May 2013 08:19:37 +0000
Subject: [New-bugs-announce] [issue17973] '+=' on a list inside tuple both
	succeeds and raises an	exception
Message-ID: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za>


New submission from Andy Chugunov:

At the same time append() succeeds silently, while simple '+' fails.

Here's an example:
>>> a = ([1],)
>>> a[0].append(2)
>>> a
([1, 2],)
>>> a[0] += [3]
Traceback (most recent call last):
  File "<pyshell#47>", line 1, in <module>
    a[0] += [3]
TypeError: 'tuple' object does not support item assignment
>>> a
([1, 2, 3],)
>>> a[0] = a[0] + [4]
Traceback (most recent call last):
  File "<pyshell#49>", line 1, in <module>
    a[0] = a[0] + [4]
TypeError: 'tuple' object does not support item assignment
>>> a
([1, 2, 3],)
>>> 

Looks like a self-contradictory behavior. Unfortunately, I'm not yet advanced enough to figure out where the problem might be and submit a fix.

Tested with v3.3.1 on Windows 7 (64-bit), and v3.2.3 and v2.7.3 on Debian 7 (also 64-bit).

----------
messages: 189201
nosy: andy.chugunov
priority: normal
severity: normal
status: open
title: '+=' on a list inside tuple both succeeds and raises an exception
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue May 14 14:34:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 May 2013 12:34:45 +0000
Subject: [New-bugs-announce] [issue17974] Migrate unittest to argparse
Message-ID: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Attached patch migrates unittest to argparse.
This doesn't make discover handling much saner, given the awful way it's originally implemented.

----------
components: Library (Lib)
files: unittest_argparse.patch
keywords: patch
messages: 189212
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Migrate unittest to argparse
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30256/unittest_argparse.patch

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

From report at bugs.python.org  Tue May 14 16:43:59 2013
From: report at bugs.python.org (Patrick Welche)
Date: Tue, 14 May 2013 14:43:59 +0000
Subject: [New-bugs-announce] [issue17975] libpython3.so conflicts between
	$VERSIONs
Message-ID: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za>


New submission from Patrick Welche:

I currently have python 2.7 and 3.2 installed concurrently. I just tried to install 3.3 as well, but a file conflicts between 3.2 and 3.3. It is libpython3.so.

Given that we go out of our way e.g. with

$(INSTALL_DATA) Misc/python.pc $(DESTDIR)$(LIBPC)/python-$(VERSION).pc

to avoid clashes, what should be done about PY3LIBRARY?

----------
components: Build
messages: 189223
nosy: prlw1
priority: normal
severity: normal
status: open
title: libpython3.so conflicts between $VERSIONs
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May 14 17:10:27 2013
From: report at bugs.python.org (Jaakko Moisio)
Date: Tue, 14 May 2013 15:10:27 +0000
Subject: [New-bugs-announce] [issue17976] file.write doesn't raise IOError
	when it should
Message-ID: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>


New submission from Jaakko Moisio:

file.write doesn't sometimes raise IOError when it should, e.g. writing to /dev/full in line buffered mode:

jaakko at jm-laptop:~$ python
Python 2.7.5+ (2.7:a32a3b79f5e8, May 14 2013, 14:20:11) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f=open('/dev/full','w',1)
>>> f.write('hello\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 28] No space left on device
>>> f.close()
>>> f=open('/dev/full','w',1)
>>> f.write('hello')
>>> f.write('\n')
>>> f.close()
>>> # No IOError!
... 
>>> 

The current implementation of file.write relies on comparing the return value of fwrite to the expected number of bytes written to detect errors. I haven't dug deep enough into the C standard to know for sure if fwrite return value == expected should always imply no error, but in my example it clearly doesn't (I assume my glibc and fwrite aren't broken though). However using ferror to detect the error works fine and IOError was raised as expected.

Python3 and io module use different implementation where this is no longer an issue. For us still using Python 2.7 I suggest the attached simple patch to fix the issue.

----------
components: Interpreter Core
files: fileobject-fix.patch
keywords: patch
messages: 189226
nosy: jasujm
priority: normal
severity: normal
status: open
title: file.write doesn't raise IOError when it should
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30258/fileobject-fix.patch

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

From report at bugs.python.org  Tue May 14 17:31:19 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 May 2013 15:31:19 +0000
Subject: [New-bugs-announce] [issue17977] urllib.request.urlopen() cadefault
	argument is	documented with wrong default value
Message-ID: <1368545479.83.0.400534978811.issue17977@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

The docs[1] say:

.. function:: urlopen(url, data=None[, timeout], *, cafile=None, capath=None, cadefault=True)

The code[2] says:

def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT,
            *, cafile=None, capath=None, cadefault=False):

Obviously, the code cannot be changed in a stable release, and whether the default should be changed for 3.4 is a separate discussion.  For now, the docs should be fixed to reflect the code.

[1] Doc/library/urllib.request.rst
[2] Lib/urllib/request.py

----------
assignee: barry
components: Documentation
messages: 189228
nosy: barry
priority: normal
severity: normal
status: open
title: urllib.request.urlopen() cadefault argument is documented with wrong default value
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue May 14 23:04:28 2013
From: report at bugs.python.org (Romulo A. Ceccon)
Date: Tue, 14 May 2013 21:04:28 +0000
Subject: [New-bugs-announce] [issue17978] Python crashes if
	Py_Initialize/Py_Finalize are called	multiple times
Message-ID: <1368565468.18.0.0802244129119.issue17978@psf.upfronthosting.co.za>


New submission from Romulo A. Ceccon:

I have patched (see attachment) Python 2.7.4 (as available for download at python.org/download) to disable initialization of Unicode (an embeded system requirement) and now it segfaults with the following program:

    #include <Python.h>
    
    int main(int argc, char** argv)
    {
      int i;
      Py_NoSiteFlag = 1;
    
      Py_SetProgramName(argv[0]);
    
      for (i = 0; i < 3; i++)
      {
        printf("run no. %d\n", i);
    
        Py_Initialize();
        Py_Finalize();
      }
    
      return 0;
    }

The problem appears to be related with the reference count of the empty tuple. I've also applied the following patch in Objects/tupleobject.c to help diagnose the problem:

    @@ -928,6 +928,8 @@ PyTuple_Fini(void)
     #if PyTuple_MAXSAVESIZE > 0
         /* empty tuples are used all over the place and applications may
          * rely on the fact that an empty tuple is a singleton. */
    +    printf("free_list[0]->ob_refcnt before XDECREF: %d\n",
    +        free_list[0]->ob_refcnt);
         Py_XDECREF(free_list[0]);
         free_list[0] = NULL;

*Without* the patch for Python/pythonrun.c the program produces the following results under Ubuntu 13.04 x64:

    run no. 0
    free_list[0]->ob_refcnt before XDECREF: 58
    run no. 1
    free_list[0]->ob_refcnt before XDECREF: 57
    run no. 2
    free_list[0]->ob_refcnt before XDECREF: 57

Note the strange ref count of the empty tuple (free_list[0]). Now, *with* the patch, the application will not hold so many references to the empty tuple and the finalization code ends up trying to deallocate it (what, from my limited understading of the code, is not supposed to happen):

    run no. 0
    free_list[0]->ob_refcnt before XDECREF: 2
    run no. 1
    free_list[0]->ob_refcnt before XDECREF: 1
    Segmentation fault (core dumped)

The actual patch I'm using is much more complicated. This is just the minimal patch able to reproduce the problem. I tried undefining Py_USING_UNICODE but then the build doesn't succeed.

----------
components: Interpreter Core
files: pythonrun.c.patch
keywords: patch
messages: 189250
nosy: Romulo A. Ceccon
priority: normal
severity: normal
status: open
title: Python crashes if Py_Initialize/Py_Finalize are called multiple times
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file30261/pythonrun.c.patch

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

From report at bugs.python.org  Wed May 15 01:27:00 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 14 May 2013 23:27:00 +0000
Subject: [New-bugs-announce] [issue17979] Cannot build 2.7 with
	--enable-unicode=no
Message-ID: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

python2.7 can't be compiled with --enable-unicode=no
Because of a crash in the re module. It's a regression from 2.7.3.

$ ./python -c 'import re; re.compile("([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*)")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/amauryfa/python/cpython2.7/Lib/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/home/amauryfa/python/cpython2.7/Lib/re.py", line 240, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/amauryfa/python/cpython2.7/Lib/sre_compile.py", line 533, in compile
    groupindex, indexgroup
RuntimeError: invalid SRE code


The cause is in sre.h: when Py_USING_UNICODE is false, SRE_CODE is defined as "unsigned long" instead of "unsigned short"!

When this is fixed, the following modules did not compile:
_io _json _sqlite3 _ssl _testcapi
Which modules are supposed to work without unicode?

----------
assignee: serhiy.storchaka
messages: 189255
nosy: amaury.forgeotdarc, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Cannot build 2.7 with --enable-unicode=no
versions: Python 2.7

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

From report at bugs.python.org  Wed May 15 12:25:06 2013
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 15 May 2013 10:25:06 +0000
Subject: [New-bugs-announce] [issue17980] ssl.match_hostname() trips over
	crafted wildcard names
Message-ID: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za>


New submission from Florian Weimer:

If the name in the certificate contains many "*" characters, matching the compiled regular expression against the host name can take a very long time.  Certificate validation happens before host name checking, so I think this is a minor issue only because it can only be triggered in cooperation with a CA (which seems unlikely).

The fix is to limit the number of "*" wildcards to a reasonable maximum (perhaps even 1).

----------
components: Library (Lib)
messages: 189280
nosy: fweimer
priority: normal
severity: normal
status: open
title: ssl.match_hostname() trips over crafted wildcard names
versions: Python 3.3

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

From report at bugs.python.org  Wed May 15 15:49:55 2013
From: report at bugs.python.org (Julien Palard)
Date: Wed, 15 May 2013 13:49:55 +0000
Subject: [New-bugs-announce] [issue17981] SysLogHandler closes connection
	before using it
Message-ID: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za>


New submission from Julien Palard:

I have a script that close its socket to /dev/log immediatly before using it, causing it to fail, here is the code :
{{{
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import logging
import logging.handlers
import daemon
from daemon.pidlockfile import PIDLockFile

logger = logging.getLogger('twitterCounter')
logger.addHandler(logging.handlers.SysLogHandler(address='/dev/log'))
logger.setLevel(logging.DEBUG)

logger.info("Hello")

with daemon.DaemonContext():
    logger.info("World !")
}}}

and here is an strace :
{{{
strace -s999 -f  /tmp/test.py 2>&1 | grep -C2 ^connect
// Outside daemonContext, all is OK
// Note that inside daemonContext, all is OK if we do not log outside daemonContext.

close(3)                                = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 3
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = 0
sendto(3, "<14>Hello\0", 10, 0, NULL, 0) = 10
getuid()                                = 1001
--

// Second log, inside daemonContext, with the erroneous "socket(); close()" :


socket(PF_FILE, SOCK_DGRAM, 0)          = 3
close(3)                                = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EBADF (Bad file descriptor)
close(3)                                = -1 EBADF (Bad file descriptor)

// As the previous try has failed, SysLogHandler seems to give another try with different parameters, failing too as expected socket type is DGRAM :
socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EPROTOTYPE (Protocol wrong type for socket)
}}}

----------
components: Library (Lib)
messages: 189283
nosy: Julien.Palard
priority: normal
severity: normal
status: open
title: SysLogHandler closes connection before using it
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 15 18:20:36 2013
From: report at bugs.python.org (Hugh Littlejohn)
Date: Wed, 15 May 2013 16:20:36 +0000
Subject: [New-bugs-announce] [issue17982] Syntax Error in IDLE3 not in IDLE
Message-ID: <1368634836.7.0.999902243519.issue17982@psf.upfronthosting.co.za>


New submission from Hugh Littlejohn:

New to Python, acquired Raspberry PI. Upgraded and now have IDLE and IDLE3.
Python 3.2.3 (default, Mar 1 2013, 11:53:50) (GNU 4.6.3] on Linux2

First task, New Window to create "Hello, World!"
Using IDLE3, created file helloworld.py
Using Run/ Check Module - failed with syntax error on the closing double-quote
Tried space before ending double-quote - failed
Tried reducing string to "Hello" - failed
Removed training end-of-line - failed

Closed IDLE3 and started IDLE
Loaded file as before - worked as expected

Restarted IDLE3 - still failed

Tried command-line "python helloworld.py" - worked as expected

Any ideas ?

----------
components: IDLE
files: helloworld.py
messages: 189288
nosy: Littlejohn
priority: normal
severity: normal
status: open
title: Syntax Error in IDLE3 not in IDLE
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file30267/helloworld.py

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

From report at bugs.python.org  Wed May 15 21:00:10 2013
From: report at bugs.python.org (Dwight Guth)
Date: Wed, 15 May 2013 19:00:10 +0000
Subject: [New-bugs-announce] [issue17983] global __class__ statement in
	class declaration
Message-ID: <1368644410.25.0.871302075026.issue17983@psf.upfronthosting.co.za>


New submission from Dwight Guth:

The following python program causes cpython to crash:

class A:
  global __class__
  def a(self):
    super()

I get the following output on the console:

bug.py:2: SyntaxWarning: name '__class__' is assigned to before global declaration
  global __class__
lookup '__class__' in ? a sequ 2 -1
freevars of A: ('__class__',)
Fatal Python error: compiler_make_closure()

Current thread 0x00007fc712192700:
Aborted (core dumped)

This probably happens because __class__ is handled specially by the scoping rules and isn't expected to be anything other than a member of co_cellvars. It should probably throw an exception instead (SystemError?)

----------
messages: 189293
nosy: dwight.guth
priority: normal
severity: normal
status: open
title: global __class__ statement in class declaration
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed May 15 21:49:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 May 2013 19:49:27 +0000
Subject: [New-bugs-announce] [issue17984] io and _pyio modules require the
	_io module
Message-ID: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

io and _pyio modules don't usable without the _io module. In particular when 2.7 build without unicode. Why we have a Python implementation if it can't be used as a fallback when a C implementation is not available?

----------
components: IO
messages: 189295
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: io and _pyio modules require the _io module
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 15 22:41:12 2013
From: report at bugs.python.org (Andre Dias)
Date: Wed, 15 May 2013 20:41:12 +0000
Subject: [New-bugs-announce] [issue17985] multiprocessing Queue.qsize() and
	Queue.empty() with	different results
Message-ID: <1368650472.41.0.00471316865127.issue17985@psf.upfronthosting.co.za>


New submission from Andre Dias:

The problem is that Queue.empty() is True even if Queue.qsize()>0!


#!/usr/bin/python

from multiprocessing import Queue

numbers=Queue()
for i in range (0,10):
    numbers.put(i)

if numbers.qsize()>0 and numbers.empty():
    print "BUG?!"

----------
components: Extension Modules
messages: 189302
nosy: aod
priority: normal
severity: normal
status: open
title: multiprocessing Queue.qsize() and Queue.empty() with different results
versions: Python 2.7

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

From report at bugs.python.org  Wed May 15 23:09:59 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 15 May 2013 21:09:59 +0000
Subject: [New-bugs-announce] [issue17986] Alternative async subprocesses
	(pep 3145)
Message-ID: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

In the attached file is an experimental implementation of an AsyncPopen
class.  It should work for Python 3.3, 3.4 on Unix and Windows.  Unlike

    http://code.google.com/p/subprocdev

(see #1191964) this does not depend on using time.sleep() and polling.
It also uses the stdlib's _winapi instead of ctypes.

It lets one do Unix-style multiplexing of stdin, stdout, stderr on
Windows (by using overlapped IO).

Differences from normal Popen:

* File objects created for stdin/stdout/stderr using "...=PIPE" are
  non-blocking.

* There are no options for buffering or for universal line endings
  (or unicode).

* There is an extra method

      select(file_list, timeout=None) -> ready_file_list

  which can be used to wait for stdin, stdout, stderr to be ready.
  file_list should be a sublist of [self.stdin, self.stdout, self.stderr]
  with no None elements.  Note that there is no separation between
  "readers" and "writers" the way there is for the normal select()
  function.  On Unix this is implemented using select() or poll().

* On Windows close() can fail with BlockingIOError.  To prevent this
  one must use select() to wait for self.stdin to be ready.

As an example, communicate() can be reimplemented using select() as follows:

    def communicate(p, input):
        buf = memoryview(input)
        collected = collections.defaultdict(list)
        registered = [f for f in (p.stdin, p.stdout, p.stderr)
                      if f is not None]

        while registered:
            for f in p.select(registered):
                if f is p.stdin:
                    if not buf:
                        f.close()
                        registered.remove(f)
                    else:
                        n = f.write(buf)
                        if n is not None:
                            buf = buf[n:]
                elif f in (p.stdout, p.stderr):
                    s = f.read(8192)
                    if s == b'':
                        f.close()
                        registered.remove(f)
                    elif s is not None:
                        collected[f].append(s)
                else:
                    raise RuntimeError('should not get here')

        return (b''.join(collected[p.stdout]) if p.stdout else None,
                b''.join(collected[p.stderr]) if p.stderr else None)

----------
files: asyncsubprocess.py
messages: 189304
nosy: sbt
priority: normal
severity: normal
status: open
title: Alternative async subprocesses (pep 3145)
versions: Python 3.4
Added file: http://bugs.python.org/file30269/asyncsubprocess.py

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

From report at bugs.python.org  Wed May 15 23:30:23 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 15 May 2013 21:30:23 +0000
Subject: [New-bugs-announce] [issue17987] test.support.captured_stderr,
	captured_stdin not documented
Message-ID: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr.:

The captured_stderr and captured_stdin context managers aren't documented, and should be.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 189311
nosy: docs at python, fdrake
priority: normal
severity: normal
stage: needs patch
status: open
title: test.support.captured_stderr, captured_stdin not documented
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 16 00:39:43 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 15 May 2013 22:39:43 +0000
Subject: [New-bugs-announce] [issue17988] ElementTree.Element !=
	ElementTree._ElementInterface
Message-ID: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

The xml.etree.ElementTree module provides _Element and _ElementInterface as compatibility aliases for Element. However, in Python 3.3 if the _elementtree module is importable, these classes are not identical: Element is a C implementation, and _Element/_ElementInterface is a Python implementation.

$ python3.2 test-elementinterface.py 
141477524
141477524
141477524

$ python3.3 test-elementinterface.py 
137248544
4144597188
4144597188

----------
components: Library (Lib)
files: test-elementinterface.py
messages: 189319
nosy: jwilk
priority: normal
severity: normal
status: open
title: ElementTree.Element != ElementTree._ElementInterface
versions: Python 3.3
Added file: http://bugs.python.org/file30270/test-elementinterface.py

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

From report at bugs.python.org  Thu May 16 00:46:51 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 15 May 2013 22:46:51 +0000
Subject: [New-bugs-announce] [issue17989] ElementTree.Element broken
	attribute setting
Message-ID: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

Setting attributes on ElementTree.Element objects is broken: it succeeds without exception, but then the following statement fails with AttributeError (unless that statement sets an Element's attribute too):

$ python3.3 test-element-setattr.py 
Hello world!Traceback (most recent call last):
  File "test-element-setattr.py", line 6, in <module>
    print('Hello world!')
AttributeError: ham2

----------
components: Library (Lib)
files: test-element-setattr.py
messages: 189321
nosy: jwilk
priority: normal
severity: normal
status: open
title: ElementTree.Element broken attribute setting
versions: Python 3.3
Added file: http://bugs.python.org/file30272/test-element-setattr.py

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

From report at bugs.python.org  Thu May 16 01:37:43 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 May 2013 23:37:43 +0000
Subject: [New-bugs-announce] [issue17990] 2.7 builds can fail due to
	unconditional inclusion of	include paths
Message-ID: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za>


New submission from Ned Deily:

For Issue17086, 8ee6d96a1019 backported some cross-build patches to the 2.7 branch.  The changes to setup.py detect_modules differ in the backport from those in default. In particular, in default, changes to the library and include directory lists used to build extensions modules are only made conditionally when cross-compiling.  But the 2.7 backport makes these changes unconditionally.

default:
    def detect_modules(self):
        # Ensure that /usr/local is always used, but the local build
        # directories (i.e. '.' and 'Include') must be first.  See issue
        # 10520.
        if not cross_compiling:
            add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
            add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
        # only change this for cross builds for 3.3, issues on Mageia
        if cross_compiling:
            self.add_gcc_paths()
        self.add_multiarch_paths()

2.7:
    def detect_modules(self):
        # Ensure that /usr/local is always used
        add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib')
        add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
        self.add_gcc_paths()
        self.add_multiarch_paths()

This breaks certain universal build combinations on OS X when using SDKs and it is possible it could break builds on other platforms as well.  Substituting the default branch code on 2.7 appears to solve the OS X build problem.  Whether it has any negative impact on other builds, in particular cross-compilations is untested.

----------
components: Build
messages: 189327
nosy: benjamin.peterson, doko, ned.deily
priority: release blocker
severity: normal
stage: patch review
status: open
title: 2.7 builds can fail due to unconditional inclusion of include paths
versions: Python 2.7

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

From report at bugs.python.org  Thu May 16 05:21:57 2013
From: report at bugs.python.org (Steven Barker)
Date: Thu, 16 May 2013 03:21:57 +0000
Subject: [New-bugs-announce] [issue17991] ctypes.c_char gives a misleading
	error when passed a	one-character unicode string
Message-ID: <1368674517.59.0.230555789399.issue17991@psf.upfronthosting.co.za>


New submission from Steven Barker:

While investigating a Stack Overflow question (http://stackoverflow.com/questions/16484764/multiprocessing-value-clear-syntax) I came across a misleading error message from the multiprocessing.Value constructor:

>>> import multiprocessing
>>> my_char = "x"
>>> v = multiprocessing.Value("c", my_char)
Traceback (most recent call last):
  File "<pyshell#21>", line 1, in <module>
    v = multiprocessing.Value("c", my_char)
  File "S:\Python33\lib\multiprocessing\__init__.py", line 243, in Value
    return Value(typecode_or_type, *args, lock=lock)
  File "S:\Python33\lib\multiprocessing\sharedctypes.py", line 70, in Value
    obj = RawValue(typecode_or_type, *args)
  File "S:\Python33\lib\multiprocessing\sharedctypes.py", line 47, in RawValue
    obj.__init__(*args)
TypeError: one character string expected

The "one character string expected" message was rather unhelpful, since that seemed to be what I gave it. After being stumped by this for a bit, I realized that it might be having an issue with Unicode and giving an error message more appropriate to Python 2 than Python 3. Sure enough, passing a one-character bytes instance works just fine.

So, at a minimum I think the error message should be updated to say it wants a one-character bytes instance rather than a "string" (which to my mind means a "str" instance). A further enhancement might be to accept unicode strings that contain just a single ASCII character too, but I realize that may be more messy and error prone.

The error message comes from the ctypes module, and can be reproduced easily:

>>> ctypes.c_char("x")
Traceback (most recent call last):
  File "<pyshell#28>", line 1, in <module>
    ctypes.c_char("x")
TypeError: one character string expected

The exception text comes from Modules/_ctypes/cfield.c:1151

----------
components: Library (Lib)
messages: 189338
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: ctypes.c_char gives a misleading error when passed a one-character unicode string
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu May 16 06:54:43 2013
From: report at bugs.python.org (Carlos Nepomuceno)
Date: Thu, 16 May 2013 04:54:43 +0000
Subject: [New-bugs-announce] [issue17992] test_asynchat hangs
Message-ID: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za>


New submission from Carlos Nepomuceno:

after running 'make' i entered 'make test' and it hanged on test_asynchat. stayed there for more than 1 hour.

---
Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _tkinter           bsddb185
bz2                dbm                dl
gdbm               imageop            readline
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
./python -E -c 'import sys ; from sysconfig import get_platform ; print get_platform()+"-"+sys.version[0:3]' >platform
find ./Lib -name '*.py[co]' -print | xargs rm -f
./python -Wd -3 -E -tt  ./Lib/test/regrtest.py -l
== CPython 2.7.5 (default, May 16 2013, 00:43:33) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]
==   Linux-2.6.32-279.19.1.el6.x86_64-x86_64-with-centos-6.4-Final little-endian
==   /usr/src/Python-2.7.5/build/test_python_26106
Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_grammar
test_opcodes
test_dict
test_builtin
test_exceptions
test_types
test_unittest
/usr/src/Python-2.7.5/Lib/unittest/runner.py:39: DeprecationWarning: comparing unequal types not supported in 3.x
  self.showAll = verbosity > 1
test_doctest
test_doctest2
test_MimeWriter
test_SimpleHTTPServer
test_StringIO
test___all__
test___future__
test__locale
test__osx_support
test_abc
test_abstract_numbers
test_aepack
test_aepack skipped -- No module named aetypes
test_aifc
test_al
test_al skipped -- No module named al
test_anydbm
test_applesingle
test_applesingle skipped -- No module named MacOS
test_argparse
test_array
test_ascii_formatd
test_ast
test_asynchat

----------
components: Tests
files: test_asynchat.txt
messages: 189340
nosy: Carlos.Nepomuceno
priority: normal
severity: normal
status: open
title: test_asynchat hangs
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file30277/test_asynchat.txt

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

From report at bugs.python.org  Thu May 16 09:18:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 May 2013 07:18:52 +0000
Subject: [New-bugs-announce] [issue17993] Missed comma causes unintentional
	implicit string	literal concatenation
Message-ID: <1368688732.05.0.0592357298734.issue17993@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

I just found a bug in Tools/scripts/abitype.py:

typeslots = [
    'tp_name',
    'tp_basicsize',
    ...
    'tp_subclasses',
    'tp_weaklist',
    'tp_del'
    'tp_version_tag'
]

There is a missed comma after 'tp_del'.

Perhaps there are other similar bugs in Python sources.

----------
components: Demos and Tools
files: missed_comma.patch
keywords: patch
messages: 189343
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Missed comma causes unintentional implicit string literal concatenation
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30280/missed_comma.patch

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

From report at bugs.python.org  Thu May 16 16:24:45 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Thu, 16 May 2013 14:24:45 +0000
Subject: [New-bugs-announce] [issue17994] Change necessary in platform.py to
	support IronPython
Message-ID: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za>


New submission from Ian Cordasco:

Stemming from a StackOverflow question[1] and a conversation with Marc-Andre Lemburg via email, I'm filing this issue without any easy way of confirming it myself.

It seems that the logic in platform.python_implementation() has been obsoleted by a change made in IronPython. As it is now, it checks that the slice, sys.version[:10], is "IronPython". Seemingly due to a change in IronPython, this no longer is a correct condition for checking that the implementation is IronPython.

I'm trying to work with the question author on StackOverflow to provide the relevant debugging information to fix this, but it is taking a while to get responses. Without his repr(sys.version) I can't submit a patch with this issue.

I've also only tagged Python 2.7 since I have no way of knowing if this occurs with Python 3.x or anything earlier.

[1]: http://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23828551_16545027

----------
components: Library (Lib), Windows
messages: 189383
nosy: icordasc, lemburg
priority: normal
severity: normal
status: open
title: Change necessary in platform.py to support IronPython
versions: 3rd party, Python 2.7

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

From report at bugs.python.org  Thu May 16 19:29:40 2013
From: report at bugs.python.org (Nobody/Anonymous)
Date: Thu, 16 May 2013 17:29:40 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue17995=5D_report=EF=BC=8C?=
 =?utf-8?b?5Lit44CA6auY44CA5bGC44CA566h44CA55CG44CA5oqA44CA6IO9MTU4NzY2?=
Message-ID: <1368725380.5.0.946016872176.issueNone@psf.upfronthosting.co.za>


New submission from Nobody/Anonymous:

report????

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

                       158766? ? ? ? 6 ? ?158766

            5?18-19? ? ?  05?25-26? ? ?  6?08-09? ? ? 

??????????????????????????????????

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
2013-05-1701:29:41

----------
messages: 189390
nosy: nobody
priority: normal
severity: normal
status: open
title: report??????????????158766

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

From report at bugs.python.org  Fri May 17 04:20:43 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 17 May 2013 02:20:43 +0000
Subject: [New-bugs-announce] [issue17996] socket module should expose AF_LINK
Message-ID: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

I bumped into this while exposing getifaddrs() [1] in psutil:
https://code.google.com/p/psutil/issues/detail?id=376

In that case AF_LINK would be useful to distinguish MAC addresses (see also: http://carnivore.it/2010/07/22/python_-_getifaddrs).

[1] http://man7.org/linux/man-pages/man3/getifaddrs.3.html

----------
messages: 189420
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket module should expose AF_LINK
versions: Python 3.4

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

From report at bugs.python.org  Fri May 17 16:04:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 17 May 2013 14:04:53 +0000
Subject: [New-bugs-announce] [issue17997] ssl.match_hostname(): sub string
	wildcard should not	match IDNA prefix
Message-ID: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's ssl.match_hostname() does sub string matching as specified in RFC 2818:

   Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

The RFC doesn't specify how internationalized domain names shoould be handled because it predates RFC 5890 for IDNA by many year. IDNA are prefixed with "xn--", e.g. u"g?tter.example.de".encode("idna") == 
"xn--gtter-jua.example.de". This can result into false positive matches for a rule like "x*.example.de".

Chrome has special handling for IDN prefix in X509Certificate::VerifyHostname()
http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc

Also see #17980

----------
messages: 189454
nosy: christian.heimes, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: ssl.match_hostname(): sub string wildcard should not match IDNA prefix
type: security
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 17 17:09:14 2013
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 17 May 2013 15:09:14 +0000
Subject: [New-bugs-announce] [issue17998] internal error in regular
	expression engine
Message-ID: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

On Linux Ubuntu 13.04, i686:

$ uname -a
Linux arando 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:20:06 UTC 2013 i686 i686 i686 GNU/Linux

$ python
Python 2.7.5 (default, May 17 2013, 18:43:24) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: internal error in regular expression engine

This is a 2.7.5 regression, 2.7.4 worked fine.

----------
components: Library (Lib)
messages: 189461
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: internal error in regular expression engine
versions: Python 2.7

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

From report at bugs.python.org  Fri May 17 18:15:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 May 2013 16:15:33 +0000
Subject: [New-bugs-announce] [issue17999] test_super fails in refleak runs
Message-ID: <1368807333.21.0.801142067432.issue17999@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

$ ./python -m test -R 3:3 test_super
[1/1] test_super
beginning 6 repetitions
123456
test test_super failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_super.py", line 97, in test_various___class___pathologies
    self.assertIs(X.x, type(self))
AssertionError: 42 is not <class 'test.test_super.TestSuper'>

----------
components: Tests
messages: 189464
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_super fails in refleak runs
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri May 17 21:23:12 2013
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 17 May 2013 19:23:12 +0000
Subject: [New-bugs-announce] [issue18000] _md5 should be built if _ssl
	cannot be built
Message-ID: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer:

I have an Itanium Linux system where compiling Python's _ssl module fails for some reason, with the consequence that there is no md5 support at all in the resulting Python 2.7.5 installation.

With Python 2.7.4, setup.py didn't even try to compile _ssl, instead it compiled the _sha, _md5, _sha256, _sha512 modules and it worked.

With Python 2.7.5, setup.py somehow thinks that _ssl should work, tries to compile _ssl, which fails and (this is the real failure): it doesn't try anymore to compile the _sha, _md5, _sha256, _sha512 modules.

----------
components: Build
messages: 189479
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: _md5 should be built if _ssl cannot be built
versions: Python 2.7

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

From report at bugs.python.org  Fri May 17 21:49:55 2013
From: report at bugs.python.org (Charles Henry)
Date: Fri, 17 May 2013 19:49:55 +0000
Subject: [New-bugs-announce] [issue18001] TypeError: dict is not callable in
	ConfigParser.py
Message-ID: <1368820195.26.0.0396003591011.issue18001@psf.upfronthosting.co.za>


New submission from Charles Henry:

Python 2.6 and 2.7 each have a bad definition of the class RawConfigParser
It is immediately apparent in the __init__ function which begins with:

class RawConfigParser:
    def __init__(self, defaults=None, dict_type=dict):
        self._dict = dict_type
        self._sections = self._dict()
        self._defaults = self._dict()

Clearly, _dict() is not a function.  _dict is not even properly defined as a public or private member of the RawConfigParser class.

The fix is to add a private variable to the class and a function for retrieving the value.

----------
components: Library (Lib)
messages: 189480
nosy: czhenry
priority: normal
severity: normal
status: open
title: TypeError: dict is not callable in ConfigParser.py
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri May 17 22:55:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 May 2013 20:55:55 +0000
Subject: [New-bugs-announce] [issue18002] AMD64 Windows7 SP1 3.x buildbot:
	compilation of _ssl	module fails, the build fails
Message-ID: <1368824155.21.0.900173074466.issue18002@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example of failure:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1956/


--

Compilation log:

Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pcbuild.sln" (1) is building "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (17) on node 1 (default targets).
Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (17) is building "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj" (18) on node 1 (default targets).
Build:
  cd "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\"
  "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a
  
  Can not find a suitable PERL:
   NO perl interpreters were found on this machine at all!
   Please install ActivePerl and ensure it appears on your path
  No Perl installation was found. Existing Makefiles are used.
  Perl is required to build the makefiles!
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "cd "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\" [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: " exited with code 1. [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj]
Done Building Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (default targets) -- FAILED.

----------
components: Tests, Windows
messages: 189485
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: AMD64 Windows7 SP1 3.x buildbot: compilation of _ssl module fails, the build fails
versions: Python 3.4

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

From report at bugs.python.org  Sat May 18 00:27:24 2013
From: report at bugs.python.org (Michael Fox)
Date: Fri, 17 May 2013 22:27:24 +0000
Subject: [New-bugs-announce] [issue18003] New lzma crazy slow with
	line-oriented reading.
Message-ID: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za>


New submission from Michael Fox:

import lzma
count = 0
f = lzma.LZMAFile('bigfile.xz' ,'r')
for line in f:
    count += 1
print(count)

Comparing python2 with pyliblzma to python3.3.1 with the new lzma:

m at air:~/q/topaz/parse_datalog$ time python  lzmaperf.py
102368

real    0m0.062s
user    0m0.056s
sys     0m0.004s
m at air:~/q/topaz/parse_datalog$ time python3  lzmaperf.py
102368

real    0m7.506s
user    0m7.484s
sys     0m0.012s

Profiling shows most of the time is spent here:

   102371    6.881    0.000    6.972    0.000 lzma.py:247(_read_block)

I also notice that reading the entire file into memory with f.read() is perfectly fast.

I think it has something to do with lack of buffering.

----------
components: Library (Lib)
messages: 189488
nosy: Michael.Fox, nadeem.vawda
priority: normal
severity: normal
status: open
title: New lzma crazy slow with line-oriented reading.
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Sat May 18 01:46:49 2013
From: report at bugs.python.org (Anselm Kruis)
Date: Fri, 17 May 2013 23:46:49 +0000
Subject: [New-bugs-announce] [issue18004] test_list.test_overflow crashes
	Win64
Message-ID: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

I installed Python 2.7.5 including tests using the MSI installer from http://www.python.org/ftp/python/2.7.5/python-2.7.5.amd64.msi Running 

python.exe -m test.regrtest -v test_list

consumes all available memory and renders the my system completely unusable. I had to reboot. The problem is caused by the test case "test_overflow". If you run the test with an imposed memory limit, e.g. by using ulimitnt (http://code.google.com/p/ulimitnt/) , test_overflow passes.

I propose to skip this test on Win64.

----------
components: Tests
messages: 189491
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: test_list.test_overflow crashes Win64
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Sat May 18 12:07:19 2013
From: report at bugs.python.org (Pernici Mario)
Date: Sat, 18 May 2013 10:07:19 +0000
Subject: [New-bugs-announce] [issue18005] faster modular exponentiation in
	some cases
Message-ID: <1368871639.93.0.89718215484.issue18005@psf.upfronthosting.co.za>


New submission from Pernici Mario:

A trivial optimization can be made in ``pow(a, b, c)``
if ``b`` is even and ``c - a < a``

```
In [1]: c = (1 << 1000000) + 1 

In [2]: a = c - 1234567

In [3]: b = 2

In [4]: %timeit pow(a, b, c)
1 loops, best of 3: 3.03 s per loop

In [5]: %timeit pow(c - a if c - a < (a >> 10) else a, b, c)
1000 loops, best of 3: 287 us per loop
```

This optimization is probably done in GMP, since using gmpy.mpz
[5] is a bit slower than [4].

----------
messages: 189504
nosy: pernici
priority: normal
severity: normal
status: open
title: faster modular exponentiation in some cases
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Sat May 18 13:44:07 2013
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 18 May 2013 11:44:07 +0000
Subject: [New-bugs-announce] [issue18006] Set thread nema in linux kernel
Message-ID: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za>


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

In linux (Since 2.6.9) we can use syscall

prctl(PR_SET_NAME, "Some thread name")

to set thread name to the kernel. This thread is seen  under this name in some process tool (like top, ps, pstree (have bug reported connected with this) and others).

It will be nice if this syscall will be called (from correspoding thread=TID) when changing (setting) thread name.

Note, that in current implementation name will be truncated to 15 bytes in kernel.

This work very well using ctypes or python-prctl module.

Also there is error in manpage about prctl saying that name is set to process (already sent to maintainer). Really, name is set to each thread.

----------
components: Library (Lib)
messages: 189507
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Set thread nema in linux kernel
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May 18 17:45:02 2013
From: report at bugs.python.org (Simon Nicolussi)
Date: Sat, 18 May 2013 15:45:02 +0000
Subject: [New-bugs-announce] [issue18007] CookieJar expects request objects
	with origin_req_host	attribute instead of method
Message-ID: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za>


New submission from Simon Nicolussi:

A fix for a DeprecationWarning (#17678) had the unfortunate side effect of changing the expected interface of the request object higher up in the call stack.

For example, the documentation for CookieJar.add_cookie_header(request) states that the request object must support the methods get_full_url(), get_host(), get_type(), unverifiable(), get_origin_req_host(), has_header(), get_header(), header_items(), and add_unredirected_header(). The patch for #17678, however, changes the requirement for a get_origin_req_host() method to an origin_req_host attribute.

This breaks at least one notable third-party library (Kenneth Reitz' Requests).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 189523
nosy: docs at python, orsenthil, sinic
priority: normal
severity: normal
status: open
title: CookieJar expects request objects with origin_req_host attribute instead of method
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May 18 17:45:06 2013
From: report at bugs.python.org (William Moreno)
Date: Sat, 18 May 2013 15:45:06 +0000
Subject: [New-bugs-announce] [issue18008] python33-3.3.2 Parser/pgen:
	Permission denied
Message-ID: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za>


New submission from William Moreno:

cc -DNDEBUG -O2 -pipe  -fno-strict-aliasing -pthread  -pthread Parser/acceler.o  Parser/grammar1.o  Parser/listnode.o  Parser/node.o  Parser/parser.o  Parser/bitset.o  Parser/metagrammar.o  Parser/firstsets.o  Parser/grammar.o  Parser/pgen.o Objects/obmalloc.o  Python/dynamic_annotations.o  Python/mysnprintf.o  Python/pyctype.o  Parser/tokenizer_pgen.o  Parser/printgrammar.o  Parser/parsetok_pgen.o  Parser/pgenmain.o -lutil -o Parser/pgen
`Parser/pgen' is up to date.
Parser/pgen ./../Grammar/Grammar Include/graminit.h Python/graminit.c
Parser/pgen: Permission denied
*** [Include/graminit.h] Error code 126
cc -c  -DNDEBUG -O2 -pipe  -fno-strict-aliasing -O2 -pipe  -fno-strict-aliasing -O2 -pipe  -fno-strict-aliasing    -I. -IInclude -I./../Include    -DPy_BUILD_CORE -o Objects/typeobject.o ./../Objects/typeobject.c
/usr/lib/crt1.o: In function `_start':
crt1.c:(.text+0x8a): undefined reference to `main'
Parser/bitset.o: In function `_Py_newbitset':
bitset.c:(.text+0xfa): undefined reference to `Py_FatalError'
Parser/firstsets.o: In function `calcfirstset':
firstsets.c:(.text+0x15): undefined reference to `Py_DebugFlag'
firstsets.c:(.text+0x1d9): undefined reference to `Py_DebugFlag'
firstsets.c:(.text+0x20f): undefined reference to `Py_FatalError'
firstsets.c:(.text+0x329): undefined reference to `Py_FatalError'
Parser/firstsets.o: In function `_Py_addfirstsets':
firstsets.c:(.text+0x345): undefined reference to `Py_DebugFlag'
Parser/grammar.o: In function `_Py_translatelabels':
grammar.c:(.text+0x87): undefined reference to `Py_DebugFlag'
grammar.c:(.text+0x10d): undefined reference to `Py_DebugFlag'
grammar.c:(.text+0x205): undefined reference to `Py_DebugFlag'
grammar.c:(.text+0x234): undefined reference to `Py_DebugFlag'
Parser/grammar.o: In function `_Py_findlabel':
grammar.c:(.text+0x452): undefined reference to `Py_FatalError'
Parser/grammar.o: In function `_Py_addarc':
grammar.c:(.text+0x4ec): undefined reference to `Py_FatalError'
Parser/grammar.o: In function `_Py_addstate':
grammar.c:(.text+0x588): undefined reference to `Py_FatalError'
Parser/grammar.o: In function `_Py_addlabel':
grammar.c:(.text+0x63b): undefined reference to `Py_DebugFlag'
grammar.c:(.text+0x675): undefined reference to `Py_FatalError'
Parser/grammar.o: In function `_Py_adddfa':
grammar.c:(.text+0x72e): undefined reference to `Py_FatalError'
Parser/grammar.o: In function `_Py_newgrammar':
grammar.c:(.text+0x7a6): undefined reference to `Py_FatalError'
Parser/pgen.o: In function `addnfaarc':
pgen.c:(.text+0x76): undefined reference to `Py_FatalError'
Parser/pgen.o: In function `addnfastate':
pgen.c:(.text+0xd6): undefined reference to `Py_FatalError'
Parser/pgen.o: In function `_Py_pgen':
pgen.c:(.text+0x5f4): undefined reference to `Py_DebugFlag'
pgen.c:(.text+0x744): undefined reference to `Py_FatalError'
pgen.c:(.text+0x799): undefined reference to `Py_FatalError'
pgen.c:(.text+0x7ee): undefined reference to `Py_DebugFlag'
pgen.c:(.text+0xaa3): undefined reference to `Py_DebugFlag'
pgen.c:(.text+0xb86): undefined reference to `Py_DebugFlag'
pgen.c:(.text+0xc96): undefined reference to `Py_FatalError'
pgen.c:(.text+0xca5): undefined reference to `Py_FatalError'
pgen.c:(.text+0xcb1): undefined reference to `Py_DebugFlag'
pgen.c:(.text+0xeed): undefined reference to `Py_FatalError'
pgen.c:(.text+0xefc): undefined reference to `Py_FatalError'
Parser/tokenizer_pgen.o: In function `indenterror':
tokenizer_pgen.c:(.text+0x3a6): undefined reference to `PySys_WriteStderr'
Parser/tokenizer_pgen.o: In function `tok_nextc':
tokenizer_pgen.c:(.text+0x605): undefined reference to `PyOS_Readline'
tokenizer_pgen.c:(.text+0x6ef): undefined reference to `PySys_WriteStderr'
Parser/tokenizer_pgen.o: In function `tok_backup':
tokenizer_pgen.c:(.text+0xa98): undefined reference to `Py_FatalError'
Parser/parsetok_pgen.o: In function `PyParser_ParseStringFlagsFilenameEx':
parsetok_pgen.c:(.text+0x5e3): undefined reference to `PyErr_Occurred'
*** [Parser/pgen] Error code 1
1 error
*** [Include/graminit.h] Error code 2
1 error
*** [Python/importlib.h] Error code 2
2 errors
*** [do-build] Error code 1

Stop in /usr/ports/lang/python33.
*** [install] Error code 1

Stop in /usr/ports/lang/python33.
root at server:/usr/ports/lang/python33 # make clean
===>  Cleaning for python33-3.3.2

----------
components: Build
messages: 189524
nosy: wmoreno3
priority: normal
severity: normal
status: open
title: python33-3.3.2 Parser/pgen: Permission denied
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Sat May 18 18:44:29 2013
From: report at bugs.python.org (Shai Berger)
Date: Sat, 18 May 2013 16:44:29 +0000
Subject: [New-bugs-announce] [issue18009] os.write.__doc__ is misleading
Message-ID: <1368895469.2.0.802658153503.issue18009@psf.upfronthosting.co.za>


New submission from Shai Berger:

At least on posix systems, os.write says it takes a string, but in fact it barfs on strings -- it needs bytes.

$ python
Python 3.3.1 (default, May  6 2013, 16:18:33) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print(os.write.__doc__)
write(fd, string) -> byteswritten

Write a string to a file descriptor.
>>> os.write(1, "hello")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface
>>> os.write(1, b"hello")
hello5
>>>

----------
messages: 189535
nosy: shai
priority: normal
severity: normal
status: open
title: os.write.__doc__ is misleading
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat May 18 19:05:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 18 May 2013 17:05:19 +0000
Subject: [New-bugs-announce] [issue18010] pydoc search chokes on import
	errors
Message-ID: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

After installing Django, I get the following error in test_pydoc:

======================================================================
FAIL: test_url_requests (test.test_pydoc.PydocUrlHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/finalize/Lib/test/test_pydoc.py", line 581, in test_url_requests
    self.assertEqual(result, title, text)
AssertionError: 'Pydoc: Error - search?key=pydoc' != 'Pydoc: Search Results'
- Pydoc: Error - search?key=pydoc
+ Pydoc: Search Results

The reason is attempting to import a django.something module raises the following error:

django.core.exceptions.ImproperlyConfigured: Requested setting DATABASES, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings

... which isn't silenced by pydoc.

Now I agree this is fundamentally obnoxious on Django's part, but unfortunately it isn't the only package (IIRC) to behave in this way, meaning it would be nice from pydoc to silence all such errors when an import is attempted.

----------
components: Library (Lib)
messages: 189536
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc search chokes on import errors
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 19 10:19:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 May 2013 08:19:09 +0000
Subject: [New-bugs-announce] [issue18011] Inconsistency between b32decode()
	documentation, docstring and code
Message-ID: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

b32decode() documentation says: "A TypeError is raised if s were incorrectly padded or if there are non-alphabet characters present in the string."

b32decode() docstring says: "binascii.Error is raised if the input is incorrectly padded or if there are non-alphabet characters present in the input."

Actually binascii.Error (which is a ValueError subtype) is raised if the input is incorrectly padded and TypeError is raised if there are non-alphabet characters present in the input.

At least 2 of 3 (documentation, docstring and implementation) should be corrected.

Base32 support was originally added in 3cc0d8fd4e2b (TypeError was used everywhere) and then modified in eb45f85c4c79 (TypeError was partially changed to binascii.Error).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 189571
nosy: barry, docs at python, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency between b32decode() documentation, docstring and code
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 19 16:17:57 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 19 May 2013 14:17:57 +0000
Subject: [New-bugs-announce] [issue18012] cannot assign unicode keys to
	SimpleCookie
Message-ID: <1368973077.46.0.479375460496.issue18012@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

from Cookie import SimpleCookie

cookie = SimpleCookie()
cookie[u'apple'] = u'green'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 592, in __setitem__
    self.__set(key, rval, cval)
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 585, in __set
    M.set(key, real_value, coded_value)
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 459, in set
    if "" != translate(key, idmap, LegalChars):
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/string.py", line 493, in translate
    return s.translate(table, deletions)
TypeError: translate() takes exactly one argument (2 given)



The documentation don't say it's not supported.
And the error TypeError seems not appropriate.

----------
components: Library (Lib)
messages: 189595
nosy: flox
priority: normal
severity: normal
status: open
title: cannot assign unicode keys to SimpleCookie
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun May 19 19:45:09 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 19 May 2013 17:45:09 +0000
Subject: [New-bugs-announce] [issue18013] cgi.FieldStorage does not parse
	W3C sample
Message-ID: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

Trying to parse the W3C sample, it fails in 3.3 (while it passes on 2.7).
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 (last example)

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --BbC04y
   Content-Disposition: file; filename="file2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contents of file2.gif...
   --BbC04y--
   --AaB03x--

(broken) test attached.

----------
components: Library (Lib)
files: test_multipart_w3.diff
keywords: patch
messages: 189609
nosy: flox, orsenthil
priority: normal
severity: normal
status: open
title: cgi.FieldStorage does not parse W3C sample
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30313/test_multipart_w3.diff

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

From report at bugs.python.org  Sun May 19 19:53:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 May 2013 17:53:15 +0000
Subject: [New-bugs-announce] [issue18014] Problem compiling on Windows,
	VC++Express 2010
Message-ID: <1368985995.62.0.842732310972.issue18014@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

64-bit Win 7 Professional, using default F7 debug build -- F7
Running as normal user, not admin.

3.4: built Thursday, Saturday; failed Wednesday, Friday, today Sunday.

7> cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd -DHGBRANCH=\"default\" -DHGTAG=\"tip\" -DHGVERSION=\"79bf4e7e4004\" ..\Modules\getbuildinfo.c -Fo"D:\Python\dev\cpython\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC
7>  Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
7>  Copyright (C) Microsoft Corporation.  All rights reserved.
7>  
7>  getbuildinfo.c
7>LINK : fatal error LNK1104: cannot open file 'D:\Python\dev\cpython\PCbuild\python34_d.dll'

I 'updated' back about 24 hours to rev 83828: worked. Forward to rev 83829: failed. This made no sense so back to '28: failed. Delete python34_d.dll: works. Update to tip: works. Try again: fails.

What I believe to be the case: if python34_d.dll is rebuilt, python_d.exe is built. If not, it 'cannot be opened' even though it is sitting there. I cannot be sure if this was always the case as I did not try to rebuild very ofter.

--
3.3 I have not been able to rebuild python_d.exe since May 7. I currently get

7>..\PC\pylauncher.rc(16): error RC2104: undefined keyword or key name: FIELD3 (for pywlauncher project)

10>..\PC\pylauncher.rc(16): error RC2104: undefined keyword or key name: FIELD3

9>..\PC\python_nt.rc(35): error RC2104: undefined keyword or key name: MS_DLL_ID (for pythoncore project)

Failure of pythoncore stops the dependent projects. I have no idea how I might work around this.

----------
components: Build, Windows
messages: 189612
nosy: brian.curtin, steve.dower, terry.reedy, tim.golden
priority: normal
severity: normal
status: open
title: Problem compiling on Windows, VC++Express 2010
type: compile error
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 19 20:41:59 2013
From: report at bugs.python.org (Anselm Kruis)
Date: Sun, 19 May 2013 18:41:59 +0000
Subject: [New-bugs-announce] [issue18015] python 2.7.5 fails to unpickle
	namedtuple pickled by	2.7.3 or 2.7.4
Message-ID: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

Change 18303391b981 breaks unpickling named tuples pickled by 2.7.3 and 2.7.4.

See closed issue #15535 for the full story. Unfortunately Raymond was wrong, when he wrote that the addition of __dict__ was a 2.7.4 change. It was added by changeset 26d5f022eb1a in 2.7.3.

Now 2.7.5 can't unpickle any named tuples pickled by 2.7.3, which is probably one of the most widely used python versions.


Example:

Pickle a namd tuple using 2.7.3 and unpickle it using 2.7.5.

anselm at Emmy:~$ python2.7
Python 2.7.3 (default, Sep 16 2012, 21:46:37) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import collections
>>> import pickletools
>>> import pickle
>>> N=collections.namedtuple("N","a")
>>> n=N(1)
>>> p=pickle.dumps(n, 2)
>>> p2=pickletools.optimize(p)
>>> pickletools.dis(p2)
    0: \x80 PROTO      2
    2: c    GLOBAL     '__main__ N'
   14: K    BININT1    1
   16: \x85 TUPLE1
   17: \x81 NEWOBJ
   18: c    GLOBAL     'collections OrderedDict'
   43: ]    EMPTY_LIST
   44: ]    EMPTY_LIST
   45: (    MARK
   46: U        SHORT_BINSTRING 'a'
   49: K        BININT1    1
   51: e        APPENDS    (MARK at 45)
   52: a    APPEND
   53: \x85 TUPLE1
   54: R    REDUCE
   55: b    BUILD
   56: .    STOP
highest protocol among opcodes = 2
>>> print repr(p2)
'\x80\x02c__main__\nN\nK\x01\x85\x81ccollections\nOrderedDict\n]](U\x01aK\x01ea\x85Rb.'


anselm at Emmy:~/sc/eclipsews/fg2py$ fg2python
Python 2.7.5 (default, May 18 2013, 17:02:17) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> import collections
>>> N=collections.namedtuple("N","a")
>>> pickle.loads('\x80\x02c__main__\nN\nK\x01\x85\x81ccollections\nOrderedDict\n]](U\x01aK\x01ea\x85Rb.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 1419, in loads
    return Unpickler(file).load()
  File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 895, in load
    dispatch[key](self)
  File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 1261, in load_build
    d = inst.__dict__
AttributeError: 'N' object has no attribute '__dict__'


As we can see from the trace back, the problem arises from the pickle op-code 'BUILD'. BUILD requires that the object to be build either has a method __setstate__ or has an attribute __dict__. Therefore I propose:

- Revert change 18303391b981 and add a __getstate__ method
  This is the Python 3 fix for the problem.

or

- Add a method __setstate__:

  def __setstate__(self, state): 
     """For compatibility with Python 2.7.3 and 2.7.4"""
     pass

----------
components: Library (Lib)
messages: 189614
nosy: anselm.kruis, rhettinger
priority: normal
severity: normal
status: open
title: python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun May 19 22:29:13 2013
From: report at bugs.python.org (Jason Gross)
Date: Sun, 19 May 2013 20:29:13 +0000
Subject: [New-bugs-announce] [issue18016] subprocess should open stdin in
	mode w+b on windows
Message-ID: <1368995353.89.0.988630901542.issue18016@psf.upfronthosting.co.za>


New submission from Jason Gross:

Files opened on Windows in mode 'wb' have a limit on the number of characters that can be written to them (at once?); attempting to write too many bytes gives the confusing error ?IOError: [Errno 22] Invalid argument?.  See http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 and http://stackoverflow.com/questions/4226941/python-ioerror-errno-22-invalid-argument-when-using-cpickle-to-write-large.  I have gotten this error when using subprocess.communicate(input=<large string>).  Please fix the subprocess library (and any other library that uses mode 'wb') to use mode 'w+b', at least on Windows.

----------
components: Library (Lib)
messages: 189624
nosy: Jason.Gross
priority: normal
severity: normal
status: open
title: subprocess should open stdin in mode w+b on windows
versions: Python 2.7

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

From report at bugs.python.org  Mon May 20 02:38:39 2013
From: report at bugs.python.org (=?utf-8?q?Marc_Br=C3=BCnink?=)
Date: Mon, 20 May 2013 00:38:39 +0000
Subject: [New-bugs-announce] [issue18017] ctypes.PyDLL documentation
Message-ID: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>


New submission from Marc Br?nink:

The documentation for is not very clear regarding the usage of CDLL and PyDLL. Especially it is not obvious that you should use PyDLL whenever you call any function of the Python/C API. Since calling a Python/C API function without owning the GIL will most likely cause latent segfaults, I think it warrants a warning box in section 16.17.2.2 and maybe also somewhere prominent in http://docs.python.org/dev/c-api/intro.html.

For section 16.17.2.2 I would put a box next the decription of CDLL saying something like: "The Python GIL is released before a function call. It is not safe to call any Pyhon/C API function within the loaded library without acquiring the GIL first. Thus, if the loaded library calls functions of the Python/C API, for example in case it creates and returns a new Python object, and does not manually acquire and release the GIL, use PyDLL instead."

----------
assignee: docs at python
components: Documentation
messages: 189629
nosy: Marc.Br?nink, docs at python
priority: normal
severity: normal
status: open
title: ctypes.PyDLL documentation
versions: Python 3.5

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

From report at bugs.python.org  Mon May 20 03:01:48 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 20 May 2013 01:01:48 +0000
Subject: [New-bugs-announce] [issue18018] SystemError: Parent module '' not
	loaded, cannot perform relative import
Message-ID: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

When executing a submodule, there's a SystemError in 3.3 where we used to receive a ValueError.

mkdir marsu
touch marsu/__init__.py
echo "from .houba import bi" >> marsu/pilami.py

./python marsu/pilami.py

Traceback (most recent call last):
  File "marsu/pilami.py", line 2, in <module>
    from .houba import bi
SystemError: Parent module '' not loaded, cannot perform relative import


In Python 3.2 (or Python 2.7):

./python3.2 marsu/pilami.py

Traceback (most recent call last):
  File "marsu/pilami.py", line 2, in <module>
    from .houba import bi
ValueError: Attempted relative import in non-package

----------
components: Interpreter Core
keywords: 3.3regression
messages: 189630
nosy: brett.cannon, eric.snow, flox, ncoghlan
priority: normal
severity: normal
status: open
title: SystemError: Parent module '' not loaded, cannot perform relative import
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May 20 04:18:42 2013
From: report at bugs.python.org (Marcin Szamotulski)
Date: Mon, 20 May 2013 02:18:42 +0000
Subject: [New-bugs-announce] [issue18019] dictionary views lead to
	segmentation fault
Message-ID: <1369016322.42.0.272832887604.issue18019@psf.upfronthosting.co.za>


New submission from Marcin Szamotulski:

This simple snipet will crash python:
>>> d={}
>>> v=d.viewvalues()
>>> k=d.viewkeys()
>>> d[v]=k
>>> k
Segmentation fault

I am using python2.7.  Python3.2 does not have views while .keys() and .values() methods raise RuntimeError: maximum recursion depth exceeded, which is expected.

----------
messages: 189632
nosy: Marcin.Szamotulski
priority: normal
severity: normal
status: open
title: dictionary views lead to segmentation fault
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon May 20 10:21:38 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 20 May 2013 08:21:38 +0000
Subject: [New-bugs-announce] [issue18020] html.escape 10x slower than
	cgi.escape
Message-ID: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

I noticed the convenient ``html.escape`` in Python 3.2 and ``cgi.escape`` is marked as deprecated.


However, the former is an order of magnitude slower than the latter.

$ python3 --version
Python 3.3.2


With html.escape:

$ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright)" "h = html(s)"
10000 loops, best of 3: 48.7 usec per loop
$ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright) * 19" "h = html(s)"
1000 loops, best of 3: 898 usec per loop

With cgi.escape:

$ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright)" "h = escape(s)"
100000 loops, best of 3: 7.42 usec per loop
$ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright) * 19" "h = escape(s)"
10000 loops, best of 3: 21.5 usec per loop


Since this kind of function is called frequently in template engines, it makes a difference.
Of course C replacements are available on PyPI: MarkupSafe or Webext

But it would be nice to restore the performance of cgi.escape with a pragmatic `.replace(` approach.

----------
components: Library (Lib)
messages: 189641
nosy: ezio.melotti, flox, orsenthil
priority: normal
severity: normal
status: open
title: html.escape 10x slower than cgi.escape
type: performance
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 20 15:12:18 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 20 May 2013 13:12:18 +0000
Subject: [New-bugs-announce] [issue18021] Update broken link to Apple
	Publication Style Guide
Message-ID: <1369055538.2.0.556134337366.issue18021@psf.upfronthosting.co.za>


New submission from Madison May:

The links at http://docs.python.org/devguide/documenting.html#building-doc and http://docs.python.org/devguide/docquality.html to http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf lead to a "Page Not Found" message and a redirect to http://developer.apple.com/library/mac/navigation/.  This url should be updated to point to another copy of the 2009 style guide or https://help.apple.com/asg/mac/2013/ASG_2013.pdf, the 2013 version of Apple's Style Guide.

----------
components: Devguide
messages: 189659
nosy: Madison.May, ezio.melotti
priority: normal
severity: normal
status: open
title: Update broken link to Apple Publication Style Guide
type: enhancement

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

From report at bugs.python.org  Mon May 20 16:13:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 May 2013 14:13:28 +0000
Subject: [New-bugs-announce] [issue18022] Inconsistency between
	quopri.decodestring() and	email.quoprimime.decode()
Message-ID: <1369059208.07.0.0770184639372.issue18022@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import quopri, email.quoprimime
>>> quopri.decodestring(b'==41')
b'=41'
>>> email.quoprimime.decode('==41')
'=A'

I don't see a rule about double '=' in RFC 1521-1522 or RFCs 2045-2047 and I think quopri is wrong.

Other half of this bug (encoding '=' as '==') was fixed in 9bc52706d283.

----------
components: Library (Lib), email
messages: 189663
nosy: Jeremy.Hylton, barry, gvanrossum, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency between quopri.decodestring() and email.quoprimime.decode()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May 20 21:56:02 2013
From: report at bugs.python.org (Anselm Kruis)
Date: Mon, 20 May 2013 19:56:02 +0000
Subject: [New-bugs-announce] [issue18023] msi product code for 2.7.5150 not
	in Tools/msi/uuids.py
Message-ID: <1369079762.11.0.597354582837.issue18023@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

The file Tools/msi/uuids.py contains the product codes for all recently released Python 2.x versions except 2.7.5. Without this code it is not possible to recreate the MSI installer using Tools\msi\msi.py. 

The product code of http://www.python.org/ftp/python/2.7.5/python-2.7.5.msi is '{DBDD570E-0952-475F-9453-AB88F3DD5659}'.

----------
components: Build, Windows
messages: 189686
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: msi product code for 2.7.5150 not in Tools/msi/uuids.py
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon May 20 22:11:50 2013
From: report at bugs.python.org (Kristofer Wempa)
Date: Mon, 20 May 2013 20:11:50 +0000
Subject: [New-bugs-announce] [issue18024] dbm module fails to build on
	SLES11SP1 using 2.7.5 source
Message-ID: <1369080710.44.0.400005629221.issue18024@psf.upfronthosting.co.za>


New submission from Kristofer Wempa:

I recently built a new version of our Linux tools using Python 2.7.5 on our SLES11SP2 server.  Afterwards, I noticed that the dbm module was not built successfully.  The Python build did not fail and the failed module build summary at the end of the build did not list "dbm", which surprised me.  I rebuilt Python and captured the actual error when attempting to build the dbm module.  Below is the error.  I managed to get it to build by replacing "-lndbm" with "-lgdbm".  This is the first time dbm has failed to build on this platform.  I've built several versions of Python 2.7.2, 2.7.3 and 2.7.4 and this module built every single time.  Something that has changed in the build process is causing this problem.



Link Error:

gcc -pthread -shared build/temp.linux-x86_64-2.7/nfs/statbuild/ci1admin/ci1_toolchain_src/KRIS/Python-2.7.5/Modules/dbmmodule.o -L/usr/lib -L/lib -L/usr/x86_64-suse-linux/lib -L/lib64 -L/usr/lib64 -L/usr/local/lib -lndbm -o build/lib.linux-x86_64-2.7/dbm.so
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libgdbm.so when searching for /usr/lib/libgdbm.so
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find /usr/lib/libgdbm.so
collect2: ld returned 1 exit status

----------
components: Build
messages: 189687
nosy: wempa
priority: normal
severity: normal
status: open
title: dbm module fails to build on SLES11SP1 using 2.7.5 source
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Mon May 20 22:34:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 May 2013 20:34:38 +0000
Subject: [New-bugs-announce] [issue18025] Buffer overflow in
	BufferedIOBase.readinto()
Message-ID: <1369082078.59.0.190906066186.issue18025@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

BufferedIOBase.readinto() overflows output buffer if read() returns more data than requested. Here is a patch.

See also related issue17872.

----------
assignee: serhiy.storchaka
components: Extension Modules, IO
files: bufferedio_buffer_overflow.patch
keywords: patch
messages: 189691
nosy: benjamin.peterson, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Buffer overflow in BufferedIOBase.readinto()
type: crash
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30323/bufferedio_buffer_overflow.patch

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

From report at bugs.python.org  Mon May 20 23:06:37 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 20 May 2013 21:06:37 +0000
Subject: [New-bugs-announce] [issue18026] Typo in ctypes documentation
Message-ID: <1369083997.94.0.835709293593.issue18026@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

http://docs.python.org/3/library/ctypes.html#finding-shared-libraries reads:
"If wrapping a shared library with ctypes, it may be better to determine the shared library name at development type, and hardcode ..."

Shouldn't that be "... at development time, ..."?

----------
assignee: docs at python
components: Documentation
messages: 189693
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: Typo in ctypes documentation

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

From report at bugs.python.org  Mon May 20 23:27:22 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 20 May 2013 21:27:22 +0000
Subject: [New-bugs-announce] [issue18027] distutils should access
	stat_result timestamps via	.st_*time attributes
Message-ID: <1369085242.54.0.746637584547.issue18027@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

Currently distutils accesses stat_result timestamps like this:

  os.stat(source)[ST_MTIME]

But, for compatibility with older Python versions, the above method gives you at most 1-second resolution. It should do it like this instead:

  os.stat(source).st_mtime

----------
assignee: eric.araujo
components: Distutils
messages: 189695
nosy: eric.araujo, jwilk, tarek
priority: normal
severity: normal
status: open
title: distutils should access stat_result timestamps via .st_*time attributes

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

From report at bugs.python.org  Tue May 21 10:32:22 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 21 May 2013 08:32:22 +0000
Subject: [New-bugs-announce] [issue18028] Warnings with -fstrict-aliasing
Message-ID: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Hi,
I'm getting these warnings with -fstrict-aliasing, compiling Python 3.3.2 (compiling with gcc 4.4.7):

/builddir/build/BUILD/Python-3.3.2/Python/ceval.c: In function 'PyEval_EvalFrameEx':
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1006: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1007: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1008: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1009: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1249: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1258: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1372: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2358: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2377: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2379: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2388: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2390: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2743: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2745: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2909: warning: dereferencing type-punned pointer will break strict-aliasing rules
/builddir/build/BUILD/Python-3.3.2/Python/ceval.c:3035: warning: dereferencing type-punned pointer will break strict-aliasing rules

This seems to be quite serious, but I'm not a C expert, so I'd like to know whether this is a false positive or this is actually a dangerous bug.
Thanks.

----------
components: Build
messages: 189729
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Warnings with -fstrict-aliasing
versions: Python 3.3

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

From report at bugs.python.org  Tue May 21 17:00:11 2013
From: report at bugs.python.org (Donal Duane)
Date: Tue, 21 May 2013 15:00:11 +0000
Subject: [New-bugs-announce] [issue18029] Python SSL support is missing from
	SPARC build
Message-ID: <1369148411.16.0.857951754305.issue18029@psf.upfronthosting.co.za>


New submission from Donal Duane:

Hi,

We have 2 Python 3.2 builds - one on x86 (Solaris 10), and one on SPARC (Solaris 10).

The x86 build works fine for SSL, but the SPARC build was either built without SSL support pecified, or, there was an issue with the build.


$ bash $ . /etc/opt/ericsson/system.env $ export PYTHONPATH PYTHONHOME PYTHON_HOME_3PP
$ /opt/python/python/python3.2 Python 3.2.2 (default, Nov 16 2011, 05:23:55)
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import _ssl Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named _ssl 
>>> 

$ ls -l /opt/python/python/lib-dynload/ | grep ssl -r-xr-xr-x 1 root other 110604 Nov 21 2011 _ssl_failed.so



are there any know issues with building in SSL support to Python 3.2 on Solaris SPARC 10?

If not - is there anyway to include it POST-compile?

Any support much appreciated.

Regards,
D?nal

----------
components: Extension Modules
messages: 189762
nosy: eeiddne
priority: normal
severity: normal
status: open
title: Python SSL support is missing from SPARC build
type: security
versions: Python 3.2

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

From report at bugs.python.org  Wed May 22 04:58:12 2013
From: report at bugs.python.org (Marc)
Date: Wed, 22 May 2013 02:58:12 +0000
Subject: [New-bugs-announce] [issue18030] IDLE shell crashes when reporting
	errors in Windows 7
Message-ID: <1369191492.92.0.0405253536514.issue18030@psf.upfronthosting.co.za>


New submission from Marc:

Using TkInter as gui, running a module that worked in 3.0 (I believe). 

It is trying to print a warning message about 

RuntimeWarning: overflow encountered in double_scalars

and stops my process (running eval) returning this error

  File "C:\Python32\lib\idlelib\PyShell.py", line 59, in idle_showwarning
    file.write(warnings.formatwarning(message, category, filename,
AttributeError: 'NoneType' object has no attribute 'write'

If I use python -m idlelib.idle it doesn't happen; it just prints the error.

Previously this worked fine using the shell as stdout. This is similar to a bug about symbols' errors however it has been closed and this one is not about symbols. http://bugs.python.org/issue14200

I don't really know a lot about programming and don't often submit bugs so sorry if I've missed any major details here.

Marc

----------
components: IDLE
messages: 189788
nosy: marcopolo
priority: normal
severity: normal
status: open
title: IDLE shell crashes when reporting errors in Windows 7
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Wed May 22 07:58:22 2013
From: report at bugs.python.org (Carlos Nepomuceno)
Date: Wed, 22 May 2013 05:58:22 +0000
Subject: [New-bugs-announce] [issue18031] The Python Tutorial says % string
	formatting will be	removed
Message-ID: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za>


New submission from Carlos Nepomuceno:

It[1] says:
"Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used."

[1] http://docs.python.org/2/tutorial/inputoutput.html#old-string-formatting

----------
assignee: docs at python
components: Documentation
messages: 189791
nosy: Carlos.Nepomuceno, docs at python
priority: normal
severity: normal
status: open
title: The Python Tutorial says % string formatting will be removed
versions: Python 2.7

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

From report at bugs.python.org  Wed May 22 13:58:43 2013
From: report at bugs.python.org (Abafei)
Date: Wed, 22 May 2013 11:58:43 +0000
Subject: [New-bugs-announce] [issue18032] set methods should specify whether
	they consume	iterators "lazily"
Message-ID: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za>


New submission from Abafei:

It says here (http://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset) that some of the set methods take iterables as a parameter.

Usually, the expected behavior is for a iterator consumer to consume only as much data as it needs. For example, for the code `any(itertools.repeat(True))`, the code will complete speedily, in contrast to when all() is used instead of any(), in which case the code will go forever.

A least some of the set methods have semantics such that they can consume only some of the input; for example, "issubset" only needs to make sure that all of the items in the set are in the iterable, and once this is the case, it can return "True".

However in such a case, the methods will *still* go forever.

The docs should specify that this is the case, to disambiguate the semantics.

(Tested on Python 3.2.3 and 2.7.3).

----------
assignee: docs at python
components: Documentation
messages: 189806
nosy: Abafei, docs at python
priority: normal
severity: normal
status: open
title: set methods should specify whether they consume iterators "lazily"
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed May 22 17:12:38 2013
From: report at bugs.python.org (Jough Dempsey)
Date: Wed, 22 May 2013 15:12:38 +0000
Subject: [New-bugs-announce] [issue18033] Example for Profile Module shows
	incorrect method
Message-ID: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za>


New submission from Jough Dempsey:

The example on this page:
http://docs.python.org/2/library/profile.html?highlight=pstats#profile.Profile

Shows:

import cProfile, pstats, io
pr = cProfile.Profile()
pr.enable()
... do something ...
pr.disable()
s = io.StringIO()
ps = pstats.Stats(pr, stream=s)
ps.print_results()

Where "ps.print_results()" should be "ps.print_stats()"

----------
assignee: docs at python
components: Documentation
messages: 189823
nosy: docs at python, jough
priority: normal
severity: normal
status: open
title: Example for Profile Module shows incorrect method
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 22 19:35:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 May 2013 17:35:15 +0000
Subject: [New-bugs-announce] [issue18034] Last two entries in the
	programming FAQ are out of date	(import related)
Message-ID: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za>


New submission from R. David Murray:

The second to last talks about the __import__ quirk with out calling __import__ out as deprecated.  The last uses the imp module for reload.

----------
assignee: docs at python
components: Documentation
messages: 189827
nosy: brett.cannon, docs at python, eric.snow, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Last two entries in the programming FAQ are out of date (import related)
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 22 19:36:57 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 May 2013 17:36:57 +0000
Subject: [New-bugs-announce] [issue18035] telnetlib incorrectly assumes that
	select.error has an	errno attribute
Message-ID: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

In Python 2.7.3 through 2.7.5 the telnetlib select.poll based implementation assumes that select.error has an errno attribute when handling errors.  it does not.  select.error is not an EnvironmentError derived exception.

http://hg.python.org/cpython/file/85c04fdaa404/Lib/telnetlib.py#l317

i haven't check 3.x yet.

----------
messages: 189828
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: telnetlib incorrectly assumes that select.error has an errno attribute
versions: Python 2.7

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

From report at bugs.python.org  Wed May 22 19:37:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 May 2013 17:37:51 +0000
Subject: [New-bugs-announce] [issue18036] "How do I create a .pyc file?" FAQ
	entry is out of date
Message-ID: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za>


New submission from R. David Murray:

It doesn't talk about __pycache__.

----------
messages: 189829
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: "How do I create a .pyc file?" FAQ entry is out of date
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 22 23:46:44 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 22 May 2013 21:46:44 +0000
Subject: [New-bugs-announce] [issue18037] 2to3 passes through string literal
	which causes	SyntaxError in 3.x
Message-ID: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

"""
This string contains DOMAIN\username, which is talking about Windows
and is a valid string in Python 2.x but not in 3.x. However, 2to3 passes
this string through unchanged, and it causes a SyntaxError when
interpreted by Python 3.x, because it contains what looks like a
truncated Unicode escape.
"""

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 189837
nosy: benjamin.peterson, vinay.sajip
priority: normal
severity: normal
status: open
title: 2to3 passes through string literal which causes SyntaxError in 3.x
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 23 00:43:16 2013
From: report at bugs.python.org (Max Cantor)
Date: Wed, 22 May 2013 22:43:16 +0000
Subject: [New-bugs-announce] [issue18038] Unhelpful error message on invalid
	encoding specification
Message-ID: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za>


New submission from Max Cantor:

When you specify a nonexistent encoding at the top of a file, like so for example:

# -*- coding: fakefakefoobar -*-

The following exception occurs:

SyntaxError: encoding problem: with BOM

This is very unhelpful, especially in cases where you might have made a typo in the encoding.

----------
components: Library (Lib)
messages: 189840
nosy: Max.Cantor
priority: normal
severity: normal
status: open
title: Unhelpful error message on invalid encoding specification
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 23 02:39:58 2013
From: report at bugs.python.org (Sashko Kopyl)
Date: Thu, 23 May 2013 00:39:58 +0000
Subject: [New-bugs-announce] [issue18039] dbm.open(...,
	flag="n") does not work and does not give a warning
Message-ID: <1369269598.14.0.669972141851.issue18039@psf.upfronthosting.co.za>


New submission from Sashko Kopyl:

I use Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32.

dbm.open(..., flag="n") is supposed to "Always create a new, empty database, open for reading and writing".
In Windows case it does not. So I cannot empty a dbm database when I need it.

http://docs.python.org/3/library/dbm.html#module-dbm.dumb
Here it is written:
"The optional flag argument is currently ignored; the database is always opened for update, and will be created if it does not exist."

If it is ignored, there should be at least a warning. How am I supposed to now that this is a known bug?

----------
components: Library (Lib)
messages: 189841
nosy: sonyachiko
priority: normal
severity: normal
status: open
title: dbm.open(..., flag="n") does not work and does not give a warning
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May 23 05:01:06 2013
From: report at bugs.python.org (David Gilman)
Date: Thu, 23 May 2013 03:01:06 +0000
Subject: [New-bugs-announce] [issue18040] SIGINT catching regression on
	windows in 2.7
Message-ID: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za>


New submission from David Gilman:

I opened this StackOverflow bug with an example simplified testcase.  As you can see in the first comment a user added that this code worked under Python 2.6 on Windows and no longer works on 2.7.

http://stackoverflow.com/questions/16686510/how-do-i-capture-sigint-in-python-on-windows?noredirect=1#comment24013681_16686510

Here's a patch that went into the 2.7 release that maybe is related? http://bugs.python.org/issue1677

----------
messages: 189843
nosy: David.Gilman
priority: normal
severity: normal
status: open
title: SIGINT catching regression on windows in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Thu May 23 05:37:31 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 23 May 2013 03:37:31 +0000
Subject: [New-bugs-announce] [issue18041] mention issues with code churn in
	the devguide
Message-ID: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I've seen complaints about code churn a few times, example: http://bugs.python.org/issue16510#msg175956. Would be nice if this was documented in the devguide.

----------
components: Devguide
messages: 189844
nosy: ezio.melotti, tshepang
priority: normal
severity: normal
status: open
title: mention issues with code churn in the devguide

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

From report at bugs.python.org  Thu May 23 10:56:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 23 May 2013 08:56:18 +0000
Subject: [New-bugs-announce] [issue18042] Provide enum.unique class decorator
Message-ID: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Another attempt at tackling the "but I want to ensure my enum values are unique" problem that PEP 435 deliberately chose not to handle. My previous suggestion (in issue 17959) was rightly rejected due to the other problems it caused, but this idea is much cleaner and simpler.

All we would need to do is provide the following class decorator in the enum module:

    def unique(new_enum):
        for name, member in new_enum.__members__.items():
            if name != member.name:
                msg = "Alias {!r} for {!r} not permitted in unique Enum"
                raise TypeError(msg.format(name, member))
        return new_enum

Used as so:

>>> @enum.unique
... class MyEnum(enum.Enum):
...     a = 1
...     b = 2
...     c = 1
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "<stdin>", line 6, in unique
TypeError: Alias 'c' for <MyEnum.a: 1> not permitted in unique Enum

----------
components: Library (Lib)
messages: 189854
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide enum.unique class decorator
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu May 23 13:28:57 2013
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 23 May 2013 11:28:57 +0000
Subject: [New-bugs-announce] [issue18043] No mention of `match.regs` in `re`
	documentation
Message-ID: <1369308537.81.0.515783227267.issue18043@psf.upfronthosting.co.za>


New submission from Ram Rachum:

There's no mention of `match.regs` in the documentation of the `re` module.

----------
assignee: docs at python
components: Documentation
messages: 189859
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: No mention of `match.regs` in `re` documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May 23 13:57:36 2013
From: report at bugs.python.org (Tim Rawlinson)
Date: Thu, 23 May 2013 11:57:36 +0000
Subject: [New-bugs-announce] [issue18044] Email headers do not properly
	decode to unicode.
Message-ID: <1369310256.22.0.862828757307.issue18044@psf.upfronthosting.co.za>


New submission from Tim Rawlinson:

In Python 3.3 decoding of headers to unicode is supposed to be automatic but fails in several cases, including one shown as successful in the documentation:

   >>> msg = message_from_string('Subject: =?utf-8?q?=C3=89ric?=\n\n', policy=default)
   >>> msg['Subject']
   '=?utf-8?q?=C3=89ric?='

   >>> msg = message_from_string('To: =?utf-8?q?=C3=89ric <foo at example.com>\n\n', policy=default)
   >>> msg['To']
   '=?utf-8?q?=C3=89ric?= <foo at example.com>'

Although the following works:

   >>> msg = message_from_string('Subject: =?utf-8?q?Eric?=\n\n', policy=default)
   >>> msg['Subject']
   'Eric'

Though this does not:

   >>> msg = message_from_string('To: =?utf-8?q?Eric?= <foo at example.com>\n\n', policy=default)
   >>> msg['To']
   '=?utf-8?q?Eric?= <foo at example.com>'

And just to prove some things are working as they should:

    >>> msg = message_from_string("Subject: =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\n", policy=default)
    >>> msg['Subject']
    '???????'

----------
assignee: docs at python
components: Documentation, email
messages: 189862
nosy: Tim.Rawlinson, barry, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Email headers do not properly decode to unicode.
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri May 24 02:37:22 2013
From: report at bugs.python.org (Matt Mao)
Date: Fri, 24 May 2013 00:37:22 +0000
Subject: [New-bugs-announce] [issue18045] get_python_version is not import
	in bdist_rpm.py
Message-ID: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za>


New submission from Matt Mao:

Python version : 2.7.5
OS             : CentOS 6.3

When I tried to build a rpm with "python ./setup.py bdist_rpm", I get the following error :

Traceback (most recent call last):
  File "setup.py", line 221, in <module>
    ...  and much more ;)"""
  File "/usr/local/python2.7/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/python2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/python2.7/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/python2.7/lib/python2.7/python2.7/distutils/command/bdist_rpm.py", line 383, in run
    pyversion = get_python_version()
NameError: global name 'get_python_version' is not defined


I find that we do not import function get_python_version in python2.7/distutils/command/bdist_rpm.py.
I think we need to add ?from distutils.sysconfig import get_python_version? in this file.

----------
assignee: eric.araujo
components: Distutils
messages: 189888
nosy: eric.araujo, maoliping455, tarek
priority: normal
severity: normal
status: open
title: get_python_version is not import in bdist_rpm.py
versions: Python 2.7

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

From report at bugs.python.org  Fri May 24 02:54:35 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 24 May 2013 00:54:35 +0000
Subject: [New-bugs-announce] [issue18046] Simplify and clarify logging
	internals
Message-ID: <1369356875.31.0.0932169954685.issue18046@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This patch splits a dictionary that maps integer and string representations of levels to each other out into two dictionaries, one which goes int -> string, and the other which is string -> int. This makes it easier to reason about what a variable contains.

----------
components: Library (Lib)
files: log-simple.diff
keywords: needs review, patch
messages: 189889
nosy: alex
priority: normal
severity: normal
stage: patch review
status: open
title: Simplify and clarify logging internals
versions: Python 3.4
Added file: http://bugs.python.org/file30355/log-simple.diff

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

From report at bugs.python.org  Fri May 24 07:39:43 2013
From: report at bugs.python.org (Arnaud Porterie)
Date: Fri, 24 May 2013 05:39:43 +0000
Subject: [New-bugs-announce] [issue18047] Descriptors get invoked in
	old-style objects and classes
Message-ID: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za>


New submission from Arnaud Porterie:

In the Data Model section of the documentation regarding descriptors invokations (http://docs.python.org/2/reference/datamodel.html#invoking-descriptors), it is said:

    Note that descriptors are only invoked for new style objects or classes (ones that subclass object() or type()).

However, it seems this restriction isn't enforced in practice:

    Python 2.7.4 (default, May 16 2013, 13:28:03)
    [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class Desc(object):
    ...     def __get__(self, obj, cls):
    ...             return 'test'
    ...
    >>> class A:  # Not inheriting object here
    ...     desc = Desc()
    ...
    >>> A().desc
    'test'

I dived into CPython's code and saw no trace of a test for new-style classes in the descriptor invokation code path (down in classobject.c / instance_getattr2).

Unfortunately, fixing this behavior doesn't seem trivial as class methods appear to be implemented as descriptor themselves. In other words, and from my understanding, restricting descriptor invokation to new-style objects and classes would prevent method calls on old-style classes.

----------
components: Interpreter Core
files: desc.py
messages: 189896
nosy: icecrime
priority: normal
severity: normal
status: open
title: Descriptors get invoked in old-style objects and classes
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30356/desc.py

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

From report at bugs.python.org  Fri May 24 11:30:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 May 2013 09:30:12 +0000
Subject: [New-bugs-announce] [issue18048] Merging test_pep263.py and
	test_coding.py
Message-ID: <1369387812.98.0.236232283698.issue18048@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are two test files for the same feature -- defining Python source code encodings (PEP 263). It is not clear where new tests should be added. Perhaps two files should be merged into the one file.

test_pep263.py was added in 2002, test_coding.py was added in 2005.

----------
components: Tests, Unicode
messages: 189902
nosy: ezio.melotti, lemburg, loewis, nnorwitz, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Merging test_pep263.py and test_coding.py
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 24 16:27:46 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 24 May 2013 14:27:46 +0000
Subject: [New-bugs-announce] [issue18049] Re-enable threading test on OSX
Message-ID: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

I recently notied that test.test_threading.ThreadingExceptionTests.test_recursion_limit is disabled for debug builds. 

The attached patch re-enables this test case and fixes the crash be increasing the stack size for new threads. 

The disadvantage of the patch is that is increases the default stack size for all new threads on OSX from 5 to 8 megabytes (for threads created by Python) and that could affect program behavior as fewer threads can be created before running out of memory.

The patch could be updated to check for Py_DEBUG and only increase the stack size for --with-pydebug builds (which are the ones using -O0), as those builds need the increased stack size and debug builds already consume more memory that normal builds. That's not 100% reliable though, as users could also build the with CFLAGS set to -O0 without using --with-pydebug. 

I haven't found a way to detect the optimization level with clang or gcc using the preprocessor.

----------
assignee: ronaldoussoren
components: Macintosh
files: reenable-threading-test.txt
messages: 189912
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Re-enable threading test on OSX
type: behavior
Added file: http://bugs.python.org/file30359/reenable-threading-test.txt

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

From report at bugs.python.org  Fri May 24 19:40:43 2013
From: report at bugs.python.org (Samuel John)
Date: Fri, 24 May 2013 17:40:43 +0000
Subject: [New-bugs-announce] [issue18050] _sre.MAXREPEAT not defined in 2.7.3
Message-ID: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>


New submission from Samuel John:

As also discussed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084 and https://github.com/mxcl/homebrew/pull/19300, Python 2.7.4 and 2.7.5 seem to have added an `from _sre import MAXREPEAT` to the sre_compile.py, sre_parse.py and sre_constants.py modules.

But python 2.7.3 (and older?) don't have the built in MAXREPEAT in _sre. Some virtualenvs have to be updated (which is easy) but some Software (such as vim, shipped with OS X 10.8.3) is statically linked to an older python 2.7.2 (I guess) but somehow picks up my newly built python 2.7.5 and attempts to load it's site.py. (Weechat also reported to being affected)

I think this is more a bug of vim/weechat etc. but we at homebrew have to do some "hacky" fix, because Apple is not going to update vim very soon, and so having a newer python in path breaks system stuff.

So I am fine if you close this here again. But at least we have a reference or perhaps you guys have a better idea how to work-around.

For homebrew, I propose a monkey-patch in re.py to the _sre module if it does not have a MAXREPEAT.


   try:
       from _sre import MAXREPEAT
   except ImportError:
       import _sre
       _sre.MAXREPEAT = 65535 # this monkey-patches all other places of "from _sre import MAXREPEAT"

----------
components: Extension Modules, Regular Expressions
messages: 189924
nosy: ezio.melotti, mrabarnett, samueljohn
priority: normal
severity: normal
status: open
title: _sre.MAXREPEAT not defined in 2.7.3
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri May 24 21:56:52 2013
From: report at bugs.python.org (Craig McDaniel)
Date: Fri, 24 May 2013 19:56:52 +0000
Subject: [New-bugs-announce] [issue18051] get_python_version undefined in
	bdist_rpm.py
Message-ID: <1369425412.53.0.375050257963.issue18051@psf.upfronthosting.co.za>


New submission from Craig McDaniel:

Running "setup.py bdist_rpm" throws an exception on some libraries (e.g. - simplejson) since 2.7.4 due to introduction of get_python_version():

Traceback (most recent call last):
  File "setup.py", line 103, in <module>
    run_setup(True)
  File "setup.py", line 99, in run_setup
    cmdclass={'build_ext': ve_build_ext},
  File "/home/cmcdaniel/src/cpython/Lib/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/home/cmcdaniel/src/cpython/Lib/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/home/cmcdaniel/src/cpython/Lib/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "build/bdist.linux-i686/egg/setuptools/command/bdist_rpm.py", line 28, in run
  File "/home/cmcdaniel/src/cpython/Lib/distutils/command/bdist_rpm.py", line 383, in run
    pyversion = get_python_version()
NameError: global name 'get_python_version' is not defined

----------
assignee: eric.araujo
components: Distutils
files: mywork.patch
keywords: patch
messages: 189926
nosy: Craig.McDaniel, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: get_python_version undefined in bdist_rpm.py
versions: Python 2.7
Added file: http://bugs.python.org/file30361/mywork.patch

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

From report at bugs.python.org  Sat May 25 01:21:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 May 2013 23:21:33 +0000
Subject: [New-bugs-announce] [issue18052] IDLE 3.3.2 Windows taskbar icon
	regression
Message-ID: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Windows 7 (32 bit?), 32 bit IDLE 3.3.2: When I start from the start menu, the taskbar icon is the red Tk icon instead of the IDLE icon. If I try to pin the Tk icon to the task bar, a useless pythonw icon is pinned instead. The Tk icon goes when the program is closed. After multiple open and frequent program deletions, Idle shows up on the Start/frequent programs list with it normal Idle icon (White page + snake).

(I had 3.3.1 before working fine. The 3.3.2 upgrade did not work (tkinter would not import, so I redownloaded, deleted Python 3.3.2, and reinstalled, getting the behavior above.)

I have seen the Tk icon before after fresh installs, but on other machines, and it was replaced after the first open with the correct icon.

----------
components: IDLE, Installation, Windows
messages: 189937
nosy: loewis, roger.serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE 3.3.2 Windows taskbar icon regression
versions: Python 3.3

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

From report at bugs.python.org  Sat May 25 05:46:40 2013
From: report at bugs.python.org (Yogesh Chaudhari)
Date: Sat, 25 May 2013 03:46:40 +0000
Subject: [New-bugs-announce] [issue18053] Add checks for Misc/NEWS in make
	patchcheck
Message-ID: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za>


New submission from Yogesh Chaudhari:

Based on the threads about http://mail.python.org/pipermail/python-committers/2013-May/002529.html and discussion on http://bugs.python.org/issue17953; It would be good to add some (very high level)checks inside patchcheck that will tell the user if Misc/NEWS needs to be updated for the patch created. 

As of now the patchcheck utility adds a notice to modify Misc/NEWS for every patch. IMO this notice should be based on some simple checks.
eg:
number of lines modified and/or directories changed (that might give a clue about ignoring minor changes in documentation and considering changes in Python core or major changes in Libs etc) based on which make patchcheck should generate warnings for changing Misc/NEWS.

----------
messages: 189942
nosy: Yogesh.Chaudhari
priority: normal
severity: normal
status: open
title: Add checks for Misc/NEWS in make patchcheck

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

From report at bugs.python.org  Sat May 25 08:55:59 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 May 2013 06:55:59 +0000
Subject: [New-bugs-announce] [issue18054] Add more exception related
	assertions to unittest
Message-ID: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

When creating the error handling tests for the new ipaddress module, one of the things I added was an "assertCleanError" method on the test cases [1].

This is a wrapper around assertRaisesRegex which ensures that either no exception context is set, or if there is one set, ensures that the display is suppressed by default.

While I don't think assertCleanError itself is suitable for adoption (there are two many use case specific details), I think it *would* be useful to provide two related helper assertions along the lines of the following (the failure message in the first case could likely be improved).

Firstly, ensuring that the context has been *suppressed* when it should have been:

    def assertCleanTraceback(self, exc, msg=None):
        exc_context = exc.__context__
        if exc_context is not None and not exc.__suppress_context__:
            if msg is None:
                fmt = "{} has context set: {}"
                msg = fmt.format(type(exc), type(exc_context))
            self.fail(msg)
        return exc_context

and secondly ensuring that the cause has been *set* when it should have been:

    def assertRaisedFrom(self, exc, expected_cause, expected_regex, msg=None):
        exc_cause = exc.__cause__
        # Use the guts of assertRaises to compare the actual cause
        # and the expected cause and raise an appropriate failure
        # if they don't match
        return exc_cause

Both proposed helpers return the actual context/cause so they can be used to test longer deliberate exception chaings.

[1] http://hg.python.org/cpython/file/04ca3f1515cf/Lib/test/test_ipaddress.py#l37

----------
messages: 189945
nosy: michael.foord, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add more exception related assertions to unittest
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat May 25 17:40:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 May 2013 15:40:14 +0000
Subject: [New-bugs-announce] [issue18055] Stop using imp in IDLE
Message-ID: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As part of issue #14797 I'm trying to remove all uses of imp.find_module/load_module since the API is so bad in the face of importers. See the attached patch to replace the one use in IDLE. It should actually be more accepting of alternative importers than the original code.

Since I'm not an IDLE user I'm not comfortable with committing w/o an IDLE dev signing off on it, so please let me know if I can commit it (I would only bother in 3.4 unless you really want it in the 3.3 branch).

----------
components: IDLE
files: imp_removed_from_idle.diff
keywords: patch
messages: 189968
nosy: brett.cannon
priority: normal
severity: normal
stage: commit review
status: open
title: Stop using imp in IDLE
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file30365/imp_removed_from_idle.diff

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

From report at bugs.python.org  Sat May 25 17:45:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 May 2013 15:45:51 +0000
Subject: [New-bugs-announce] [issue18056] Document
	importlib._bootstrap.NamespaceLoader
Message-ID: <1369496751.81.0.344197180241.issue18056@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Is there a reason NamespaceLoader is undocumented?

----------
assignee: barry
components: Documentation
keywords: 3.3regression
messages: 189969
nosy: barry, brett.cannon, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Document importlib._bootstrap.NamespaceLoader
versions: Python 3.3

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

From report at bugs.python.org  Sat May 25 17:46:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 May 2013 15:46:50 +0000
Subject: [New-bugs-announce] [issue18057] Register NamespaceLoader with
	importlib.abc.Loader
Message-ID: <1369496810.62.0.455394595935.issue18057@psf.upfronthosting.co.za>


New submission from Brett Cannon:

<EOM>

----------
assignee: brett.cannon
components: Library (Lib)
messages: 189970
nosy: barry, brett.cannon, eric.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Register NamespaceLoader with importlib.abc.Loader
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 25 17:48:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 May 2013 15:48:43 +0000
Subject: [New-bugs-announce] [issue18058] Define is_package for
	NamespaceLoader
Message-ID: <1369496923.18.0.904476367209.issue18058@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Is there a reason that is_package() is not defined for NamespaceLoader? If it's just an oversight then adding it would let -m would work with namespace packages. The other abstract methods on InspectLoader can also be implemented or raise ImportError as appropriate.

Just assign to me if you are okay with seeing this happen.

----------
assignee: barry
components: Library (Lib)
messages: 189972
nosy: barry, brett.cannon, eric.smith
priority: normal
severity: normal
stage: test needed
status: open
title: Define is_package for NamespaceLoader
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 25 20:41:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 May 2013 18:41:28 +0000
Subject: [New-bugs-announce] [issue18059] Add multibyte encoding support to
	pyexpat
Message-ID: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It is possible to add the support of most multibyte encodings to pyexpat.

There are several ways to do this:

1. Generate maps with a special script and add generated file to repository. After adding or updating a multibyte encoding this file should be regenerated.

2. Generate maps on fly. It requires more time for first use of the encoding, but allows support of arbitrary encoding which compatible with expat.

----------
components: Extension Modules, XML
files: expat_encodings.py
messages: 189989
nosy: doerwalter, eli.bendersky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add multibyte encoding support to pyexpat
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30368/expat_encodings.py

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

From report at bugs.python.org  Sat May 25 21:07:26 2013
From: report at bugs.python.org (Lauri Alanko)
Date: Sat, 25 May 2013 19:07:26 +0000
Subject: [New-bugs-announce] [issue18060] Updating _fields_ of a derived
	struct type yields a bad	cif
Message-ID: <1369508846.31.0.680698237225.issue18060@psf.upfronthosting.co.za>


New submission from Lauri Alanko:

In Modules/_ctypes/stgdict.c:567 there is a suspicious line:

    stgdict->length = len;      /* ADD ffi_ofs? */

That is, the length field of the stgdict is set to the number of fields in the immediate Structure class, and the number of fields in the parent class (ffi_ofs) is questionably left out. This is wrong.

The length field is used in PyCStgDict_clone to copy the ffi_type descriptors for struct elements to a derived struct type. If length is short, not all element types are copied, and the resulting array is not NULL-terminated.

So the problem manifests when you inherit from a structure type, update the _fields_ of the inherited type, and then inherit again from the updated type. Even then everything might seem normal, since the elements array is actually not used very much.

However, attached is a test case that segfaults at least with debug builds on ARM with the VFP ABI. The non-null-terminated element type array is traversed to find if the structure can be passed in floating point registers, eventually resulting in dereferencing 0xfbfbfbfb.

The test program should print out pi. To avoid the hassle of a separate C component, the program abuses the standard atan2 function by pretending it takes a struct of two doubles instead of two separate double parameters. This does not make a difference to the ABI.

Fixing the bug is trivial. Just change the line to:

 stgdict->length = ffi_ofs + len;

----------
components: ctypes
files: t1.py
messages: 189992
nosy: lauri.alanko
priority: normal
severity: normal
status: open
title: Updating _fields_ of a derived struct type yields a bad cif
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file30369/t1.py

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

From report at bugs.python.org  Sat May 25 22:55:04 2013
From: report at bugs.python.org (mirabilos)
Date: Sat, 25 May 2013 20:55:04 +0000
Subject: [New-bugs-announce] [issue18061] m68k Python 3.3 test results
Message-ID: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za>


New submission from mirabilos:

Hi!

As a followup to http://bugs.python.org/issue17237 I took the tree of Python 3.3.1 I had compiled already, with the patch that was eventually committed for issue17237, and ran the testsuite. Since I used configure flags to get it compiled quickly, it probably lacks functionality that?s normally there, so some tests got omitted.

The result of normally running the testsuite is attached as file; I can re-run any test verbosely, just ask ;-)

I can immediately say something to some failures:

? On m68k, the 68881 FPU, similar to the i8087 FPU, internally operates on 80-bit precision, which means that the ?old? dtoa code is used. Contrarily to i8087, we do not want to disable that mode because that is not fully supported in some environments; especially, at least the most wide-spread emulator had bugs wrt. that. (Do note that, when you disable 80-bit precision on i8087, you get double-rounding as the only the mantisse, not the exponent, is bit-reduced, anyway. So I believe that you should not restrict the i8087 to 64-bit precision either.)

That?s responsible for test_optparse, test_difflib, maybe test_cmath, definitely test_format, test_types, test_math? ouch, quite some.

It would be interesting to see what happens when you take a normal i386 (not amd64 or x32) Linux host and compile py3k with SSE disabled (to force it to use the normal i80387 FPU), and disable HAVE_GCC_ASM_FOR_X87 so that X87_DOUBLE_ROUNDING is defined, because that?s what we have on m68k, and see whether the failure mode is the same. If so, you can then probably relatively easily fix those.

root at ara3:~/P-without-block # fgrep X87 pyconfig.h                                                              
/* #undef HAVE_GCC_ASM_FOR_X87 */
#define X87_DOUBLE_ROUNDING 1

? This one is pretty severe: AssertionError: 42 != 44 : wrong size for <class 'BaseException'>: got 42, expected 44

On m68k, ?natural? alignment is *not* used: instead of aligning 4-byte quantities on 4-byte boundaries, for almost all types, only a minimum alignment of 2 bytes is used; this also has effect on struct padding, array padding, and things like that.

As shown in https://mail.gnome.org/archives/commits-list/2012-February/msg02332.html fixing this is a ?simple? matter of making these invalid assumptions explicit. To that effect, take Include/pyerrors.h and change
#define PyException_HEAD PyObject_HEAD PyObject *dict;\
             PyObject *args; PyObject *traceback;\
             PyObject *context; PyObject *cause;\
             char suppress_context;
to
#define PyException_HEAD PyObject_HEAD PyObject *dict;\
             PyObject *args; PyObject *traceback;\
             PyObject *context; PyObject *cause;\
             char suppress_context; char padding1[3];
i.e. add the padding that?s implicit on ?natural alignment? platforms (a padding1[1] is implicit on m68k). Do *not* use -malign-int because that changes the ABI, and you probably won?t be able to make libc or syscalls any more?

However, this brings us to a problem with that solution (which I?d still prefer over everything else) in Debian (hence, putting doko on Cc), which I?ll demonstrate on the shortest struct I could find in that file, but applies to e.g. PyImportErrorObject too:

typedef struct {
    PyException_HEAD 
    PyObject *code;  
} PySystemExitObject;

The ?code? member of this struct is aligned with only *one* byte of padding, instead of three. This means that, when we apply this bugfix, that the published ABI changes: currently, sizeof(PySystemExitObject) is (8 (PyObject_HEAD) + 4 (dict) + 4 (args) + 4 (traceback) + 4 (context) + 4 (cause) + 1 (suppress_context) + 1 padding + 4 (code)) = 34; after the fact, it will be 36, and the offsetof(code) will have changed.

I?ll leave the understanding of these implications, and how they can best be handled in the distribution, to doko, because he?s probably the man who understands it best. I guess we need versioned dependencies or ABI virtual dependencies, since python3.3 is already uploaded, but some packages have already been built against it (probably not too difficult to identify them).

Or we can only get this fixed in python3.4 ? no idea when that will land in Debian, or whether it?ll become the default python3 provider shortly.

? As for any other failures, I don?t directly have an idea, but I guess we can work on them. I?d somewhat prefer to do that *after* the FPU precision-related bugs have been fixed, though, as it?ll reduce the noise, and possibly followup-errors. (Maybe I should even, for running the tests, fix the alignment issue locally in the tree.)

----------
components: Interpreter Core
files: results.txt
messages: 189997
nosy: doko, mirabilos, pitrou, skrah
priority: normal
severity: normal
status: open
title: m68k Python 3.3 test results
versions: Python 3.3
Added file: http://bugs.python.org/file30371/results.txt

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

From report at bugs.python.org  Sat May 25 23:00:51 2013
From: report at bugs.python.org (mirabilos)
Date: Sat, 25 May 2013 21:00:51 +0000
Subject: [New-bugs-announce] [issue18062] m68k FPU precision issue
Message-ID: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za>


New submission from mirabilos:

Hi,

splitting off issue18061 by request of pitrou:

FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it?s not supported in all environments. Can probably be reproduced on i386 (with disabled SSE); fixing this in general would allow keeping the FPUCW on i387 unchanged too.

See issue18061 for details.

----------
components: Interpreter Core
messages: 189999
nosy: mirabilos
priority: normal
severity: normal
status: open
title: m68k FPU precision issue
versions: Python 3.3

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

From report at bugs.python.org  Sat May 25 23:01:55 2013
From: report at bugs.python.org (mirabilos)
Date: Sat, 25 May 2013 21:01:55 +0000
Subject: [New-bugs-announce] [issue18063] m68k struct alignment issue vs.
	PyException_HEAD
Message-ID: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za>


New submission from mirabilos:

Hi,

splitting off issue18061 by request of pitrou:

struct alignment issue: PyException_HEAD misses explicit alignment instruction; uses invalid (non-portable) alignment assumptions. ABI change on m68k.

See issue18061 for details.

----------
components: Interpreter Core
messages: 190000
nosy: mirabilos
priority: normal
severity: normal
status: open
title: m68k struct alignment issue vs. PyException_HEAD
versions: Python 3.3

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

From report at bugs.python.org  Sat May 25 23:36:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 May 2013 21:36:20 +0000
Subject: [New-bugs-announce] [issue18064] IDLE: add current directory to
	open_module
Message-ID: <1369517780.56.0.941397989466.issue18064@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The point of File / Open Module is to look at the source for a module that has been, could be, or will be imported. The problem is that open_module is executed in the idle process while imports are executed in the user process, with the current directory prepended to sys.module.
The problem was already noted in the source, line 675.
 # XXX Ought to insert current file's directory in front of path

The augmentation of sys.path and subsequent restoration of the original could be done in a context manager that might be useful elsewhere. For 3.3,3.4, I think the change should be done after the patch in #18055, to not invalidate that patch. It would need to located in a slightly different place in 2.7, which will not be changed by that issue.

----------
messages: 190012
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: add current directory to open_module
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 26 01:21:02 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 25 May 2013 23:21:02 +0000
Subject: [New-bugs-announce] [issue18065] set __path__ = [] for frozen
	packages
Message-ID: <1369524062.03.0.920595154239.issue18065@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you import the frozen __phello__ package, you will notice that __phello__.__path__ == ['__phello__']. While that seems innocuous, that could potentially lead to incorrect results if there just so happens to be a directory named __phello__ which contains a file that isn't a frozen submodule (i.e. FrozenImporter can't find the submodule but PathFinder can find a file that happens to match the module's name).

So for that reason I want to simply set __path__ = [] for frozen packages. The language reference for import states setting __path__ to anything makes a module a package and that it just needs to be an iterable that only returns strings (http://docs.python.org/3.4/reference/import.html#packages), so an empty list works. Plus __package__ contains the same information so there is no lost data by doing this.

Can anyone think of a good reason not to do this? I can't see why someone would be relying upon this for any reason since the existence of __path__ itself is enough to determine something is a package.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 190034
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: set __path__ = [] for frozen packages
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun May 26 14:32:17 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 26 May 2013 12:32:17 +0000
Subject: [New-bugs-announce] [issue18066] Remove SGI-specific code from
	pty.py
Message-ID: <1369571537.69.0.0137495343006.issue18066@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

pty.py contains some code that tries to do 'import sgi' and then does something SGI-specific.  sgimodule.c was dropped in 3.0alpha1, so this code is now useless.

The attached patch removes it; I'm posting the code review largely in case someone wants to suggest changes to the docstring.

----------
files: remove-sgi.txt
messages: 190083
nosy: akuchling
priority: normal
severity: normal
stage: patch review
status: open
title: Remove SGI-specific code from pty.py
type: resource usage
Added file: http://bugs.python.org/file30383/remove-sgi.txt

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

From report at bugs.python.org  Sun May 26 18:29:11 2013
From: report at bugs.python.org (Shriramana Sharma)
Date: Sun, 26 May 2013 16:29:11 +0000
Subject: [New-bugs-announce] [issue18067] In considering the current
	directory for importing	modules,
	Python does not honour the output of os.getcwd()
Message-ID: <1369585751.87.0.707349991887.issue18067@psf.upfronthosting.co.za>


New submission from Shriramana Sharma:

Hello. I first asked about this at https://groups.google.com/d/topic/comp.lang.python/ZOGwXGU_TV0/discussion and am only posting this issue due to no reply there.

I am using Python 2.7.4 and Python 3.3.1 (default packages) on Kubuntu Raring. On both I experience this same bug.

This bug has to do with a Python script called via a symlink. To illustrate it I have included a minimal test case tarball as an attachment. Just run sh test.sh at root of the extracted tree to see what's happening.

I am quite unpleasantly surprised that when one calls a Python script via a symlink, and that script asks for a module to be imported, Python searches the directory in which the *target* of the link exists, and uses the version of the library present *there* if any, and raises an exception if not. It even follows a chain of symlinks. Any version of the library present in the same directory as the (user-called) symlink is ignored. This is totally counter-intuitive behaviour and should be treated as a bug and fixed.

This is all the more frustrating since running print(os.getcwd()) from the same script correctly prints the current directory in which the *symlink* and not its target exists. (See output of the attached scripts.)

Now the symlink is only a user-level file system convenience indicating that I create a virtual file in one place pointing to another file elsewhere. Whatever the rest of the contents of the directory containing the other file is immaterial to me -- I am only interested in the one file I am symlinking to. 

I am executing a script from a given directory. os.getcwd() correctly prints the path of that directory. I also have a library in that same directory for the script to import. I would expect Python to honour the output of os.getcwd() in doing import too.

I read through http://docs.python.org/3/reference/import.html and didn't seem to find any explanation for the current illogical behaviour. (Please point out if I have missed it.)

(Note that the same behaviour does not happen with hardlinks, probably since the filesystem itself shows the whole file as existing at the current location.)

Output of the test.sh script:

**** Trying english/run.py ****
CWD: /tmp/symlink-bug/english
Hello Shriramana!
**** Trying english/run-link.py symlinked to ./run.py ****
CWD: /tmp/symlink-bug/english
Traceback (most recent call last):
  File "run-link.py", line 3, in <module>
    from greet import greet
ImportError: No module named greet
**** Trying english/run-link-link.py symlinked to ./run-link.py symlinked to english/run.py ****
CWD: /tmp/symlink-bug/english
Hello Shriramana!
**** Trying sanskrit/run-slink.py symlinked to english/run.py ****
CWD: /tmp/symlink-bug/sanskrit
Hello Shriramana!
**** Trying sanskrit/run-hlink.py hardlinked to english/run.py ****
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!

Expected output: (see esp items marked 1 and 2 below):

**** Trying english/run.py ****
CWD: /tmp/symlink-bug/english
Hello Shriramana!
1 **** Trying english/run-link.py symlinked to ./run.py ****
CWD: /tmp/symlink-bug/english
Hello Shriramana!
**** Trying english/run-link-link.py symlinked to ./run-link.py symlinked to english/run.py ****
CWD: /tmp/symlink-bug/english
Hello Shriramana!
2 **** Trying sanskrit/run-slink.py symlinked to english/run.py ****
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!
**** Trying sanskrit/run-hlink.py hardlinked to english/run.py ****
CWD: /tmp/symlink-bug/sanskrit
Namaste Shriramana!

----------
components: Extension Modules
files: symlink-bug.tar.gz
messages: 190098
nosy: jamadagni
priority: normal
severity: normal
status: open
title: In considering the current directory for importing modules, Python does not honour the output of os.getcwd()
Added file: http://bugs.python.org/file30386/symlink-bug.tar.gz

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

From report at bugs.python.org  Sun May 26 20:59:09 2013
From: report at bugs.python.org (Oleg Broytman)
Date: Sun, 26 May 2013 18:59:09 +0000
Subject: [New-bugs-announce] [issue18068] pickle + weakref.proxy(self)
Message-ID: <1369594749.9.0.0448045246945.issue18068@psf.upfronthosting.co.za>


New submission from Oleg Broytman:

Hello! I've found a problematic behaviour of pickle when it pickles
(direct or indirect) weak proxies to self. I suspect pickle cannot
detect reference loops with weak proxies. I managed to narrow the case
to the following example:

import pickle, weakref

class TestPickle(object):
    def __init__(self):
        self.recursive = weakref.proxy(self)

    def __getstate__(self):
        print "__getstate__", id(self)
        return self.__dict__.copy()

    def __setstate__(self, d):
        print "__setstate__", id(self)
        self.__dict__.update(d)

print "- 1 -"
test = TestPickle()
print "- 2 -"
data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL)
print "- 3 -"
test2 = pickle.loads(data)
print "- 4 -"
print "Result:", id(test2)
print "- 5 -"

   It prints:

- 1 -
- 2 -
__getstate__ 3075348620
__getstate__ 3075348620
- 3 -
__setstate__ 3075348844
__setstate__ 3075349004
- 4 -
Result: 3075349004
- 5 -

   That is, __getstate__ is called twice for the same object. And what
is worse, __setstate__ is called twice for different objects. The
resulting unpickled object is the last one, but in the library that I
have been debugging creation of two different objects during unpickling
is a bug.

   I can fix it by avoiding pickling the proxy and recreating the proxy
on unpickling:

import pickle, weakref

class TestPickle(object):
    def __init__(self):
        self.recursive = weakref.proxy(self)

    def __getstate__(self):
        print "__getstate__", id(self)
        d = self.__dict__.copy()
        del d['recursive']
        return d

    def __setstate__(self, d):
        print "__setstate__", id(self)
        self.__dict__.update(d)
        self.recursive = weakref.proxy(self)

print "- 1 -"
test = TestPickle()
print "- 2 -"
data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL)
print "- 3 -"
test2 = pickle.loads(data)
print "- 4 -"
print "Result:", id(test2)
print "- 5 -"

- 1 -
- 2 -
__getstate__ 3075070092
- 3 -
__setstate__ 3075070188
- 4 -
Result: 3075070188
- 5 -

   But I wonder if it's a bug that should be fixed? If it's an expected
behaviour it perhaps should be documented as a warning in docs for
pickle or weakref or both.

----------
components: Library (Lib)
messages: 190105
nosy: phd
priority: normal
severity: normal
status: open
title: pickle + weakref.proxy(self)
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun May 26 21:15:42 2013
From: report at bugs.python.org (berdario)
Date: Sun, 26 May 2013 19:15:42 +0000
Subject: [New-bugs-announce] [issue18069] Subprocess picks the wrong
	executable on Windows
Message-ID: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za>


New submission from berdario:

To reproduce:
I installed 2 versions of python: python2.7 and python3.3, both in C:\
I then used the distribute-setup and get-pip script on both interpreters
http://python-distribute.org/distribute_setup.py
https://raw.github.com/pypa/pip/master/contrib/get-pip.py

I copied C:\Python33\Scripts\pip.exe to C:\Python33\pip.exe

And I set up the PATH system variable, to have C:\Python27\Scripts;C:\Python33\; at the beginning

When invoking python, it'll pick Python3.3, as expected, and then:

> python
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from shutil import which
>>> import os
>>> os.environ['PATH']
'C:\\Python27\\Scripts;C:\\Python33\\;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files\\Microsoft Windows Performance Toolkit\\;C:\\Program Files (x86)\\Bazaar;C:\\Program Files\\Mercurial\\;C:\\MinGW\\bin; C:\\Program Files (x86)\\Git\\cmd;C:\\Users\\Dario\\Documents\\WindowsPowerShell\\Modules\\Pscx\\Apps;C:\\Users\\Dario\\Applications\\bin;C:\\Users\\Dario\\Applications\\emacs\\bin'
>>> which('pip')
'c:\\python27\\scripts\\pip.exe'
>>> from subprocess import call
>>> call('pip --version'.split())
Cannot open C:\Python33\pip-script.py
2
>>>

----------
components: Interpreter Core, Windows
messages: 190106
nosy: berdario
priority: normal
severity: normal
status: open
title: Subprocess picks the wrong executable on Windows
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 27 15:59:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 May 2013 13:59:43 +0000
Subject: [New-bugs-announce] [issue18070] change
	importlib.util.module_for_loader to	unconditionally set attributes
Message-ID: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za>


New submission from Brett Cannon:

importlib.util.module_for_loader (as well as set_package and set_loader) only set those attributes either when they are not already set or when the module is new. I realized this is a problem as it means a reload won't work the way one might expect.

I want to at least change module_for_loader since I suspect that is in wider use, but probably all three decorators to unconditionally set their respective attributes so reloads operate as expected. Unfortunately that is backwards-incompatible, albeit for probably a rare case if anyone actually cares.

Anyone see a reason why doing this is a bad idea and it shouldn't be done?

----------
components: Library (Lib)
messages: 190139
nosy: barry, brett.cannon, eric.smith, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: change importlib.util.module_for_loader to unconditionally set attributes
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May 27 16:07:21 2013
From: report at bugs.python.org (Samuel John)
Date: Mon, 27 May 2013 14:07:21 +0000
Subject: [New-bugs-announce] [issue18071] _osx_support compiler_fixup
Message-ID: <1369663641.63.0.31152522756.issue18071@psf.upfronthosting.co.za>


New submission from Samuel John:

In the `_osx_support.py` module, there seems to be a bug in the method `compiler_fixup` which occurs if 

* the `customize_compiler` method from `distutils/sysconfig` has been called and after that
* `_compile` from `distutils/unixcompiler.py` is called. The `_compile` method uses `_osx_support.compiler_fixup`.

The critical line in compiler_fixup is:

`compiler_so = list(compiler_so)`.

Usually `compiler_so` is a list like `['cc']` but not when `customize_compiler` (from sysconfig) has been called. The value returned by `sysconfig.get_config_var('LDSHARED')` is a unicode like for example in the case of a Python 2.7.5 built via Homebrew: 
  
    "cc -bundle -undefined dynamic_lookup -L/homebrew/lib -L/homebrew/opt/sqlite/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk".
When `list()` is applied to the value, it is split at each character and that cannot be intended.

I am not sure if I fully understand, but to fix this in `compiler_fixup`, instead of `compiler_so = list(compiler_so)`, I'd propose something along the lines of:

    if isinstance(compiler_so, (str,unicode)):
        compiler_so = compiler_so.split()

I found this by trying to `pip install cython` (it uses customize_compiler, I guess) on a homebrewed python.

To reproduce in an interactive shell we can emulate what is going on by calling `compiler_fixup` directly with the values sysconfig has stored. The exact string does not matter, because I think the any value returned by `sysconfig_get_config_var` is a (unicode) string and not a list:

    import sysconfig
    import _osx_support
    _osx_support.compiler_fixup(sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('CFLAGS'))


Not sure if other python versions are affected. I wasn't aware of `_osx_support` at all until now.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 190140
nosy: hynek, ned.deily, ronaldoussoren, samueljohn
priority: normal
severity: normal
status: open
title: _osx_support compiler_fixup
versions: Python 2.7

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

From report at bugs.python.org  Mon May 27 17:03:42 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 May 2013 15:03:42 +0000
Subject: [New-bugs-announce] [issue18072] Add an implementation
	of	importlib.abc.InspectLoader.get_code
Message-ID: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm contemplating adding an implementation of importlib.abc.InspectLoader.get_code() which relies on get_source() (and then another version in ExecutionLoader which uses get_filename()). The reason I'm hesitant is get_source() is often an expensive operation thanks to having to decode the source code and do a universal newline conversion.

Now I could add the implementation but leave the method abstract, forcing users to make the decision to call super().get_code(), although that's still easy enough that I'm afraid people still won't take into consideration the performance implications.

But maybe I'm worrying too much? We're consenting adults, right? So for that reason I'm leaning towards implementing but leaving abstract with a note in the docs that performance should be considered before just blindly calling the abstract method.

----------
components: Library (Lib)
messages: 190143
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Add an implementation of importlib.abc.InspectLoader.get_code
versions: Python 3.4

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

From report at bugs.python.org  Mon May 27 20:04:41 2013
From: report at bugs.python.org (Julien Muchembled)
Date: Mon, 27 May 2013 18:04:41 +0000
Subject: [New-bugs-announce] [issue18073] pickle.Unpickler may read too many
	bytes, causing hangs with blocking input stream
Message-ID: <1369677881.19.0.98233808248.issue18073@psf.upfronthosting.co.za>


New submission from Julien Muchembled:

I use pickle over sockets to make 2 processes communicate and I experience hangs when the resulting pickle message is exactly 4097 bytes.

Attached file is a small script reproducing the issue, trying a few values around 4096. It runs on both Python 2.7 & 3.3:

- Python 2.7.3: ok (script exits)
- Python 3.3.2: last iteration hangs

With strace, you can easily see that after reading the 4097 bytes:

[pid 17100] read(3,  <unfinished ...>
[pid 17100] <... read resumed> "\200\2X\367\17\0\0                         "..., 4096) = 4096
[pid 17100] read(3, ".", 4096)          = 1

it reads again without reason:

[pid 17100] read(3, 

No issue with the Python implementation, that you can try with little change:

- Python 2.7.3: ok   (from pickle import Unpickler)
- Python 3.3.2: ok   (from pickle import _Unpickler as Unpickler)

----------
components: Extension Modules
files: test_case.py
messages: 190149
nosy: jm
priority: normal
severity: normal
status: open
title: pickle.Unpickler may read too many bytes, causing hangs with blocking input stream
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30388/test_case.py

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

From report at bugs.python.org  Tue May 28 00:25:16 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 27 May 2013 22:25:16 +0000
Subject: [New-bugs-announce] [issue18074] argparse: Namespace can contain
	critical characters
Message-ID: <1369693516.49.0.861390993855.issue18074@psf.upfronthosting.co.za>


New submission from Sworddragon:

Positional arguments which have no dest attribute doesn't replace any - with _. In the attachments is an example script which demonstrate this. The output looks like this:

sworddragon at ubuntu:~$ ./args.py foo
Namespace(foo-bar2='foo', foo_bar1=None)

----------
components: Library (Lib)
files: args.py
messages: 190157
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: argparse: Namespace can contain critical characters
versions: Python 3.3
Added file: http://bugs.python.org/file30393/args.py

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

From report at bugs.python.org  Tue May 28 03:02:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 May 2013 01:02:08 +0000
Subject: [New-bugs-announce] [issue18075] Infinite recursion tests
	triggering a segfault
Message-ID: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you run any test that has infinite recursion (test_json test_exceptions test_sys test_runpy) it will segfault with a fresh checkout under OS X 10.8.3 using Clang. Not sure how widespread this is.

I did check that I am using a clean checkout of the default branch.

----------
components: Interpreter Core
messages: 190162
nosy: brett.cannon, larry
priority: release blocker
severity: normal
status: open
title: Infinite recursion tests triggering a segfault
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue May 28 03:24:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 May 2013 01:24:09 +0000
Subject: [New-bugs-announce] [issue18076] Implement
	importlib.util.decode_source_bytes()
Message-ID: <1369704249.95.0.785002868519.issue18076@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Right now importlib.abc.SourceLoader implements get_source(), but most of it is decoding bytes properly. That should probably be abstracted out to importlib.util so that it's available even for loaders which don't provide get_data() or get_filename().

----------
assignee: brett.cannon
components: Library (Lib)
messages: 190164
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Implement importlib.util.decode_source_bytes()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue May 28 04:08:54 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Tue, 28 May 2013 02:08:54 +0000
Subject: [New-bugs-announce] [issue18077] dis.dis throws IndexError
Message-ID: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

>>> dis.dis('pass')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dis.py", line 45, in dis
    disassemble_string(x)
  File "/usr/lib/python2.7/dis.py", line 112, in disassemble_string
    labels = findlabels(code)
  File "/usr/lib/python2.7/dis.py", line 166, in findlabels
    oparg = ord(code[i]) + ord(code[i+1])*256
IndexError: string index out of range

it happens for any string.

----------
components: Library (Lib)
messages: 190169
nosy: elazar
priority: normal
severity: normal
status: open
title: dis.dis throws IndexError
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue May 28 05:40:19 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Tue, 28 May 2013 03:40:19 +0000
Subject: [New-bugs-announce] [issue18078] threading.Condition to allow
	notify on a specific waiter
Message-ID: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo:

If users could provide an inner lock for `threading.Condition` acquire when making a thread wait, it would allow for notifying a specific waiter.

Because of race conditions, using:

    cond.notify(1)

may not wake the thread I want. Also, I may not want to wake the first waiter at all.

So my proposal is something along the lines:



class Condition:
    ...

    def wait(self, timeout=None, lock=None):
        ...
        waiter = _allocate_lock() if lock is None else lock
        ...

    def notify_one(self, lock): 
        # Maybe could notify a list of locks?

        try:
            self._waiters.remove(lock)
        except ValueError:
            pass 
            # Maybe RuntimeError("Lock not waiting in this Condition")
        else:
            lock.release()

----------
components: Library (Lib)
messages: 190173
nosy: JBernardo
priority: normal
severity: normal
status: open
title: threading.Condition to allow notify on a specific waiter
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue May 28 09:26:22 2013
From: report at bugs.python.org (arbour)
Date: Tue, 28 May 2013 07:26:22 +0000
Subject: [New-bugs-announce] [issue18079] documentation tutorial 3.1.3 typo
Message-ID: <1369725982.22.0.36331305671.issue18079@psf.upfronthosting.co.za>


New submission from arbour:

documentation tutorial 3.1.3 typo

at page 15 (21/127)

>>> p[0]
['a','b','c']
>>> p[0][1]
'b'

should be:

>>> x[0]
['a','b','c']
>>> x[0][1]
'b'

----------
assignee: docs at python
components: Documentation
files: tutorial.pdf
messages: 190178
nosy: arbour, docs at python
priority: normal
severity: normal
status: open
title: documentation tutorial 3.1.3 typo
versions: Python 3.3
Added file: http://bugs.python.org/file30394/tutorial.pdf

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

From report at bugs.python.org  Tue May 28 11:27:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 28 May 2013 09:27:55 +0000
Subject: [New-bugs-announce] [issue18080] setting CC no longer overrides
	default linker for	extension module builds on OS X
Message-ID: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za>


New submission from Ned Deily:

As part of the initial changes for Issue13590 in 2.7.3, 3.2.3, and 3.3 (prior to release) to Distutils to support building extension modules on OS X with Xcode 4, code was added to substitute the clang compiler if the older gcc-4.2 supplied with Xcode 3 was not found.  In addition, the changes made it easier for the user to override the compiler for both the compile and linking stages: "Also as a convenience, if the user does explicitly set CC, substitute its value as the default compiler in the Distutils LDSHARED configuration variable for OS X."  This eliminated the need to construct a complete LDSHARED value.  For 2.7.4, 3.2.4, and 3.3.0, more extensive changes were made to fully support the latest releases of Xcode 4.  Unfortunately, the code to override LDSHARED if CC is set was inadvertently deleted for these later releases.  The attached patch restores the deleted override behavior and adds tests.

----------
assignee: ned.deily
components: Distutils, Macintosh
messages: 190182
nosy: ned.deily, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: setting CC no longer overrides default linker for extension module builds on OS X
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue May 28 17:25:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 28 May 2013 15:25:27 +0000
Subject: [New-bugs-announce] [issue18081] test_logging failure in
	WarningsTest on buildbots
Message-ID: <1369754727.16.0.996234462502.issue18081@psf.upfronthosting.co.za>


New submission from R. David Murray:

The following failure is showing up frequently in the buildbots.  I haven't checked closely enough to be sure if it is a heisenberg, but I suspect it is, since it doesn't seem to be related to any of the recent changesets that would have been included in the builds that just failed and that show the failure:

======================================================================
FAIL: test_warnings (test.test_logging.WarningsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.3.bolen-freebsd/build/Lib/test/test_logging.py", line 1796, in test_warnings
    "dummy.py:42: UserWarning: Explicit\n  Dummy line\n")
AssertionError: '\nWarning (from warnings module):\n  File "dummy.py", line 42\n    Dummy line\n [truncated]... != 'dummy.py:42: UserWarning: Explicit\n  Dummy line\n'
+ dummy.py:42: UserWarning: Explicit
- 
- Warning (from warnings module):
-   File "dummy.py", line 42
-     Dummy line
? --
+   Dummy line
- UserWarning: Explicit
- >>>

----------
components: Tests
keywords: buildbot
messages: 190220
nosy: r.david.murray, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failure in WarningsTest on buildbots
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue May 28 18:31:28 2013
From: report at bugs.python.org (Dwight Guth)
Date: Tue, 28 May 2013 16:31:28 +0000
Subject: [New-bugs-announce] [issue18082] Inconsistent behavior of IOBase
	methods on closed files
Message-ID: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za>


New submission from Dwight Guth:

Consider the following program:

import io 
class A(io.IOBase): 
  def __init__(self): 
    self.x = 5 
  def read(self, limit=-1): 
    self.x -= 1 
    if self.x > 0: 
      return b"5" 
    return b"" 
  def seek(self, offset, whence=0): 
    return 0 
  def write(self, b): 
    pass 
 
a = A() 
a.close() 
assert a.__next__() == b"5555" 
assert a.readline() == b"" 
assert a.tell() == 0

These three operations succeed, even though the file is closed. However, these two operations fail:

a.readlines()
a.writelines([])

Why do some of the mixin methods on IOBase call _checkClosed and others don't?

----------
components: IO
messages: 190224
nosy: dwight.guth
priority: normal
severity: normal
status: open
title: Inconsistent behavior of IOBase methods on closed files
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue May 28 18:34:53 2013
From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=)
Date: Tue, 28 May 2013 16:34:53 +0000
Subject: [New-bugs-announce] [issue18083] _sysconfigdata.py is installed in
	an arch-independent	directory
Message-ID: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za>


New submission from Maciej Blizi?ski:

_sysconfigdata.py is installed into ${prefix}/lib/pythonX.Y/_sysconfigdata.py which is an architecture-independent directory, as opposed to a path starting with e.g. ${libdir}, which is architecture-dependent. But _sysconfigdata.py contains architecture-dependent information, which breaks some installation, specifically Solaris multi-arch.

A fix would be to move it to an architecture-dependent directory, but this probably requires some discussion.

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

Original question on the mailing list:
http://mail.python.org/pipermail/python-list/2013-May/647197.html

I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package
for Solaris. The specificity of that package is that I need to include
both 32-bit and 64-bit binaries in it. The exact way in which the
32/64 support is done is described at [1].

There currently is a Python package that I maintain, which is 32-bit only[2].

I have made an attempt to build a 64-bit package, and my findings are
that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains
system-specific information. Note that it's not ${libdir}/pythonX.Y -
that would have worked, because I'm specifying different ${libdir}
directories when running the 32-bit and 64-bit builds. The Python
installer specifically uses ${prefix}/lib/pythonX.Y. For the most part
is fine, because most of files in there are not architecture-specific,
and it would be quite good to share them among the 32-bit and 64-bit
binaries at runtime. The problem is that some files differ. I've
described it some more at [3].

Ideally, I'd make _sysconfigdata.py return/set different values
depending on the Python runtime that reads it. Something like:

if we're 64-bit:
  set values for the 64-bit platform
else:
  set values for the 32-bit platform

It's a similar approach to how we currently handle C header files. See
the 'Development packages' section in [1] for more information.

The problem is that it would involve somewhat intrusive patching of
the Python source code, and in long term that means maintainability
issues.

----------
components: Installation
messages: 190225
nosy: automatthias
priority: normal
severity: normal
status: open
title: _sysconfigdata.py is installed in an arch-independent directory
versions: Python 3.3

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

From report at bugs.python.org  Tue May 28 21:16:19 2013
From: report at bugs.python.org (Hideaki Takahashi)
Date: Tue, 28 May 2013 19:16:19 +0000
Subject: [New-bugs-announce] [issue18084] wave.py should use sys.byteorder
	to determine endianess
Message-ID: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za>


New submission from Hideaki Takahashi:

wave.py uses struct based endianness detecting code.
However there is sys.byteorder in Python since Python 2.0.

I think wave.py should use sys.byteorder to determine endianness.

----------
components: Library (Lib)
messages: 190235
nosy: hideaki_t
priority: normal
severity: normal
status: open
title: wave.py should use sys.byteorder to determine endianess

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

From report at bugs.python.org  Tue May 28 21:22:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 May 2013 19:22:38 +0000
Subject: [New-bugs-announce] [issue18085] Verifying refcounts.dat
Message-ID: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

I found one error in Doc/data/refcounts.dat (see issue9369, second argument of PyObject_CallMethodObjArgs is `PyObject*`, not `char*`). Perhaps there are other errors. How this file was generated first? Is it possible to write a tool which will automatically verify at least signatures of functions?

----------
assignee: docs at python
components: Documentation
messages: 190236
nosy: docs at python, serhiy.storchaka, skip.montanaro
priority: normal
severity: normal
status: open
title: Verifying refcounts.dat
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May 29 00:46:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 May 2013 22:46:43 +0000
Subject: [New-bugs-announce] [issue18086] Create
	importlib.util.set_attrs_post_import()
Message-ID: <1369781203.49.0.533816460652.issue18086@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There is no good reason to have set_loader and set_package separately. There should just be a single decorator which sets both of those attributes post-import (with the proper doc note saying use module_for_loader instead when possible to have the attributes set during execution).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 190254
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Create importlib.util.set_attrs_post_import()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed May 29 00:49:21 2013
From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=)
Date: Tue, 28 May 2013 22:49:21 +0000
Subject: [New-bugs-announce] [issue18087] os.listdir don't show hidden option
Message-ID: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za>


New submission from Dra?en Lu?anin:

I would like to be able to list a directory, but without showing hidden files. Currently, as discussed in a SO question [1], one has to either code this manually or resort to other libraries (glob). This functionality should be available in the os module.

[1]: http://stackoverflow.com/questions/7099290/how-to-ignore-hidden-files-using-os-listdir-python

----------
components: Extension Modules
messages: 190255
nosy: kermit666
priority: normal
severity: normal
status: open
title: os.listdir don't show hidden option
type: enhancement

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

From report at bugs.python.org  Wed May 29 02:08:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 May 2013 00:08:15 +0000
Subject: [New-bugs-announce] [issue18088] Create
	importlib.abc.Loader.init_module_attrs()
Message-ID: <1369786095.97.0.622799229859.issue18088@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There are a bunch of attributes that need to be set on a module, and yet they are only handled by various decorators in importlib.util. The problem with that is there is no way in the API to override or expand upon setting those attributes pre-loading; only post-loading like what set_loader and set_package do.

importlib.abc.Loader.init_module_attrs(module) would take a module and then using whatever methods are available, sets as many attributes as possible. This method can either be called before execution of the module's code or after some function is called that directly returns a loaded module (e.g. BuiltinImporter).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 190260
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Create importlib.abc.Loader.init_module_attrs()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed May 29 02:09:44 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 May 2013 00:09:44 +0000
Subject: [New-bugs-announce] [issue18089] Create
	importlib.abc.InspectLoader.load_module()
Message-ID: <1369786184.33.0.5189689694.issue18089@psf.upfronthosting.co.za>


New submission from Brett Cannon:

<EOM>

----------
assignee: brett.cannon
components: Library (Lib)
messages: 190261
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Create importlib.abc.InspectLoader.load_module()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed May 29 03:49:54 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 May 2013 01:49:54 +0000
Subject: [New-bugs-announce] [issue18090] dict_contains first argument
	declared register, and shouldn't be
Message-ID: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za>


New submission from Larry Hastings:

I'm monkeying around with CPython trunk, and just noticed the following declaration in Objects/dictobject.c:

    static PyObject *
    dict_contains(register PyDictObject *mp, PyObject *key)

Although dict_contains is a static method, it's cast to PyCFunction and stored in the methoddef array for the dict class.  Therefore it must be callable when cast to a PyCFunction--indeed, that's the only way it is ever called.

Although the "register" keyword is at best a vague hope, surely it'd be bad news if our wish was granted?  The first argument to the PyCFunction typedef is *not* declared register.  So if the caller pushed the first argument on the stack, and dict_contains went looking for its first argument in a register... kablooey.

Surely we must remove the "register" keyword to this function, and similarly clean up all other functions ever cast to PyCFunction or PyCFunctionWithKeywords.

The "register" keyword isn't just a euphemism for "I want this code to go faster" -ly yours,

----------
components: Interpreter Core
messages: 190263
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: dict_contains first argument declared register, and shouldn't be
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed May 29 04:00:44 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 29 May 2013 02:00:44 +0000
Subject: [New-bugs-announce] [issue18091] Remove PyNoArgsFunction
Message-ID: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za>


New submission from Larry Hastings:

There's a typedef in methodobject.h called PyNoArgsFunction.  You might think it's used for METH_NOARGS functions--you'd be wrong, those use PyCFunction and pass in NULL for args.

No, PyNoArgsFunction is never used.  Nor is it documented.  It's found in exactly one place in the CPython tree, and that's when it's declared.  We should consider removing it.

Note that I'm pretty sure this will break external code; a quick Google found that Blender's extension interface uses it.  And AFAICT they still use it, and they *have* moved to Python 3.  So I could believe the right call is "we better leave it in".

I suspect that PyNoArgsFunction *was* used once upon a time.  I further suspect that year started with a 1.

----------
components: Interpreter Core
messages: 190264
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: Remove PyNoArgsFunction
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed May 29 08:25:00 2013
From: report at bugs.python.org (Andreas Jung)
Date: Wed, 29 May 2013 06:25:00 +0000
Subject: [New-bugs-announce] [issue18092] Python 2.7.5 installation broken
	on OpenSuse 12.2
Message-ID: <1369808700.25.0.570015045706.issue18092@psf.upfronthosting.co.za>


New submission from Andreas Jung:

I tried to install 2.7.5 on my OpenSuse 12.2 (latest patches)

ajung at blackmoon2:~/sandboxes/mib.portal> cat /etc/issue
Welcome to openSUSE 12.2 "Mantis" - Kernel \r (\l).


Compilation went fine (no visible errors).

Starting the interpreter gives me:

ajung at blackmoon2:~/sandboxes/mib.portal> /opt/python-2.7.5/bin/python 
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python 2.7.5 (default, May 29 2013, 08:19:10) 
[GCC 4.7.1 20120723 [gcc-4_7-branch revision 189773]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Trying to bootstrap a Pyramid project using zc.buildout gives me:

ajung at blackmoon2:~/sandboxes/mib.portal> /opt/python-2.7.5/bin/python bootstrap.py 
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
  File "bootstrap.py", line 21, in <module>
    import os, shutil, sys, tempfile, urllib, urllib2, subprocess
  File "/opt/python-2.7.5/lib/python2.7/shutil.py", line 12, in <module>
    import collections
  File "/opt/python-2.7.5/lib/python2.7/collections.py", line 8, in <module>
    from _collections import deque, defaultdict
ImportError: No module named _collections

----------
messages: 190274
nosy: Andreas.Jung
priority: normal
severity: normal
status: open
title: Python 2.7.5 installation broken on OpenSuse 12.2
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 29 13:51:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 May 2013 11:51:30 +0000
Subject: [New-bugs-announce] [issue18093] Move main functions to a separate
	Programs directory
Message-ID: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This patch moves the C level main functions for python, _testembed and _freeze_importlib to a new Programs directory.

I added README files with my current understanding of the expected contents of the Python, Objects, Modules and Programs directories and also attempted to update the Windows builds (which don't appear to include _testembed at all).

----------
components: Build, Interpreter Core
files: move_programs.diff
keywords: patch
messages: 190292
nosy: ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Move main functions to a separate Programs directory
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file30408/move_programs.diff

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

From report at bugs.python.org  Wed May 29 14:20:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 29 May 2013 12:20:00 +0000
Subject: [New-bugs-announce] [issue18094] Skip tests in test_uuid not
	silently
Message-ID: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tests in test_uuid just silently skipped if ran on unsuitable platform or if required module is not available. In such cases tests resulted as succesful passed. The proposed patch uses unittest.skipUnless to mark them as skipped.

----------
components: Tests
files: test_uuid.patch
keywords: patch
messages: 190296
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Skip tests in test_uuid not silently
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30410/test_uuid.patch

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

From report at bugs.python.org  Wed May 29 16:07:24 2013
From: report at bugs.python.org (Roman Valov)
Date: Wed, 29 May 2013 14:07:24 +0000
Subject: [New-bugs-announce] [issue18095] unable to invoke socket.connect
	with AF_UNSPEC
Message-ID: <1369836444.73.0.072481574082.issue18095@psf.upfronthosting.co.za>


New submission from Roman Valov:

There is a way to "disconnect" UDP socket
that was previously "connected" to specific
remote endpoint in C:

  struct sockaddr_in sin;        
  memset((char *)&sin, 0, sizeof(sin));
  sin.sin_family = AF_UNSPEC;
  connect(fd, (struct sockaddr *)&sin, sizeof(sin));

However in this is not available in python, since connect
accepts only (host, port) as a parameter for UDP socket.

It's possible to drop "port" connection with port=0,
however I can't find a way to drop "host" connection.

----------
components: IO
messages: 190308
nosy: Roman.Valov
priority: normal
severity: normal
status: open
title: unable to invoke socket.connect with AF_UNSPEC
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed May 29 18:45:24 2013
From: report at bugs.python.org (David Taylor)
Date: Wed, 29 May 2013 16:45:24 +0000
Subject: [New-bugs-announce] [issue18096] bad library order returned by
	python-config.in
Message-ID: <1369845924.16.0.424451971001.issue18096@psf.upfronthosting.co.za>


New submission from David Taylor:

Misc/python-config.in returns a bad library order when given the --ldflags or --libs arguments.  A library should be listed *BEFORE* those libraries that it depends upon.  The python library depends upon all the other libraries listed, but it is listed last -- it should be first.

When linking with shared libraries, you can generally get away with the current behaviour.  When linking with static libraries, it fails

----------
components: Library (Lib)
files: xx
messages: 190319
nosy: taylor
priority: normal
severity: normal
status: open
title: bad library order returned by python-config.in
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file30414/xx

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

From report at bugs.python.org  Wed May 29 19:21:37 2013
From: report at bugs.python.org (Michel Weinachter)
Date: Wed, 29 May 2013 17:21:37 +0000
Subject: [New-bugs-announce] [issue18097] Check out my profile on LinkedIn
Message-ID: <343561565.10012341.1369848095417.JavaMail.app@ela4-bed83.prod>


New submission from Michel Weinachter:

LinkedIn
------------

I'd like to include you in my network to share updates and stay in touch.

- Michel

Michel Weinachter
Senior security manager / RSSI at Thales
Paris Area, France

Confirm that you know Michel Weinachter:
https://www.linkedin.com/e/-3qcne3-hhas6r2q-4f/isd/13708904224/XGTvGJjU/?hs=false&tok=26V0lOdbLhnBM1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hhas6r2q-4f/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4549108961_1/?hs=false&tok=0zmMvplEjhnBM1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
files: unnamed
messages: 190321
nosy: datamoc
priority: normal
severity: normal
status: open
title: Check out my profile on LinkedIn
Added file: http://bugs.python.org/file30415/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18097>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/jpeg
Size: 1181 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20130529/420ec66f/attachment.jpe>

From report at bugs.python.org  Thu May 30 03:17:48 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 May 2013 01:17:48 +0000
Subject: [New-bugs-announce] [issue18098] "Build Applet.app" build fails on
	OS X 10.8
Message-ID: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za>


New submission from Ned Deily:

The Build Applet.app tool for OS X depends on the deprecated EasyDialogs module to interact with the user.  EasyDialogs depends on Apple-deprecated Carbon QuickDraw APIs.  As of OS X 10.8, the headers for the QuickDraw APIs are no longer supplied with Xcode 4.  This means that Build Applet.app can no longer be built on 10.8 unless an earlier version of Xcode and an SDK from an earlier system are used.  The Mac/Makefile target "install_BuildApplet" fails with either:
  ImportError: cannot import name GetNewDialog
or
  AttributeError: 'module' object has no attribute 'GetQDGlobalsScreenBits'
depending on whether the interpreter being built supports 32-bit or not.    

Given that Build Applet.app is already considered deprecated and has been removed in Python 3, it does not seem appropriate to attempt to re-engineer its GUI interface.  Instead, the Makefile should just skip building it if EasyDialogs is not available.

(Note that the QuickDraw libraries are still being shipped in OS X 10.8, so a "Build Applet.app" built on an older system - such as with the python.org OS X installers - will still run on 10.8.  There is no guarantee that will still be true in future versions of OS X.)

----------
assignee: ned.deily
components: Build, Macintosh
messages: 190333
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: "Build Applet.app" build fails on OS X 10.8
versions: Python 2.7

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

From report at bugs.python.org  Thu May 30 12:33:28 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 30 May 2013 10:33:28 +0000
Subject: [New-bugs-announce] [issue18099] wsgiref sets Content-Length: 0 on
	304 Not Modified
Message-ID: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

While testing wsgiref w.r.t RFC2616, I noticed that it sets the Content-Length to 0 when the application returns 304 Not Modified.

This is a violation of RFC 2616 section 10.3.5.

And the net effect is a weird bug with some browsers (tested with Chrome 27) where the resource is truncated on 304 Not Modified.
(the resource was a CSS file in that case)

This is loosely related to http://bugs.python.org/issue3839.


# How to reproduce:

def test_304():
    import time
    from email.utils import formatdate
    from wsgiref.simple_server import make_server

    def demo_app(environ, start_response):
        if 'HTTP_IF_MODIFIED_SINCE' in environ:
            start_response("304 Not Modified", [])
            return []
        headers = [('Content-Type', 'text/html; charset=utf-8'),
                   ('Last-Modified', formatdate(time.time(), usegmt=True))]
        start_response("200 OK", headers)
        return ["Hello World!"]

    httpd = make_server('127.0.0.1', 8000, demo_app)
    sa = httpd.socket.getsockname()
    print("Serving HTTP on %s port %s ..." % sa)
    httpd.serve_forever()

if __name__ == '__main__':
    test_304()

----------
components: Library (Lib)
messages: 190352
nosy: flox, pitrou, pje
priority: normal
severity: normal
status: open
title: wsgiref sets Content-Length: 0 on 304 Not Modified
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/issue18099>
_______________________________________

From report at bugs.python.org  Thu May 30 14:56:22 2013
From: report at bugs.python.org (Tom van Leeuwen)
Date: Thu, 30 May 2013 12:56:22 +0000
Subject: [New-bugs-announce] [issue18100] socket.sendall() cannot send
	buffers of 2GB or more
Message-ID: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za>


New submission from Tom van Leeuwen:

When using socket.sendall() to send a buffer of 2GB or more (for example, numpy.zeros(2*GB, dtype=numpy.uint8) ), it doesn't send anything at all.

In socketmodule.c, socket.sendall() sock_sendall uses an int for len, while this should be a Py_ssize_t.

----------
components: Build
messages: 190357
nosy: Tom.van.Leeuwen
priority: normal
severity: normal
status: open
title: socket.sendall() cannot send buffers of 2GB or more
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu May 30 15:59:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 May 2013 13:59:21 +0000
Subject: [New-bugs-announce] [issue18101] Tk.split() doesn't work with
	nested Unicode strings
Message-ID: <1369922361.42.0.622055843561.issue18101@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tk.split() doesn't work with nested Unicode strings, but works with nested bytes.

>>> import tkinter
>>> t = tkinter.Tcl()
>>> t.split('a {b c}')
('a', ('b', 'c'))
>>> t.split(b'a {b c}')
('a', ('b', 'c'))
>>> t.split(('a {b c}',))
('a {b c}',)
>>> t.split((b'a {b c}',))
(('a', ('b', 'c')),)

I think this is unintentional. Here is a patch which processes strings inside a tuple as bytes objects. It also adds tests for Tk.splitline() and Tk.split().

----------
components: Tkinter
files: tkinter_split_nested_unicode.patch
keywords: patch
messages: 190359
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Tk.split() doesn't work with nested Unicode strings
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30426/tkinter_split_nested_unicode.patch

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

From report at bugs.python.org  Thu May 30 17:35:59 2013
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 30 May 2013 15:35:59 +0000
Subject: [New-bugs-announce] [issue18102] except-clause with own exception
	class inside generator	can lead to confusing warning on termination
Message-ID: <1369928159.24.0.947067999583.issue18102@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau:

The following code will sometimes warn about an ignored TypeError('catching classes that do not inherit from BaseException is not allowed',) on termination:


class MyException(Exception):
    pass

def gen():
    try:
        yield
    except MyException:
        pass

g = gen()
next(g)


Of course, MyException inherits from Exception, so there should be no problem.

Apparently, MyException gets destroyed before the generator object (at least sometimes, presumably depending on the hash randomization seed), and the destructor of the generator object then complains because there is no MyException any more. At least that's my explanation of this, without having digged into the code.

----------
components: Interpreter Core
messages: 190365
nosy: hagen
priority: normal
severity: normal
status: open
title: except-clause with own exception class inside generator can lead to confusing warning on termination
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu May 30 23:06:57 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 May 2013 21:06:57 +0000
Subject: [New-bugs-announce] [issue18103] Create a GUI test framework for
	Idle
Message-ID: <1369948017.01.0.493052648792.issue18103@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This is a follow-up to #15392, which created the Idle test framework. The similar endpoint for this issue will be a framework for tests that require a gui resource, at least one prototype test file, and documentation of Idle practice. At the moment, completely automated tests that can run on buildbots with a gui, but without human intervention, are a lower priority to me than adding text-only tests.

The tkinter test framework should be a starting point, but some things should be modernized, as they were for the basic framework. This means using unittest rather than regrtest. One thing to copy may be to put gui-tests in a separate directory. I presume load_tests() could conditionally load tests in such a directory.

It is not clear to me to what extent tk widgets can be created and manipulated without being shown on a screen or needing a 'gui' resource.

Idle tests are not intended to test tkinter and tk. A mock_tk could replace at least some gui use. Creating a mock-tk framework would be a different issue from this one. A generic tk mock might possibly go in a tkinter subdirectory. Mocks of Idle classes would belong somewhere below idle_test.

As noted in #15392, about 20 idlelib files have primitive non-automated 'main' tests requiring unspecified human action and observation, some of which do not even run. The 'test' is to see whether the action produced the expected response (which one has to know) or to check the appearance of a text or dialog widget. A first step might be to upgrade and semi-automate these instructions with unittests in idle_test/human. Running them all with one documented command or import would be much nicer pleasant than having to discover and run each individually. I might make this a separate sub-issue.

----------
assignee: terry.reedy
messages: 190381
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Create a GUI test framework for Idle
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 31 02:52:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 May 2013 00:52:01 +0000
Subject: [New-bugs-announce] [issue18104] Idle: make human-mediated GUI
	tests usable
Message-ID: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

23 of the 62 idlelib/*.py files have an 'if __name__ ...' test that brings up a tkinter gui widget and waits for the human tester to do ... something. Problems:

0. They are a bit of a nuisance to run individually: either type
python -m idlelib.SomeLongNameYoumightMistype
or open in an editor and hit F5.

Running all is much worse given that I found no list; doing the above with all 62 files to find the 23 is something few would do.

1. About 5 do not run; at least 1 is a simple incomplete 2to3 fix (which means it has never been run with 3.x). I will post separately any that are not obvious.

2. They were written by and for the module authors; some are a puzzle. For example: python -m idlelib.FileList. I do not know what to do to perform the test.

3. About 4 of those that do run do not stop properly, depending on how run. Example: after python -m idlelib.ColorDelegator, the puzzling window (blank on 3.3, not 2.7) seems to close correctly, but open the same file and run with F5 (2.7 or 3.3, Windows) and pressing [x] in the window does nothing. But most do close so this is something different with a few.

4. Even when the test is fairly obvious, (python -m idlelib.MultiStatusBar) there is no way to indicate failure so that an  automated record of failures is collected.

My overall idea expands on the example of the dialog tests, such as
python -m idlelib.aboutDialog
Each opens a master test window with a start button that opens a window with the dialog be tested. Make a standardized master window for all tests, add an explanation of what to do (or a button to display it) and buttons to record the result: OK, NothingHappened, or Error (explain in text widget). A test method would set up the explanation and test item, connect both to a master window, run, retrieve result (I have no idea how to do this ;-), and end with AssertTrue(result, explanation).

I am thinking to suffix human-only tests with '_H' and put 'test_xyy_H' in a subdirectory such as idle_test/human. Some test files might test several different modules, such as 'test_dialog_H'.

----------
assignee: terry.reedy
messages: 190388
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: make human-mediated GUI tests usable
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May 31 08:54:16 2013
From: report at bugs.python.org (Adam Urban)
Date: Fri, 31 May 2013 06:54:16 +0000
Subject: [New-bugs-announce] [issue18105] ElementTree writes invalid files
	when UTF-16 encoding is	specified
Message-ID: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za>


New submission from Adam Urban:

import xml.etree.ElementTree as ET
tree = ET.parse("myinput.xml")
tree.write("myoutput.xml", encoding="utf-16")

...Output is a garbled mess, often a mix of UTF-8 and UTF-16 bytes... UTF-8 output works fine, but when UTF-16, UTF-16LE, or UTF-16BE are specified the output is mangled.

----------
components: Unicode, XML
messages: 190392
nosy: Adam.Urban, ezio.melotti
priority: normal
severity: normal
status: open
title: ElementTree writes invalid files when UTF-16 encoding is specified
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri May 31 10:13:32 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 31 May 2013 08:13:32 +0000
Subject: [New-bugs-announce] [issue18106] There are unused variables
	in	Lib/test/test_collections.py
Message-ID: <1369988012.39.0.245549184475.issue18106@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In two "test_copying" methods in Lib/test/test_collections.py, variable i is never used. My guess is the original test writer forgot to utilize the variable i.

For example, in test_copying method in TestOrderedDict class:

    def test_copying(self):
        # Check that ordered dicts are copyable, deepcopyable, picklable,
        # and have a repr/eval round-trip
        pairs = [('c', 1), ('b', 2), ('a', 3), ('d', 4), ('e', 5), ('f', 6)]
        od = OrderedDict(pairs)
        update_test = OrderedDict()
        update_test.update(od)
        for i, dup in enumerate([
                    od.copy(),
                    copy.copy(od),
                    copy.deepcopy(od),
                    pickle.loads(pickle.dumps(od, 0)),
                    pickle.loads(pickle.dumps(od, 1)),
                    pickle.loads(pickle.dumps(od, 2)),
                    pickle.loads(pickle.dumps(od, 3)),
                    pickle.loads(pickle.dumps(od, -1)),
                    eval(repr(od)),
                    update_test,
                    OrderedDict(od),
                    ]):
            self.assertTrue(dup is not od)
            self.assertEqual(dup, od)
            self.assertEqual(list(dup.items()), list(od.items()))
            self.assertEqual(len(dup), len(od))
            self.assertEqual(type(dup), type(od))

The variable i in "for i, dup in enumerate" is never used.

The test_copying method in TestCounter class has the same problem.

In my opinion, we need to put variable i inside the message in the assert functions to detect which place inside the iteration the test fails.

----------
components: Tests
files: test_copying.patch
keywords: patch
messages: 190393
nosy: vajrasky
priority: normal
severity: normal
status: open
title: There are unused variables in Lib/test/test_collections.py
versions: Python 3.4
Added file: http://bugs.python.org/file30432/test_copying.patch

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

From report at bugs.python.org  Fri May 31 11:49:53 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 31 May 2013 09:49:53 +0000
Subject: [New-bugs-announce] [issue18107] 'str(long)' can be made faster
Message-ID: <1369993793.36.0.708057511123.issue18107@psf.upfronthosting.co.za>


New submission from Armin Rigo:

If you have in x some very large number, like 3**200000, then the computation for 'str(x)' is sub-efficient.  Nathan Hurst posted to the pypy-dev mailing list a pure Python algo that gives the same result in 2/3rd of the time (in either CPython or PyPy).  We would get a similar gain by recoding this algorithm in C.

The mail is here: http://mail.python.org/pipermail/pypy-dev/2013-May/011433.html

----------
messages: 190397
nosy: arigo
priority: normal
severity: normal
status: open
title: 'str(long)' can be made faster
type: performance

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

From report at bugs.python.org  Fri May 31 15:09:57 2013
From: report at bugs.python.org (Colin Watson)
Date: Fri, 31 May 2013 13:09:57 +0000
Subject: [New-bugs-announce] [issue18108] shutil.chown should support dir_fd
	and follow_symlinks	keyword arguments
Message-ID: <1370005797.04.0.715885093574.issue18108@psf.upfronthosting.co.za>


New submission from Colin Watson:

Python 3.3 added the dir_fd and follow_symlinks keyword arguments to os.chown; it also added the shutil.chown function.  Unfortunately the latter, while useful, does not support these new keyword arguments.  It would be helpful if it did.

----------
components: Library (Lib)
messages: 190404
nosy: cjwatson
priority: normal
severity: normal
status: open
title: shutil.chown should support dir_fd and follow_symlinks keyword arguments
versions: Python 3.3

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

From report at bugs.python.org  Fri May 31 21:58:40 2013
From: report at bugs.python.org (Dominik Richter)
Date: Fri, 31 May 2013 19:58:40 +0000
Subject: [New-bugs-announce] [issue18109] os.uname() crashes if hostname
	contains non-ascii	characters
Message-ID: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za>


New submission from Dominik Richter:

To reproduce (tested on Arch Linux, python 3.3.2):

  sudo hostname h?t
  python -c "import os; os.uname()"

produces:

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

----------
components: Unicode
messages: 190413
nosy: Dominik.Richter, ezio.melotti
priority: normal
severity: normal
status: open
title: os.uname() crashes if hostname contains non-ascii characters
type: crash
versions: Python 3.3

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