From report at bugs.python.org  Tue Feb  1 00:02:42 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Jan 2011 23:02:42 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296474363.6.0.287806699302.issue11016@psf.upfronthosting.co.za>
Message-ID: <4D473F90.1060003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 31.01.2011 12:46, schrieb Jes?s Cea Avi?n:
> 
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
> 
> Martin, I guess "stat" deprecation could require a few years and it
> would be an extra incompatibility burden between 2.7 and 3.x.
> 
> Beside the symbolic constants, why would you see "stat" deprecated?.

Because it doesn't provide any useful functionality, and confuses
the users. The ST_* constants should have been deprecated long ago,
since people really should use the st_ members of stat_result. In
addition, stat_result should stop behaving like a tuple.

The other constants and functions (S_*) are plainly non-portable.
Apparently, contributor have the illusion that the values they put
into the file are somehow standardized, when they are actually not.
So having the module available makes people like you wonder how
to best support it (see msg127107 and msg127110). Better remove
it so that it doesn't confuse you anymore.

----------

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

From report at bugs.python.org  Tue Feb  1 00:07:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 Jan 2011 23:07:02 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za>
Message-ID: <1296515222.1.0.23783742745.issue11016@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Apparently, contributor have the illusion that the values they put
> into the file are somehow standardized, when they are actually not.

Are there actual bugs with that or is it merely a theoretical concern?

----------

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

From report at bugs.python.org  Tue Feb  1 00:53:13 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 31 Jan 2011 23:53:13 +0000
Subject: [issue11016] Add S_ISDOOR to the stat module
In-Reply-To: <1296515222.1.0.23783742745.issue11016@psf.upfronthosting.co.za>
Message-ID: <4D474B67.6050402@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> Apparently, contributor have the illusion that the values they put
>> into the file are somehow standardized, when they are actually not.
> 
> Are there actual bugs with that or is it merely a theoretical concern?

Neither, nor (i.e. it's in the middle). I'm not aware of an actual
problem, but I very much doubt that SF_SNAPSHOT really has the same
meaning on all systems (IOW, chances are high that some system has
allocated the same bit to mean something different).

Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines
0xe000 as S_IFWHT (whiteout), but Solaris defines it as
S_IFPORT (event port).

----------

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

From report at bugs.python.org  Tue Feb  1 01:02:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2011 00:02:38 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1296518558.73.0.684426353588.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #6011.

----------

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

From report at bugs.python.org  Tue Feb  1 01:03:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2011 00:03:16 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1296518596.61.0.504539124607.issue10614@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: ZipFile and CP932 encoding -> ZipFile: add a filename_encoding argument

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

From report at bugs.python.org  Tue Feb  1 01:03:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2011 00:03:34 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296518614.25.0.811446496003.issue11022@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Attached patch replaces locale.getpreferredencoding() by locale.getpreferredencoding(False) in _io.TextIOWrapper and _pyio.TextIOWrapper.

----------
keywords: +patch
Added file: http://bugs.python.org/file20637/io_dont_set_locale.patch

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

From report at bugs.python.org  Tue Feb  1 01:05:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Feb 2011 00:05:46 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296518746.35.0.0807710540984.issue11022@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Tue Feb  1 03:02:22 2011
From: report at bugs.python.org (Owen)
Date: Tue, 01 Feb 2011 02:02:22 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1296525742.53.0.567487191938.issue9884@psf.upfronthosting.co.za>


Owen <j2.nete at gmail.com> added the comment:

Thanks, this issue has been fixed. :-)
fixing revisions:
r88284 (3.2), r88285 (3.1) and r88286 (2.7)

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Feb  1 03:07:06 2011
From: report at bugs.python.org (Alex McNerney)
Date: Tue, 01 Feb 2011 02:07:06 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296526026.86.0.744511145615.issue11075@psf.upfronthosting.co.za>


Alex McNerney <amcnerney13 at yahoo.com> added the comment:

It may be because the program that I am trying to run automatically exits, I do not know yet how to keep a turtle program running (waiting for input). The only way I know so far is to use the function "exitonclick()," but when using that, my I cannot use any other mouseevents in my program. (Help?) Anyways, an example of a script that will cause turtle to hang/crash is even such a simple one as:
"
import turtle as t
def flfr():
    t.fd(10)
    t.lt(45)
    t.fd(10)
    t.rt(45)
t.onkey(flfr, "Up")
t.listen()
"
Is there anyway to keep a turtle program running, waiting for user interaction without using the exitonclick() function? Also, thank you for pointing out the maintenance svn, I did an svn checkout, compiled, and installed it and it fixed other problems that I was having with Python 2.7.1 ActiveState Tcl/Tk 8.5.9 (such as hanging when running a program when the shell isn't open.)

Another quick question that you don't have to answer: is there anyway to ignore interaction (keystrokes, mouseclicks) while an onkey function is activated? Like if I make a function that takes 10 seconds to complete, can I ignore all interaction while that function is being run?

Thank you for your time.

----------

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

From report at bugs.python.org  Tue Feb  1 03:28:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Feb 2011 02:28:12 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296527292.42.0.590125452899.issue11075@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the bug tracker isn't really the place to get help on using Python.  I would suggest posting to python-list, you are more likely to find people with the time to help you there.  You should also take a look at the Turtle demo programs, I'm pretty sure you can find your answers there as I know some of them are interactive.

Turtle is designed to work from IDLE, so if it doesn't it's a bug.

You haven't mentioned an actual crash of the python interpreter, so I'm changing the type to behavior.

----------
nosy: +r.david.murray
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  1 03:43:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Feb 2011 02:43:24 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296528204.06.0.564576662798.issue11022@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Steffan: I'm not sure what your post means, but I think there is a chance you might be confused about something.  Python should *never* change the locale from the C locale.  A Python *program* can do so, by calling setlocale, but Python itself should not.  This is because when an arbitrary Python program is run, it needs to run in the C locale *unless it chooses otherwise*.  To do anything else would produce a myriad portability problems for any code that is affected by locale settings (especially when the programmer doesn't know that it is so affected).

This is orthogonal to the issue of deciding what encoding to use for various bits of I/O, where Python may need to discover what locale the user has chosen as a default.  It's too bad libc makes this so hard to do safely.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Tue Feb  1 05:06:25 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 04:06:25 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296533185.86.0.942908617838.issue11086@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It is unfortunate that the cute name for the tool is not valid as a module name.  How about renaming "lib2to3" to "to3".  The offending leading digit is strictly redundant (there is no 1to3 after all).

----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Feb  1 05:27:05 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 04:27:05 +0000
Subject: [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1296534425.38.0.180268016903.issue1215@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The consensus is that this is not a crash (and not even a bug).  I am not sure what is the proper type for doc enhancement, but is certainly should not show up in a search for crashers.

----------
components:  -Interpreter Core
nosy: +belopolsky
type: crash -> 

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

From report at bugs.python.org  Tue Feb  1 05:37:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 04:37:38 +0000
Subject: [issue886488] popen2 on Windows does not check _fdopen return value
Message-ID: <1296535058.72.0.110695730092.issue886488@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: unit test needed -> needs patch
title: WinPython 2.3.3 crashes using popen2 to spawn lots of child -> popen2 on Windows does not check _fdopen return value

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

From report at bugs.python.org  Tue Feb  1 06:00:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 05:00:49 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1296536449.96.0.0897260034863.issue7074@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I can reproduce the crash on OSX.  After ~ 100 keystrokes, I get the following diagnostics:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/tkinter/__init__.py", line 1399, in __call__
    return self.func(*args)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 701, in eventfun
    fun()
  File "turtlecrash.py", line 12, in klt
    def klt(): seth(180); fd(vel)
  File "<string>", line 1, in seth
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 1936, in setheading
    self._rotate(angle)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 3277, in _rotate
    self._update()
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 2660, in _update
    self._update_data()
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 2651, in _update_data
    self._pencolor, self._pensize)
  File "/Users/sasha/Work/python-svn/py3k-commit/Lib/turtle.py", line 545, in _drawline
    self.cv.coords(lineitem, *cl)
  File "<string>", line 1, in coords
RuntimeError: maximum recursion depth exceeded
Fatal Python error: Cannot recover from stack overflow.
Abort trap

----------
nosy: +belopolsky
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  1 06:10:32 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Feb 2011 05:10:32 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296537032.59.0.158412261475.issue11086@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Would needlessly break code for such a minor perk. I mean I doubt very many people will use this feature if it goes in. It's just rather nice for those who do want the feature to exist in the first place.

----------

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

From report at bugs.python.org  Tue Feb  1 06:14:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 05:14:27 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1296537267.46.0.477970342181.issue7074@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This looks like a duplicate of issue11029.  It is not safe to call graphic primitives in event callbacks.  A workaround is described at <http://effbot.org/zone/tkinter-threads.htm>.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Crash, 2.7.1, Tkinter and threads and line drawing

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

From report at bugs.python.org  Tue Feb  1 06:24:06 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 05:24:06 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1296537846.2.0.938383560571.issue7330@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Unicode
nosy: +haypo

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

From report at bugs.python.org  Tue Feb  1 06:30:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Feb 2011 05:30:10 +0000
Subject: [issue7574] PyUnicode_FromFormat broken and not documented for 2.x
In-Reply-To: <1261655681.25.0.454963458841.issue7574@psf.upfronthosting.co.za>
Message-ID: <1296538210.24.0.519881297327.issue7574@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Documentation part of this issue will be addressed in #10435.

----------
nosy: +belopolsky
resolution:  -> duplicate
stage: needs patch -> committed/rejected
superseder:  -> PyUnicode_FromFormat segfault

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

From report at bugs.python.org  Tue Feb  1 08:57:33 2011
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 01 Feb 2011 07:57:33 +0000
Subject: [issue11087] Speeding up the interpreter with a few lines of code
In-Reply-To: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>
Message-ID: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos <jneb at users.sourceforge.net>:

I found a very simple way to improve the speed of CPython a few percent on the most common platforms (i.e. x86), at the cost of only a few lines of code in ceval.c
The only problem is that I don't have any experience in patch submission.

Here are the suggested new lines (also see submitted file):

#define NEXTARG() (next_instr +=2, *(unsigned short*)&next_instr[-2])
#define PEEKARG() (*(unsigned short*)&next_instr[1])

of course this code only works on little-endian processors that allow nonaligned shorts; a change to configure might be needed (*shiver*).

Hope you like it.

----------
components: Interpreter Core
files: speedpatch.c
messages: 127686
nosy: jneb
priority: normal
severity: normal
status: open
title: Speeding up the interpreter with a few lines of code
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20638/speedpatch.c

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

From report at bugs.python.org  Tue Feb  1 09:37:01 2011
From: report at bugs.python.org (Alex McNerney)
Date: Tue, 01 Feb 2011 08:37:01 +0000
Subject: [issue11075] Turtle crash with IDLE on Mac OS X 10.6
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296549421.52.0.785842645017.issue11075@psf.upfronthosting.co.za>


Alex McNerney <amcnerney13 at yahoo.com> added the comment:

Sorry to keep bothering, but running Python 2.7.1:88286 (maintenance) on ActiveState Tcl/Tk 8.5.9 causes the idle to hang when a simple script like:
"
x = raw_input("x: ")
print x
"
is run. Is this a bug in Tcl/Tk? Looking in the logs I see several instances of "setCanCycle: is deprecated.  Please use setCollectionBehavior instead" Does this have any relevancy?

Relating to this, I don't know if it is proper to ask here, but is it possible to link Python to a specific Tcl/Tk when compiling from the source?

Note: When running Python 2.7.1 (32-bit from installer) with Tcl/Tk 8.4, the above problem is not there.

----------

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

From report at bugs.python.org  Tue Feb  1 09:42:55 2011
From: report at bugs.python.org (=?utf-8?q?Mads_Dar=C3=B8_Kristensen?=)
Date: Tue, 01 Feb 2011 08:42:55 +0000
Subject: [issue4735] An error occurred during the installation of assembly
In-Reply-To: <1230086140.51.0.868984437874.issue4735@psf.upfronthosting.co.za>
Message-ID: <1296549775.02.0.680358085626.issue4735@psf.upfronthosting.co.za>


Mads Dar? Kristensen <madsdk at gmail.com> added the comment:

I have this problem using Python 2.7.1 on a 32-bit Windows 7 PC.

----------
nosy: +madsdk
versions: +Python 2.7

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

From report at bugs.python.org  Tue Feb  1 10:01:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 01 Feb 2011 09:01:08 +0000
Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC
In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za>
Message-ID: <1296550868.06.0.51552355095.issue11084@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Feb  1 10:55:40 2011
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 01 Feb 2011 09:55:40 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296554140.77.0.0382843295221.issue11085@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Tue Feb  1 11:35:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 01 Feb 2011 10:35:15 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1296556515.31.0.748863788894.issue8998@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Tue Feb  1 11:46:50 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 10:46:50 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296557210.54.0.074017413354.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Now that I looked at the documentation (http://docs.python.org/library/turtle.html), I see that it is clear that Turtle is designed to work from IDLE *but*, as is noted, "when using the module from within IDLE run with the -n switch", which means run IDLE without a subprocess.  What may not be so obvious is how to do that on Mac OS X.  Double-clicking on IDLE.app launches it with default values including a subprocess and there is no straightforward to override those.  From a terminal shell, it is easy to start bin/idle:

   $ idle2.7 -n

although that has a few cosmetic disadvantages with bin/idle over IDLE.app (for example, the application name displayed is "Python" not "IDLE").  It has aways been possible to launch an OS X GUI app from a shell command line using the open(1) command; as of OS X 10.6 it is now also possible to pass regular command line arguments to the application.  So the following would work in 10.6 and probably be preferable:

   $ open -a "/Applications/Python 2.7/IDLE.app" --args -n

If you want to have a double-clickable application, a simple approach is to create a launcher application with AppleScript:

   $ osacompile -o 'IDLE-n.app' <<EOF
   > do shell script "open -a '/Applications/Python 2.7/IDLE.app' --args -n"
   > EOF

As someone not used to using Turtle and given the intended user base for Turtle, I wonder whether the current Turtle module documentation is sufficient on this point.  Two possible actions I could see are: (1) expanding the documentation to include a suggestion like the above to allow for an OS X clickable app; and/or (2) actually supplying such a simple no-subprocess app with the standard python.org installer distribution (or some other solution).  How is this issue handled on Windows?  Is there a need to expand the documentation in general?
(adding Raymond to the nosy list)

----------
nosy: +rhettinger
title: Turtle crash with IDLE on Mac OS X 10.6 -> Using Turtle with IDLE on Mac OS X
versions: +Python 3.2

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

From report at bugs.python.org  Tue Feb  1 11:52:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2011 10:52:58 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1296557578.89.0.778921995216.issue7330@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened other tickets related to PyUnicode_FromFormatV:

 * #10833 :Replace %.100s by %s in PyErr_Format(): the arbitrary limit of 500 bytes is outdated
 * #10831: PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
 * #10830: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters on narrow build
 * #10829: PyUnicode_FromFormatV() bugs with "%" and "%%" format strings

(see also #10832: Add support of bytes objects in PyBytes_FromFormatV())

PyUnicode_FromFormatV() has now tests in test_unicode: issue_7330.diff should add new tests, at least to check that %20R doesn't crash.

----------

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

From report at bugs.python.org  Tue Feb  1 12:02:52 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 11:02:52 +0000
Subject: [issue11088] IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input
	/ raw_input
In-Reply-To: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>
Message-ID: <1296558172.37.0.962954496382.issue11088@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

As reported by Alex McNerney in Issue11075 msg127687:

"... running Python 2.7.1:88286 (maintenance) [built from source] on ActiveState Tcl/Tk 8.5.9 causes the idle to hang when a simple script like:
"
x = raw_input("x: ")
print x
"
is run. Is this a bug in Tcl/Tk? Looking in the logs I see several instances of "setCanCycle: is deprecated.  Please use setCollectionBehavior instead" Does this have any relevancy?"

I can reproduce the problem using input with Cocoa Tk 8.5 and Python 3.2rc2 or raw_input with Python 2.7.1+.  It does not seem to happen with Carbon Tk 8.4.  This may be related to Issue10940.  Investigating further for impact on 3.2.

----------
assignee: ned.deily
components: IDLE, Macintosh
messages: 127691
nosy: amcnerney13, ned.deily
priority: critical
severity: normal
status: open
title: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw_input
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  1 12:13:06 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 11:13:06 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296558786.84.0.723847285263.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

[Please don't add new topics to the same tracker issue.  As David mentioned, it would be better to ask for help on one of the user lists to be sure before opening an issue.  Besides the general python-list, there is an active OS X users list (pythonmac-sig) where you will find users of IDLE;  see http://www.python.org/community/sigs/

That said, to address your most recent message, that appears to indeed be a problem.  I've opened Issue11088 for it.  The "setCanCycle: is deprecated" messages are a harmless artifact; they should disappear in an upcoming maintenance release of ActiveState Tcl 8.5.]

----------

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

From report at bugs.python.org  Tue Feb  1 12:58:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 01 Feb 2011 11:58:24 +0000
Subject: [issue11022] locale.setlocale() doesn't change I/O codec,
	os.environ does
In-Reply-To: <1296126025.04.0.965125504096.issue11022@psf.upfronthosting.co.za>
Message-ID: <1296561504.53.0.108765419984.issue11022@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Most of this is much too loud for a newbie who is about to read PEP 7 anyway.  And if this community has chosen to try (?!?) not to break compatibility with code which does not have a notion of a locale setting (i.e. naively uses other code in that spirit), you know, then this is simply the way it is.  Thus: you're right.  I do agree with what you say, we here have a (8-bit) C++ library which does this in it's setup():

        // Initialize those Locale variables we're responsible for
        Locale::_ctype_cclass = Locale::_posix_cclass;
        Locale::_ctype_ccase = Locale::_posix_ccase;

(Like i said: we here went completely grazy and avoid system libraries whenever possible and at least directly, doing the stuff ourselfs and only with syscalls.)

Besides that i would agree with me that unthreaded init, optional embeddor locale argument, cleanup of .getprefer...() and other drops of setlocale() are/would be good design decisions.  And of course: "keeping the thing simple and understandable" is a thing to keep in mind in respect to a normal user.

After the end (i have to excuse myself once again for a book):
I, f.e., opened an issue 11059 on saturday because the HG repo was (2.7 may still be) not cloneable, and i did so at selenic, too.  Notes on that:
- pitrou closed it because this tracker is of course for Python bugs.   (I asked him to decide - thanks.)
- The selenic people told me that i added my trace to a completely wrong issue.  (Just searched - that's more than shown in trace dump.)
- I've found out that many, *many* issues seem to have been created due to this repo failure at python.org (at selenic), and i've added a note that they possibly should include a prominent notice that people should look for "most recent call last" before creating a new one.  (I guess that most of these people are programmers - who else uses HG?)
- Conclusion: maybe even os.environ[]= == locale.setlocale() is not simple minded enough.

----------

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

From report at bugs.python.org  Tue Feb  1 13:40:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 12:40:24 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296564024.31.0.408327208744.issue11079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I agree that adding a link to the installed documentation set would be an improvement.  Currently, the only easy way to find it is within IDLE:  Help -> Python Docs (or F1).  I'll propose an installer patch for that for 3.2.

-0.5 for removing the Extras directory.  Prior to Python 3.2, it contained the contents of the Demo directory.  For 3.2, the Demo directory was pruned and relocated to Tools, which had not previously been installed anywhere by OS X installers.  Also, there has been at least one request to make some of the contents of Tools available on OS X, i.e. unittestgui.  For those reasons, I added Tools under Extras for 3.2.  I agree that much of the contents is not particularly useful from, say, IDLE.  But the Python Launcher will run them under a command line and users can easily drag/drop any of onto a python command line in a terminal shell or just cd there and can also use the Finder's Get Info to change the application associated with them.  That said, the launching of Python scripts in OS X is currently is currently somewhat fragile and unintuitive (in the presence of multiple Python versions) and in need of some work post-3.2; see, for instance, Issue5262.  Due to OS X's multiple personalities and interaction styles (Classic Mac, command line UNIX, X-based apps, etc), it's also difficult to assess exactly how the python.org installed Pythons are being used on OS X. My guess, though, is that a majority of our users these days primarily or exclusively use Python from a command line so it would be good to not neglect their needs.

The issue of uninstalling has come up before, most recently (IIRC) in Issue7107.  Unfortunately, the Mac/README file updated there is not installed.  I would be +0.5 at looking into it further as time permits while recognizing that there would need to be caveats like potentially wiping out installed system-wide site-packages.

----------

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

From report at bugs.python.org  Tue Feb  1 13:42:38 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 01 Feb 2011 12:42:38 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296564158.49.0.743412542341.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I've extracted and fixed the part of this patch that implements the slice object cache. In particular, PySlice_Fini() was incorrectly implemented. This patch applies cleanly for me against the latest py3k branch.

----------
Added file: http://bugs.python.org/file20639/slice-object-cache.patch

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

From report at bugs.python.org  Tue Feb  1 14:16:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Feb 2011 13:16:06 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296566166.39.0.249087748982.issue11075@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ned: I read the bits in the turtle docs about -n as meaning *if* you use -n *then* you should set this profile option (but if you don't, things should work).  I didn't go over the docs in detail, though, so maybe I'm misreading.  Since you and I clearly don't know what we are talking about in detail, I'm adding Gregor and Alexander (the latter since he's clearly been using it) to nosy.

----------
assignee: ned.deily -> 
nosy: +belopolsky, gregorlingl

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

From report at bugs.python.org  Tue Feb  1 14:17:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 13:17:09 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296566229.19.0.956819891324.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's clear from testing it and from some searches that -n is, in fact, required.

----------

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

From report at bugs.python.org  Tue Feb  1 14:31:52 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Feb 2011 13:31:52 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296567112.71.0.184834903706.issue11079@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm -0 on removing extras. Having extra's at this location makes it easier to discover them.

Adding a link to the documention is a good idea, it makes the documentation easier to use without starting IDLE.

Adding an uninstall option would be nice, but that requires significant work and is not something to be added before 3.2.   Adding an installer requires us to write a script that does the work because while OSX has an installer it doesn't have the corresponding uninstaller. Such a script should only be added after carefully testing it, there is a significant risk that bugs in the script could erase too much content.

----------

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

From report at bugs.python.org  Tue Feb  1 15:04:42 2011
From: report at bugs.python.org (Vasilis)
Date: Tue, 01 Feb 2011 14:04:42 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>


New submission from Vasilis <Vasilis.Vlachoudis at cern.ch>:

The ConfigParser class in 2.7 is almost >50 times slower than in the 2.6 which for large files it renders it almost unusable. Actually the speed decrease depends on the amount of the stored data

Results from test program:
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00)
on 3.5GHz Fedora14 64bit machine
ConfigParser 166.307140827                
RawConfigParser 0.1887819767 

Python 2.6.4 (r264:75706, Jun  4 2010, 18:20:31)
on 3.0GHz Fedora13 64bit machine
ConfigParser 4.24494099617
RawConfigParser 0.172905921936

----------
components: Extension Modules
files: ConfigParserTest.py
messages: 127699
nosy: vlachoudis
priority: normal
severity: normal
status: open
title: ConfigParser 50x slower in 2.7
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file20640/ConfigParserTest.py

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

From report at bugs.python.org  Tue Feb  1 15:13:24 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Feb 2011 14:13:24 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296569604.21.0.131081463619.issue11075@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, in that case I think the docs could be improved on that point.

----------

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

From report at bugs.python.org  Tue Feb  1 15:20:41 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 01 Feb 2011 14:20:41 +0000
Subject: [issue10214] Misc/python-mode.el is out of date.
In-Reply-To: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>
Message-ID: <1296570041.48.0.111906735693.issue10214@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Please ignore, testing roundup.

----------

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

From report at bugs.python.org  Tue Feb  1 15:21:55 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Feb 2011 14:21:55 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296570115.86.0.482362346277.issue11075@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I saw this post by Gregor: http://thread.gmane.org/gmane.comp.python.general/334881/focus=334996

I don't know applicable it still is on Windows.  But it does seem to be still true on OS X.

----------

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

From report at bugs.python.org  Tue Feb  1 15:23:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Feb 2011 14:23:35 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296570215.06.0.395666366035.issue11089@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa

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

From report at bugs.python.org  Tue Feb  1 15:30:27 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 01 Feb 2011 14:30:27 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296570627.87.0.702137059593.issue11089@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Tue Feb  1 16:23:43 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 01 Feb 2011 15:23:43 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>


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

Looks like some unittest doc changes got incorrectly backported to Python 3.1.

For example the command line features using -m are new in 3.2 and don't work with 3.1:

http://docs.python.org/py3k/library/unittest.html#command-line-interface

----------
assignee: michael.foord
components: Documentation
messages: 127703
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Doc errors for unittest in Python 3.1
versions: Python 3.1

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

From report at bugs.python.org  Tue Feb  1 16:48:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Feb 2011 15:48:38 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296575318.39.0.0127708218351.issue11071@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Feb  1 18:05:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Feb 2011 17:05:48 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1296579948.67.0.491569029977.issue11049@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Feb  1 18:41:09 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCn0YPQv9GA0LDQutC+0LI=?=)
Date: Tue, 01 Feb 2011 17:41:09 +0000
Subject: [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>


New submission from ?????? ???????? <sergeyzsg at gmail.com>:

import pkg_resources change path of already imported module
this break google appengine because It use "google.__file__" to determine sdk directory.

Ubuntu 10.10
~/lib/google_appengine$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from appcfg import fix_sys_path
>>> fix_sys_path()
>>> import google
>>> google
<module 'google' from '/home/schuprakov/lib/google_appengine/google/__init__.pyc'>
>>> import pkg_resources
>>> google
<module 'google' from '/usr/lib/pymodules/python2.6/google/__init__.pyc'>
>>> 


ls /usr/lib/pymodules/python2.6/google/
__init__.py  __init__.pyc  protobuf

----------
messages: 127704
nosy: ??????.????????
priority: normal
severity: normal
status: open
title: Bug with reimport in pkg_resources
type: resource usage

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

From report at bugs.python.org  Tue Feb  1 18:41:36 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCn0YPQv9GA0LDQutC+0LI=?=)
Date: Tue, 01 Feb 2011 17:41:36 +0000
Subject: [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296582096.12.0.939687430025.issue11091@psf.upfronthosting.co.za>


Changes by ?????? ???????? <sergeyzsg at gmail.com>:


----------
components: +Build
versions: +Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Feb  1 18:41:52 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCn0YPQv9GA0LDQutC+0LI=?=)
Date: Tue, 01 Feb 2011 17:41:52 +0000
Subject: [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296582112.69.0.973967490524.issue11091@psf.upfronthosting.co.za>


Changes by ?????? ???????? <sergeyzsg at gmail.com>:


----------
components:  -Build

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

From report at bugs.python.org  Tue Feb  1 18:42:05 2011
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCn0YPQv9GA0LDQutC+0LI=?=)
Date: Tue, 01 Feb 2011 17:42:05 +0000
Subject: [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296582125.07.0.996939090717.issue11091@psf.upfronthosting.co.za>


Changes by ?????? ???????? <sergeyzsg at gmail.com>:


----------
components: +Library (Lib)

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

From report at bugs.python.org  Tue Feb  1 18:42:36 2011
From: report at bugs.python.org (Julien Miotte)
Date: Tue, 01 Feb 2011 17:42:36 +0000
Subject: [issue11092] Setup.cfg isn't packaged when running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>


New submission from Julien Miotte <miotte.julien at gmail.com>:

Operating System: Ubuntu Maverick
Version of Python: 2.6.6
Version of Distutils2: d355f123ac79

How to reproduce: Create a project bato with a setup.cfg, like this: 
[metadata]
name = bato
version = 1.0

Run:
$ python -m distutils2.run sdist
$ tar tf dist/bato-1.0.tar.gz

What happens: The archive doesn't contain the setup.cfg file.

----------
assignee: tarek
components: Distutils2
messages: 127705
nosy: Julien.Miotte, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Setup.cfg isn't packaged when running sdist
versions: 3rd party

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

From report at bugs.python.org  Tue Feb  1 19:39:45 2011
From: report at bugs.python.org (Thijs Triemstra)
Date: Tue, 01 Feb 2011 18:39:45 +0000
Subject: [issue4833] Explicit directories for zipfiles
In-Reply-To: <1231088968.72.0.101458538333.issue4833@psf.upfronthosting.co.za>
Message-ID: <1296585585.11.0.119582666165.issue4833@psf.upfronthosting.co.za>


Changes by Thijs Triemstra <lists at collab.nl>:


----------
nosy: +thijs

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

From report at bugs.python.org  Tue Feb  1 20:08:04 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 01 Feb 2011 19:08:04 +0000
Subject: [issue11093] test_future - rename not-unittest files to redure
	regrtest.NOTTESTS an empty set
In-Reply-To: <1296587284.84.0.269223815277.issue11093@psf.upfronthosting.co.za>
Message-ID: <1296587284.84.0.269223815277.issue11093@psf.upfronthosting.co.za>


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

Hi,
following up with issue10848, here's another preparatory step:

- renamed test_future[12].py to future_test[12].py, to clearly identify the as not unittest files (and so facilitate the autodiscovery introduction)
- adapted test_future.py for the filename change
- at last, make NOTTESTS and empty set.

I tested that both test_future only and the whole test suite are all ok.

Let me know if you need anything more or done different :) (f.e.: David, do you want the documentation bits in issue11031 added here instead?) 

Cheers,
Sandro

----------
assignee: sandro.tosi
components: Tests
files: test_future.patch
keywords: patch
messages: 127706
nosy: r.david.murray, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: test_future - rename not-unittest files to redure regrtest.NOTTESTS an empty set
versions: Python 3.3
Added file: http://bugs.python.org/file20641/test_future.patch

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

From report at bugs.python.org  Tue Feb  1 20:08:20 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 01 Feb 2011 19:08:20 +0000
Subject: [issue11093] test_future - rename not-unittest files to make
	regrtest.NOTTESTS an empty set
In-Reply-To: <1296587284.84.0.269223815277.issue11093@psf.upfronthosting.co.za>
Message-ID: <1296587300.62.0.174614204548.issue11093@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
title: test_future - rename not-unittest files to redure regrtest.NOTTESTS an empty set -> test_future - rename not-unittest files to make regrtest.NOTTESTS an empty set

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

From report at bugs.python.org  Tue Feb  1 21:41:20 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Feb 2011 20:41:20 +0000
Subject: [issue11091] Bug with reimport in pkg_resources
In-Reply-To: <1296582069.56.0.625314817916.issue11091@psf.upfronthosting.co.za>
Message-ID: <1296592880.0.0.156797869333.issue11091@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

pkg_resources is not from Python but setuptools; you probably installed it and forgot it was there. I would suggest you do your App Engine development using virtualenv to make sure that you are working in a clean environment.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Feb  1 21:43:06 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Feb 2011 20:43:06 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296592986.41.0.723830117318.issue11085@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Importlib puts all of its ABCs in importlib.abc, so at least one package has already taken this approach.

I for one support the collections.abc idea.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Feb  1 23:02:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Feb 2011 22:02:59 +0000
Subject: [issue11092] Setup.cfg isn't packaged when running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <1296597779.09.0.847408588488.issue11092@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You can add it to MANIFEST.in.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Feb  1 23:07:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 01 Feb 2011 22:07:07 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296598027.64.0.313674385276.issue11089@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

If OrderedDict is used, the test case quickly uses 8GB of memory. With
this change (I'm not suggesting this as a fix!), the timings are normal:


Index: Lib/ConfigParser.py
===================================================================
--- Lib/ConfigParser.py (revision 88298)
+++ Lib/ConfigParser.py (working copy)
@@ -92,6 +92,7 @@
 except ImportError:
     # fallback for setup.py which hasn't yet built _collections
     _default_dict = dict
+_default_dict = dict
 
 import re

----------
nosy: +skrah

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

From report at bugs.python.org  Tue Feb  1 23:33:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Feb 2011 22:33:25 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296599605.16.0.195872973396.issue11089@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb  2 02:46:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 01:46:45 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296611205.34.0.531309667501.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Commenting-out the ``c.set(section,"item#%d"%(i),str(i))`` calls shows that that is not where the problem lies for the ConfigParser() class.
The issue seems confined to ConfigParser.get().

The  RawConfigParser() class doesn't seem to have the same issue.

Looking at the 2.7 code for ConfigParser.get() shows that it is doing a lot more than just getting.  For example, it does a full copy of defaults dictionary on every call !?

I'll look at it more shortly.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Feb  2 00:57:25 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 01 Feb 2011 23:57:25 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1296604645.17.0.126840786823.issue10918@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Sorry for taking so long to reply - I was on holidays until today.

This is an incompatible API change (since people may be providing "fn" by keyword) so we should probably hold off until 3.3.

I also don't really like that the signature for submit will become less readable. And the fix is pretty trivial i.e. functools.partial.

So really I'm -0 on this. But if anyone cares enough, I'll happily review and apply patches that change the submit signature to the one that Adrian proposed.

def sugar(*args, **kw):
    return args[0].submit(args[1], args[2:], kw)

----------
resolution: wont fix -> accepted
status: closed -> open

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

From report at bugs.python.org  Wed Feb  2 00:16:24 2011
From: report at bugs.python.org (Yelena)
Date: Tue, 01 Feb 2011 23:16:24 +0000
Subject: [issue11094] Runtime error
In-Reply-To: <1296602184.41.0.81665541642.issue11094@psf.upfronthosting.co.za>
Message-ID: <1296602184.41.0.81665541642.issue11094@psf.upfronthosting.co.za>


New submission from Yelena <kowu at ucdavis.edu>:

I've been using python to run some large database recently. 
I used dbfpy module to access some information stored in dbf format.
However, after 20hrs of running it gave me an error of :
Runtime Error!
This application has requested the Runtime to terminate it in an unusual way.Please contact the application's support team for more information.

The error popped out every time I ran them after 20 hrs. My prediction was that
it ran over its memory usage, since it has been accumulating the memory usage
when I was running the program. So I tried deleting/closing I/O immediately
after they were processed. However, such changes did not make any difference
in memory usage accumulation.

Could you please give me some advice in fixing problems like this?

Thank you.

----------
components: Windows
files: test2
messages: 127711
nosy: yelenawu
priority: normal
severity: normal
status: open
title: Runtime error
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file20642/test2

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

From report at bugs.python.org  Wed Feb  2 03:28:41 2011
From: report at bugs.python.org (kai zhu)
Date: Wed, 02 Feb 2011 02:28:41 +0000
Subject: [issue11095] subprocess popen broken for bytes and backslash
In-Reply-To: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>
Message-ID: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu at ugcs.caltech.edu>:

noticed when trying to call grep w/ backslashes in regexp, in shell mode.
same behavior on python2.5 & python3.2

in shell mode:
1. bytes is broken
2. 1st character after backslash is always silently truncated (with exception of '\\')

$ python3.2
Python 3.2rc1+ (py3k, Jan 24 2011, 15:00:02) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call(b'echo aa', shell = True) ## bytes broken
Traceback (most recent call last):
  File "<pseudosugar console>", line 1, in <module>
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 460, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 736, in __init__
    restore_signals, start_new_session)
  File "/home/public/i486-pc-linux-gnu/lib/python3.2/subprocess.py", line 1175, in _execute_child
    restore_signals, start_new_session, preexec_fn)
TypeError: Can't convert 'int' object to str implicitly
>>> subprocess.call('echo \aa', shell = True) ## backslash \
a
0
>>> subprocess.call('echo \\aa', shell = True) ## backslash \\
aa
0
>>> subprocess.call('echo \\\aa', shell = True) ## backslash \\\
a
0
>>> subprocess.call('echo \\\\aa', shell = True) ## backslash \\\\
a
0
>>> subprocess.call('echo \\\\\aa', shell = True) ## backslash \\\\\
\a
0
>>> subprocess.call('echo \\\\\\aa', shell = True) ## backslash \\\\\\
a
0
>>> subprocess.call('echo \\\\\\\\\\\\\\\\\\\\\\\\\aa', shell = True)
\\\a
0

----------
messages: 127714
nosy: kaizhu
priority: normal
severity: normal
status: open
title: subprocess popen broken for bytes and backslash
type: behavior
versions: Python 2.5, Python 3.2

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

From report at bugs.python.org  Wed Feb  2 03:30:32 2011
From: report at bugs.python.org (kai zhu)
Date: Wed, 02 Feb 2011 02:30:32 +0000
Subject: [issue11095] subprocess popen broken for bytes and backslash
In-Reply-To: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>
Message-ID: <1296613832.86.0.683451678998.issue11095@psf.upfronthosting.co.za>


Changes by kai zhu <kaizhu at ugcs.caltech.edu>:


----------
components: +IO, Library (Lib)

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

From report at bugs.python.org  Wed Feb  2 03:43:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 02:43:22 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296614602.54.0.0455158123219.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching a patch that fixes the algorithmic atrocities by using the Chainmap recipe:

  http://code.activestate.com/recipes/305268-chained-map-lookups

----------
keywords: +patch
Added file: http://bugs.python.org/file20643/configparser.patch

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

From report at bugs.python.org  Wed Feb  2 04:38:35 2011
From: report at bugs.python.org (Alex McNerney)
Date: Wed, 02 Feb 2011 03:38:35 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296617915.88.0.605933805176.issue11075@psf.upfronthosting.co.za>


Alex McNerney <amcnerney13 at yahoo.com> added the comment:

Thank you so much for pointing out the -n option!
Hopefully the Tk 8.5.9 input issue will be solved soon enough.
Thank you both again.
I'm not sure if I'm supposed to or not, but I am marking this as closed ? seeing as the main issue has been solved.

----------
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 04:39:35 2011
From: report at bugs.python.org (Alex McNerney)
Date: Wed, 02 Feb 2011 03:39:35 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296617975.3.0.548983963549.issue11075@psf.upfronthosting.co.za>


Alex McNerney <amcnerney13 at yahoo.com> added the comment:

solved* or rather, a workaround has been found.

----------

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

From report at bugs.python.org  Wed Feb  2 06:02:45 2011
From: report at bugs.python.org (Alex McNerney)
Date: Wed, 02 Feb 2011 05:02:45 +0000
Subject: [issue11096] Multiple turtle tracers
In-Reply-To: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>
Message-ID: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>


New submission from Alex McNerney <amcnerney13 at yahoo.com>:

In Python 2.7 and 2.6 (only ones I have tried), there is a bug in the turtle module's tracer() function, when applying it to multiple turtles using the same value.

When two turtles are defined (to draw simultaneously), and both turtles' tracers are set to the same number, one of the turtles does not end up following its tracer value. (It's a little hard to explain...look at/try the sample code)

The following script will recreate this glitch:
"
from turtle import *

t1 = Turtle()
t2 = Turtle()

for t in turtles():
    t.ht()
    t.speed(0)
    t.tracer(10)

t1.color("black")
t2.color("red")

for x in range(500):
    t1.forward(x)
    t2.forward(x)
    t1.left(144.5)
    t2.right(144.5)
"

----------
messages: 127718
nosy: amcnerney13
priority: normal
severity: normal
status: open
title: Multiple turtle tracers
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Feb  2 08:40:13 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Feb 2011 07:40:13 +0000
Subject: [issue11075] Using Turtle with IDLE on Mac OS X
In-Reply-To: <1296451592.7.0.220170284749.issue11075@psf.upfronthosting.co.za>
Message-ID: <1296632413.47.0.815255165459.issue11075@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily
resolution:  -> works for me
stage:  -> committed/rejected

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

From report at bugs.python.org  Wed Feb  2 09:12:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 08:12:00 +0000
Subject: [issue11087] Speeding up the interpreter with a few lines of code
In-Reply-To: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>
Message-ID: <1296634320.35.0.546065313035.issue11087@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> pitrou
nosy: +pitrou

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

From report at bugs.python.org  Wed Feb  2 09:12:03 2011
From: report at bugs.python.org (Alex McNerney)
Date: Wed, 02 Feb 2011 08:12:03 +0000
Subject: [issue11096] Multiple turtle tracers
In-Reply-To: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>
Message-ID: <1296634323.88.0.58647992257.issue11096@psf.upfronthosting.co.za>


Alex McNerney <amcnerney13 at yahoo.com> added the comment:

To be more clear, in the sample code, the drawing animation of the red star-spiral is smooth, whereas the drawing animation of the black star-spiral is spasmodic.

----------

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

From report at bugs.python.org  Wed Feb  2 09:14:32 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 02 Feb 2011 08:14:32 +0000
Subject: [issue11097] MSI: Remove win32com dependency from installer generator
In-Reply-To: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>
Message-ID: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>


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

The MSI installer is generated using msilib.py from http://svn.python.org/projects/python/branches/release27-maint/Tools/msi that is dependent from external win32com module. We also have internal 'msilib' module that is unused for some reason.

Is it possible to incrementally transition from Tools/msilib.py to builtin 'msilib'?

See http://codereview.appspot.com/4080047/ for the start of the thread.

----------
components: Installation
messages: 127720
nosy: loewis, techtonik
priority: normal
severity: normal
status: open
title: MSI: Remove win32com dependency from installer generator
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  2 09:15:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 08:15:53 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296634553.62.0.397263848592.issue11085@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And what about those "collection" ABCs that aren't collections?  These are at least

* Hashable
* Callable
* ByteString
* Iterator

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Wed Feb  2 09:16:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 08:16:29 +0000
Subject: [issue10918] **kwargs unnecessarily restricted in concurrent.futures
	'submit' API
In-Reply-To: <1295192992.12.0.880697566702.issue10918@psf.upfronthosting.co.za>
Message-ID: <1296634589.64.0.762011898179.issue10918@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sure, a change to 3.2 is out of the question anyway right now.

----------

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

From report at bugs.python.org  Wed Feb  2 09:19:51 2011
From: report at bugs.python.org (Eric Smith)
Date: Wed, 02 Feb 2011 08:19:51 +0000
Subject: [issue11095] subprocess popen broken for bytes and backslash
In-Reply-To: <1296613721.25.0.259420075945.issue11095@psf.upfronthosting.co.za>
Message-ID: <1296634791.09.0.235254595972.issue11095@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

1: subprocess.call is documented as taking a string, not bytes. If you think it should also take bytes, I suggest opening a separate bug as a feature request.

2: You're running into both Python and the shell escaping. If you have an odd number of backslashes, then python is converting '\a' into an ascii BEL character:
http://docs.python.org/py3k/reference/lexical_analysis.html#string-literals
For the remaining backslashes, Python is converting every 2 into a single backslash when it does its escaping, and the shell is doing the same thing, as is echo. That accounts for 8 backslashes becoming a single backslash in the output.

----------
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 09:23:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 08:23:33 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296635013.63.0.517211019164.issue11085@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> And what about those "collection" ABCs that aren't collections?

<shrug> Guido originally thought all these should live together and I don't see much of a win in separating them from the other.

----------

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

From report at bugs.python.org  Wed Feb  2 09:36:26 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 08:36:26 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296635786.4.0.46974786955.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Senthil, could this be a regression of the recent urllib transfer-encoding changes?

----------
assignee:  -> orsenthil
nosy: +georg.brandl, orsenthil
priority: normal -> deferred blocker

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

From report at bugs.python.org  Wed Feb  2 09:39:48 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 08:39:48 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296635988.25.0.402192175529.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed for 2.7 in r88318.  Will make a similar fix for 3.1.4 and for 3.2.1.

----------
assignee: lukasz.langa -> rhettinger
versions:  -Python 2.7

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

From report at bugs.python.org  Wed Feb  2 09:58:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 08:58:49 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296637129.65.0.786752104807.issue11067@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The fast subtype checks cannot be supported in the limited API, as the layout of type objects is intentionally not exposed. It would be possible to expose a getter for the type flags; the individual flag values *are* part of the ABI.

I propose the attached patch, which replaces the fast subtype check with a slow one in the limited API. The patch would need to be extended to all subtype checks.

It's not strictly necessary to include this patch into the 3.2 release; users could also explicitly call PyObject_IsSubclass as a work-around. The patch could then be added for 3.2.1.

As another work-around, users can also use PyUnicode_CheckExact, which is even faster and might be correct in many cases as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file20644/unisub.diff

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

From report at bugs.python.org  Wed Feb  2 10:13:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Feb 2011 09:13:34 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296635786.4.0.46974786955.issue11082@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=j_f9uryuvb=oNC_xhx4zFNC_LLJxxC0sWLV4N@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The POST data should be bytes. So in the attached test case, instead of

request = urllib.request.Request('http://does.not.matter', 'foo=bar')

it should be:

request = urllib.request.Request('http://does.not.matter', b'foo=bar')

And the Content-Length will be calculated using this logic.

mv = memoryview(data)
Content-length = len(mv) * mv.itemsize

Should we emphasize further that data should be bytes? I think error
message can be improved here.  This issue is not a blocker.

----------

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

From report at bugs.python.org  Wed Feb  2 10:21:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 09:21:54 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296638514.41.0.462941152961.issue11067@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file20644/unisub.diff

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

From report at bugs.python.org  Wed Feb  2 10:22:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 09:22:05 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296638525.64.0.34459966375.issue11067@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file20645/unisub.diff

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

From report at bugs.python.org  Wed Feb  2 10:30:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 09:30:04 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296639004.54.0.0315401931195.issue11067@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file20645/unisub.diff

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

From report at bugs.python.org  Wed Feb  2 10:31:03 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 09:31:03 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296639063.59.0.890463663337.issue11067@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Reconsidering: it's better to use PyType_IsSubtype, as this matches better the fast check.

----------
Added file: http://bugs.python.org/file20646/unisub.diff

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

From report at bugs.python.org  Wed Feb  2 10:47:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Feb 2011 09:47:27 +0000
Subject: [issue11094] Runtime error
In-Reply-To: <1296602184.41.0.81665541642.issue11094@psf.upfronthosting.co.za>
Message-ID: <1296640047.75.0.0704742571798.issue11094@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For this kind of question you'd better ask on the comp.lang.python newsgroup. The bug tracker is not designed to get help.

A remark though: to really debug the RuntimeError a C debugger is needed (and a debug build of Python). You'd better try to know why your script consumes more and more memory. There are certainly tools for this, and people on the python newsgroup will be happy to share them with you.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 11:42:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2011 10:42:31 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296643351.02.0.697901709419.issue11082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since r70638, the http client encodes unicode to ISO-8859-1:
<< RFC 2616 says that iso-8859-1 is the default charset for HTTP entity
bodies, but we encoded strings using ascii.  See
http://bugs.python.org/issue5314.  Changed docs and code to use
iso-8859-1. >>

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Feb  2 12:18:55 2011
From: report at bugs.python.org (Alexey Luchko)
Date: Wed, 02 Feb 2011 11:18:55 +0000
Subject: [issue11098] syntax error at end of line in interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>


New submission from Alexey Luchko <luch at ank-sia.com>:

Interactive python -u produces syntax error in win2k:
> python -u
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
  File "<stdin>", line 1
    1+1
       ^
SyntaxError: invalid syntax
>>> import sys
  File "<stdin>", line 1
    import sys
              ^
SyntaxError: invalid syntax
>>>

Tried Python 2.5.4, 2.7.1 and 3.1.2 on the same win2k machine.

The problem does not exist under mac os x 10.5 and freebsd 8.1.

----------
components: Windows
messages: 127732
nosy: luch
priority: normal
severity: normal
status: open
title: syntax error at end of line in interactive python -u
versions: Python 2.5, Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  2 14:19:06 2011
From: report at bugs.python.org (lekma)
Date: Wed, 02 Feb 2011 13:19:06 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1296652746.28.0.348338266255.issue10271@psf.upfronthosting.co.za>


Changes by lekma <lekmalek at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20647/Issue10271.diff

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

From report at bugs.python.org  Wed Feb  2 15:50:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Feb 2011 14:50:49 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296658249.33.0.261971161238.issue10227@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Any benchmark numbers for the slice cache?
Also, is the call to PyObject_INIT necessary?

----------

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

From report at bugs.python.org  Wed Feb  2 16:12:29 2011
From: report at bugs.python.org (Virgil Dupras)
Date: Wed, 02 Feb 2011 15:12:29 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296659549.38.0.328304884387.issue11076@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

I went ahead and created a patch (with test and doc) making argparse.Namespace iterable.

----------
keywords: +patch -easy
Added file: http://bugs.python.org/file20648/issue11076.diff

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

From report at bugs.python.org  Wed Feb  2 16:31:29 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 02 Feb 2011 15:31:29 +0000
Subject: [issue11099] Bytes pickled with 3.1 not unpickled with 2.7 correctly
In-Reply-To: <1296660689.12.0.256726786227.issue11099@psf.upfronthosting.co.za>
Message-ID: <1296660689.12.0.256726786227.issue11099@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jharper at yapdc.com>:

When a bytes object is pickled with 3.1 and then unpickled with 2.7, the results are incorrect.  The example below shows that pickling 
b'abcdefg' in 3.1 and then unpickling in 2.7 produces the string
'[97L, 98L, 99L, 100L, 101L, 102L, 103L]'

The unpickling operation should return 'abcdefg'.

C:\decompyle\jtest>c:\Python31\python
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> file = open('test.pkl', 'wb')
>>> import pickle
>>> pickle.dump(b'abcdefg', file, 0)
>>> exit()

C:\decompyle\jtest>c:\python27\python
Python 2.7 Stackless 3.1b3 060516 (release27-maint, Jul 22 2010, 18:58:18) [MSC
v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> file = open('test.pkl', 'rb')
>>> import pickle
>>> pickle.load(file)
'[97L, 98L, 99L, 100L, 101L, 102L, 103L]'
>>>

----------
components: Library (Lib), Unicode
messages: 127735
nosy: jdharper
priority: normal
severity: normal
status: open
title: Bytes pickled with 3.1 not unpickled with 2.7 correctly
versions: Python 2.7, Python 3.1

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

From report at bugs.python.org  Wed Feb  2 16:42:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 15:42:01 +0000
Subject: [issue11098] syntax error at end of line in interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296661321.97.0.77930520851.issue11098@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is fixed in py3k rc2, and thus will be fixed in 3.2.  The trick will be figuring out which update fixed it, to see if we can backport to 3.1 and 2.7.  Since issue 10841 touched stdio handling in Windows, I suspect that may be the source, so I'm adding Victor and Antoine to nosy since they worked that issue.

On the other hand, given how long this issue has existed without anybody running in to it, it may not even be worth backporting....what's your use case for starting the interactive interpreter with -u?

----------
nosy: +haypo, pitrou, r.david.murray
type:  -> behavior
versions:  -Python 2.5

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

From report at bugs.python.org  Wed Feb  2 16:47:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 15:47:48 +0000
Subject: [issue11099] Bytes pickled with 3.1 not unpickled with 2.7 correctly
In-Reply-To: <1296660689.12.0.256726786227.issue11099@psf.upfronthosting.co.za>
Message-ID: <1296661668.87.0.159605808052.issue11099@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duplicate of issue 6784.  (If you disagree explain why here, please.)

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> byte/unicode pickle incompatibilities between python2 and python3
type:  -> behavior

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

From report at bugs.python.org  Wed Feb  2 16:48:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 15:48:15 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1296661695.19.0.116833333362.issue6784@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +jdharper

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

From report at bugs.python.org  Wed Feb  2 17:05:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2011 16:05:47 +0000
Subject: [issue11098] syntax error at end of line in interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296662747.77.0.975316144289.issue11098@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since r7409 (14 years ago), Python does set the binary binary mode on stdin and stdout (not stderr) if the -u flag is used:
----
    if (unbuffered) {
#if defined(MS_WINDOWS) || defined(__CYGWIN__)
        _setmode(fileno(stdin), O_BINARY);
        _setmode(fileno(stdout), O_BINARY);
#endif
#ifdef HAVE_SETVBUF
        setvbuf(stdin,  (char *)NULL, _IONBF, BUFSIZ);
        setvbuf(stdout, (char *)NULL, _IONBF, BUFSIZ);
        setvbuf(stderr, (char *)NULL, _IONBF, BUFSIZ);
#else /* !HAVE_SETVBUF */
        setbuf(stdin,  (char *)NULL);
        setbuf(stdout, (char *)NULL);
        setbuf(stderr, (char *)NULL);
#endif /* !HAVE_SETVBUF */
    }
----

If you would like to check that the problem is related to the binary mode, you can set the binary mode manually without the -u flag. Add the following code at the end of your site.py file:
----
import msvcrt
msvcrt.setmode (0, os.O_BINARY) # stdin  = 0
msvcrt.setmode (1, os.O_BINARY) # stdout = 1
msvcrt.setmode (2, os.O_BINARY) # stderr = 2
----

Python 3.2 does always set the binary mode for all files (opened files but also stdin, stdout and stderr), which requires a fix in the parser because the parser didn't support Windows newlines (\r\n). See issue 10841 and the commit r87824 for more information.

----------

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

From report at bugs.python.org  Wed Feb  2 17:08:44 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 16:08:44 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>
Message-ID: <1296662924.26.0.92491328286.issue11033@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This works in 3.x:

Python 3.2rc2+ (py3k:88279:88280, Feb  1 2011, 00:01:52)
..
>>> from xml.etree import ElementTree
>>> ElementTree.fromstring('<doc>?</doc>')
<Element 'doc' at 0x1007daa00>

In 2.x you need to encode unicode strings before passing them to ElementTree.fromstring().  For example:

----
# encoding: utf-8                                                                                                                                                      
from xml.etree import ElementTree
t = ElementTree.fromstring(u'<doc>?</doc>'.encode('utf-8'))
print t.text
----

This is not a bug because fromstring() unlike some other ElementTree methods is not documented to support unicode strings. Since 2.x is closed for new features, this has to be rejected.

----------
assignee:  -> belopolsky
nosy: +belopolsky
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending
type: crash -> feature request
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Wed Feb  2 17:10:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2011 16:10:52 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296173256.62.0.363094614198.issue11033@psf.upfronthosting.co.za>
Message-ID: <1296663052.55.0.662529837227.issue11033@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Since 2.x is closed for new features, this has to be rejected.

We can explain in ElementTree documentation how to pass non-ASCII unicode strings: using explicit encoding to UTF-8.

----------
nosy: +haypo
status: pending -> open

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

From report at bugs.python.org  Wed Feb  2 17:33:09 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 16:33:09 +0000
Subject: [issue11033] ElementTree.fromstring doesn't work with Unicode
In-Reply-To: <1296663052.55.0.662529837227.issue11033@psf.upfronthosting.co.za>
Message-ID: <AANLkTikmCD3iPPdxKNF0qSM0nm=BBHBter9v+pRuro80@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Feb 2, 2011 at 11:10 AM, STINNER Victor <report at bugs.python.org> wrote:
..
> We can explain in ElementTree documentation how to pass non-ASCII unicode strings: using
> explicit encoding to UTF-8.

ElementTree.fromstring() ultimately calls ElementTree.XMLParser.feed()
which is documented as follows:

"""
feed(data)
Feeds data to the parser. data is encoded data.
"""

Maybe we can simply add "encoded" to the description of
ElementTree.fromstring()  argument as well?

----------

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

From report at bugs.python.org  Wed Feb  2 17:41:59 2011
From: report at bugs.python.org (Erik Krauss)
Date: Wed, 02 Feb 2011 16:41:59 +0000
Subject: [issue11100] test_fdopen: close failed in file object destructor
In-Reply-To: <1296664919.37.0.123111264864.issue11100@psf.upfronthosting.co.za>
Message-ID: <1296664919.37.0.123111264864.issue11100@psf.upfronthosting.co.za>


New submission from Erik Krauss <erik.krauss at highmark.com>:

test_fdopen (in test_os) fails on Solaris 9/sparc with Python 2.7.1.

FAIL: test_fdopen (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/p01/app/tenv6/mercator/tmp_pythonbuild/Python-2.7.1/Lib/test/test_os.py", line 550, in helper
    self.check(getattr(os, f))
  File "/p01/app/tenv6/mercator/tmp_pythonbuild/Python-2.7.1/Lib/test/test_os.py", line 562, in check
    % f)
AssertionError: <built-in function fdopen> didn't raise a OSError with a bad file descriptor

----------
components: Tests
files: test_os_failure.txt
messages: 127743
nosy: ekrauss
priority: normal
severity: normal
status: open
title: test_fdopen: close failed in file object destructor
versions: Python 2.7
Added file: http://bugs.python.org/file20649/test_os_failure.txt

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

From report at bugs.python.org  Wed Feb  2 18:08:19 2011
From: report at bugs.python.org (William Wu)
Date: Wed, 02 Feb 2011 17:08:19 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296666499.37.0.0569557531053.issue11082@psf.upfronthosting.co.za>


William Wu <willie.tw at gmail.com> added the comment:

If the POST data should be bytes which I also think reasonable,

should urllib.parse.urlencode return bytes instead of str?

>>> urllib.parse.urlencode({'foo': 'bar'})
'foo=bar'
>>> urllib.parse.urlencode({b'foo': b'bar'})
'foo=bar'

----------

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

From report at bugs.python.org  Wed Feb  2 19:00:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Feb 2011 18:00:40 +0000
Subject: [issue10979] setUpClass exception causes explosion with "-b"
In-Reply-To: <1295669611.84.0.453494131357.issue10979@psf.upfronthosting.co.za>
Message-ID: <1296669640.58.0.409562234285.issue10979@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Feb  2 19:11:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 18:11:32 +0000
Subject: [issue1103350] send/recv SEGMENT_SIZE should be used more in
	socketmodule
Message-ID: <1296670292.91.0.304867417979.issue1103350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like this was closed due to lack of appropriate people reviewing it, rather than because such a review was done.

----------
nosy: +brian.curtin, r.david.murray, tim.golden
resolution: out of date -> 
status: closed -> open
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Wed Feb  2 19:11:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 18:11:46 +0000
Subject: [issue1103350] send/recv SEGMENT_SIZE should be used more in
	socketmodule
Message-ID: <1296670306.48.0.250045248298.issue1103350@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Wed Feb  2 19:48:35 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 02 Feb 2011 18:48:35 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296672515.45.0.746065091536.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

> Any benchmark numbers for the slice cache?

I ran the list tests in pybench and got this:

Test               minimum run-time        average  run-time
                    this    other   diff    this    other   diff
--------------------------------------------------------------------
    ListSlicing:    66ms    67ms   -2.2%    67ms    68ms   -2.7%
     SmallLists:    61ms    64ms   -4.5%    61ms    65ms   -5.6%
--------------------------------------------------------------------
Totals:           127ms   131ms   -3.3%   128ms   133ms   -4.1%

Repeating this gave me anything between 1.5% and 3.5% in total, with >2% for the small lists benchmark (which is the expected best case as slicing large lists obviously dominates the slice object creation).

IMHO, even 2% would be pretty good for such a small change.


> Also, is the call to PyObject_INIT necessary?

In any case, the ref-count needs to be re-initialised to 1. A call to _Py_NewReference() would be enough, though, following the example in listobject.c. So you can replace

         PyObject_INIT(obj, &PySlice_Type);

by

         _Py_NewReference((PyObject *)obj);

in the patch. New patch attached.

----------
Added file: http://bugs.python.org/file20650/slice-object-cache.patch

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

From report at bugs.python.org  Wed Feb  2 19:54:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Feb 2011 18:54:17 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1296672515.45.0.746065091536.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296672852.3718.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I ran the list tests in pybench and got this:
> 
> Test               minimum run-time        average  run-time
>                     this    other   diff    this    other   diff
> --------------------------------------------------------------------
>     ListSlicing:    66ms    67ms   -2.2%    67ms    68ms   -2.7%
>      SmallLists:    61ms    64ms   -4.5%    61ms    65ms   -5.6%
> --------------------------------------------------------------------
> Totals:           127ms   131ms   -3.3%   128ms   133ms   -4.1%
> 
> Repeating this gave me anything between 1.5% and 3.5% in total, with
> >2% for the small lists benchmark (which is the expected best case as
> slicing large lists obviously dominates the slice object creation).
> 
> IMHO, even 2% would be pretty good for such a small change.

Well, 3% on such micro-benchmarks (and, I assume, 0% on the rest) is
generally considered very small.
On the other hand, I agree the patch itself is quite simple.

> by
> 
>          _Py_NewReference((PyObject *)obj);
> 
> in the patch. New patch attached.

Don't you also need a _Py_ForgetReference() at the other end? Or have I
missed it?

----------

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

From report at bugs.python.org  Wed Feb  2 19:55:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 18:55:20 +0000
Subject: [issue2733] mmap resize fails on anonymous memory
In-Reply-To: <1209661457.64.0.989081565875.issue2733@psf.upfronthosting.co.za>
Message-ID: <1296672920.05.0.716064134261.issue2733@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't see an actual crash reported.  An unexpected exception is not a crash.  Changing the type to "behavior".

----------
nosy: +belopolsky
type: crash -> behavior

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

From report at bugs.python.org  Wed Feb  2 19:59:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 18:59:54 +0000
Subject: [issue10762] strftime('%f') segfault
In-Reply-To: <1293098262.29.0.661167233963.issue10762@psf.upfronthosting.co.za>
Message-ID: <1296673194.76.0.329799269857.issue10762@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Extension Modules, Windows -Library (Lib)

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

From report at bugs.python.org  Wed Feb  2 20:03:33 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 19:03:33 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1296673413.19.0.0969041908124.issue10365@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Unexpected exception is not a crash.  Changing the type to "behavior."

----------
nosy: +belopolsky
type: crash -> behavior

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

From report at bugs.python.org  Wed Feb  2 20:10:53 2011
From: report at bugs.python.org (Bob Van Zant)
Date: Wed, 02 Feb 2011 19:10:53 +0000
Subject: [issue11101] plistlib has no graceful way of handing None values
In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za>
Message-ID: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za>


New submission from Bob Van Zant <bob at veznat.com>:

The Apple plist format does not support None or Null values in its output. A Null value in plist is denoted by the absence of the key in the data structure.

The python plist writer generates a TypeError when a None value is encoded. This issue is to track dealing with None values.

A suggestion is to have a flag on the various plist write functions and methods that will allow ignoring None values.

No changes are required to the plist reader.

----------
components: Library (Lib)
files: plistlib.patch
keywords: patch
messages: 127750
nosy: bobveznat
priority: normal
severity: normal
status: open
title: plistlib has no graceful way of handing None values
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file20651/plistlib.patch

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

From report at bugs.python.org  Wed Feb  2 20:11:56 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 02 Feb 2011 19:11:56 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296673916.37.0.289594410375.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

There's a "PyObject_Del(obj)" in all code paths.

----------

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

From report at bugs.python.org  Wed Feb  2 20:21:06 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 19:21:06 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296674466.23.0.0656968435113.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That would seem correct to me.

----------

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

From report at bugs.python.org  Wed Feb  2 20:25:42 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 19:25:42 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296674742.92.0.28245688739.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is also a question whether to disallow str explicitly, instead of letting it go through the Iterable check.

----------

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

From report at bugs.python.org  Wed Feb  2 20:25:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 02 Feb 2011 19:25:47 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1296674747.03.0.753952944098.issue8797@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open
type: crash -> behavior

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

From report at bugs.python.org  Wed Feb  2 20:46:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 19:46:04 +0000
Subject: [issue4724] setting f_exc_traceback aborts in debug builds
In-Reply-To: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za>
Message-ID: <1296675964.53.0.729033742653.issue4724@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Not applicable to 3.x because the frame object does not have f_exc_traceback attribute anymore:

>>> import sys;sys._getframe(0).f_exc_traceback = 23
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'frame' object has no attribute 'f_exc_traceback'

The issue is present in 2.7 but appears to be rather benign.   It looks like the worst that can happen in non-debug build is a reference leak in set_exc_info().

I am not sure if this is worth fixing.  If this was affecting development version, I would argue that the simplest fix is to disallow setting f_exc_traceback or f_exc_value before f_exc_type is set.  In a bug-fix reliase, however this is probably not acceptable.

Given that sys._getframe() screams "beware, expert use only", I am not sure anything should be done other than possibly documenting that assigning to f_exc_* attributes of a transient frame object is not a good idea.

Note that the following works:

>>> f = sys._getframe(0)
>>> f.f_exc_traceback = 23

If there is a legitimate use for setting f_exc_traceback, the user should know to set f.f_exc_type and f.f_exc_value as well.

----------
nosy: +belopolsky -BreamoreBoy
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb  2 20:56:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2011 19:56:35 +0000
Subject: [issue4391] use proper gettext plurals forms in argparse and optparse
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1296676595.09.0.140727201186.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks like this will have to wait for 3.3, unfortunately.

----------
keywords: +needs review
stage:  -> patch review
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Wed Feb  2 20:56:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 02 Feb 2011 19:56:40 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1296676600.36.0.416871696439.issue6465@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I was looking at this bug and tried to reproduce it, but I can't :( I extracted this code:


part1 = 'Content-Type: multipart/related; start=<op.mhtml.1247227666422.e6e72d4c344a2503 at 192.168.1.20>; boundary=----------1JBOHhxKNnWgkmE17ZJ2Cy\r\nContent-Location: http://localhost/page1.html\r\nSubject: =?utf-8?Q?test?=\r\nMIME-Version: 1.0\r\n\r\n------------1JBOHhxKNnWgkmE17ZJ2Cy\r'
part2 = '\nContent-Disposition: inline; filename=page1.html\r\nContent-Type: text/html; charset=UTF-8; name=page1.html\r\nContent-Id: <op.mhtml.1247227666422.e6e72d4c344a2503 at 192.168.1.20>\r\nContent-Location: http://localhost/page1.html\r\nContent-Transfer-Encoding: 8bit\r\n\r\n<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\r\n<html><head><title>Page 1</title></head><body><p>page 1</p></body></html>\r\n------------1JBOHhxKNnWgkmE17ZJ2Cy--\r\n'
expected = '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\r\n<html><head><title>Page 1</title></head><body><p>page 1</p></body></html>'
from email.feedparser import FeedParser
feedparser = FeedParser()
feedparser.feed(part1)
feedparser.feed(part2)
m = feedparser.close()
mm = m.get_payload()
mm[0].get_payload() == expected

from the test attached to this bug, and tried on:

* py3k
* release3.1-maint
* release2.7-maint
* debian 2.6.6

(the first 3 recompiled just before the test) and in all of the cases the last instruction returns True, so I'm actually quite skeptical this is still a bug, or there something I'm missing.

I'm not closing this bug yet, since I'd like to hear first from the people involved back then.

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Wed Feb  2 21:05:30 2011
From: report at bugs.python.org (Oren Held)
Date: Wed, 02 Feb 2011 20:05:30 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>


New submission from Oren Held <oren at held.org.il>:

The effect eventually is that on HP-UX v3 there are no os.major() and os.minor() functions.

I tried to dig deeper to find out what's wrong, and it seems that 'configure' script fails on 'major' check and thus disables the 'major' feature:

'configure' finds well that /usr/include/sys/sysmacros.h has makedev(), major(), minor() definitions (MAJOR_IN_SYSMACROS==1).

The problem is that including sys/sysmacros.h is not enough, it depends (but doesn't #include) sys/types.h for the definition of dev_t (needed by makedev() macro).


See attached config.log for configure's behavior.

----------
components: Build
files: config.log
messages: 127757
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: configure doesn't find "major()" on HP-UX v11.31
versions: Python 2.7
Added file: http://bugs.python.org/file20652/config.log

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

From report at bugs.python.org  Wed Feb  2 21:28:47 2011
From: report at bugs.python.org (Oren Held)
Date: Wed, 02 Feb 2011 20:28:47 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1296678527.78.0.73680277706.issue11102@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

Attaching a patch I've made for fixing the problem in HP-UX, simply by #including sys/types.h on the configure test..

1. I'm not sure it'll be good for all platforms; maybe we need more 'configure' magic here to make it #include <sys/types.h> on this configure test only when needed (e.g. HP-UX v3).

2. Once 'configure' decides to enable the "os.major" feature, 'make' simply compiles it well - I didn't have to fix things in Modules/posixmodule.c (apparently sys/types.h is already loaded). I'm not sure it's smart to count on it.

----------
keywords: +patch
Added file: http://bugs.python.org/file20653/python-configure-hpux-major-fix.patch

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

From report at bugs.python.org  Wed Feb  2 21:34:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 02 Feb 2011 20:34:05 +0000
Subject: [issue11092] Setup.cfg isn't packaged when running sdist
In-Reply-To: <1296582156.21.0.82325099923.issue11092@psf.upfronthosting.co.za>
Message-ID: <1296678845.91.0.855798615311.issue11092@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No, because setup.cfg should always be included.  That?s a real bug.  In distutils1, test/*.py and README[.txt] were also included; the commit that changed that (374f93ab103c) introduced this bug:

-        optional = ['test/test*.py', 'setup.cfg']
-        for pattern in optional:
-            files = filter(os.path.isfile, glob(pattern))
-            if files:
-                self.filelist.extend(files)

I think setup.cfg should always be included if it exists; I?m not sure about setup.py, you may want to ask on the ML.

----------
nosy: +gotcha

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

From report at bugs.python.org  Wed Feb  2 22:01:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 02 Feb 2011 21:01:55 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1296680515.91.0.656718861641.issue11102@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

AFAICT, including sys/types.h by default in the test should be fine. It's a standard header file (atleast for Posixish systems), so it should always be present, and including it shouldn't cause harm even if it's not needed.

----------
nosy: +loewis

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

From report at bugs.python.org  Wed Feb  2 22:02:37 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 02 Feb 2011 21:02:37 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1296680557.06.0.42565232703.issue6818@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Wed Feb  2 22:02:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 02 Feb 2011 21:02:50 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1296680570.36.0.670043943545.issue6818@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
keywords:  -patch

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

From report at bugs.python.org  Wed Feb  2 22:19:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 21:19:07 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296681547.17.0.664643584086.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching patch for Python 3.2.

Georg, I was think of waiting for 3.2.1 for this one, but it can go into 3.2.0 RC2 if you prefer.

----------
assignee: rhettinger -> georg.brandl
nosy: +georg.brandl
Added file: http://bugs.python.org/file20654/configparser.patch

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

From report at bugs.python.org  Wed Feb  2 22:23:01 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 21:23:01 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1296681781.68.0.185211338239.issue6501@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The issue is not Windows specific, so I am changing the title to reflect that.   On OSX, for example, I get

$ PYTHONIOENCODING=xyz ./python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: xyz
Abort trap

I agree that abort() is too drastic for a typo in the environment variable setting, but ignoring it silently is not a good option either.  Someone setting PYTHONIOENCODING most likely does it for a reason and giving him or her some sort of default behavior for mistyped encoding is not helpful.  (Note that this is how many C libraries treat TZ environment variable setting and this is often very frustrating.)

I think errors in environment variables that can be detected on startup should be treated the same way as the command line typos: a descriptive message on C stderr and exit(1).

Currently different environment variables are treated differently.  For example, mistakes in PYTHONHOME and PYTHONIOENCODING cause fatal error while an error in PYTHONSTARTUP is reported but does not terminate python:

$ PYTHONSTARTUP=xyz.py ./python.exe
Python 3.2rc2+ (py3k:88320, Feb  2 2011, 14:07:18) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Could not open PYTHONSTARTUP
IOError: [Errno 2] No such file or directory: 'xyz.py'
>>>

----------
nosy: +belopolsky
title: Fatal LookupError: unknown encoding: cp0 on Windows embedded startup. -> Fatal error on startup with invalid PYTHONIOENCODING

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

From report at bugs.python.org  Wed Feb  2 22:23:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 21:23:15 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1296681795.0.0.73529264437.issue6465@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My notes say that this bug is "similar to issue 5610", the fix for which made it in to 2.6.  I meant to come back and see if that fix fixed this bug, but I forgot.  The fix is different, so it is worth verifying that this test case fails in 2.5 but works subsequently.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Wed Feb  2 22:29:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 02 Feb 2011 21:29:22 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296682162.23.0.949001847044.issue11089@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

3.2.1 should be fine.

----------

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

From report at bugs.python.org  Wed Feb  2 22:34:26 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 02 Feb 2011 21:34:26 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1296682466.88.0.315315338239.issue6465@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Lucky as I can be, I have 2.5.5 here and I can confirm that with this version the code above fails - so I think this issue can be closed as fixed by issue5610 (I hope I correctly set all the fields, if not please let me know :)).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  2 22:37:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Feb 2011 21:37:49 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1296682669.28.0.484295271385.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed 3.1 in r88323.

----------
assignee: georg.brandl -> rhettinger
resolution:  -> later
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Feb  2 22:39:26 2011
From: report at bugs.python.org (Darren)
Date: Wed, 02 Feb 2011 21:39:26 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>


New submission from Darren <darrenb at sybase.com>:

The python installer should register the proper file type extensions. Files with .py extensions should have an "open" action associated with the python interpreter and there should also be an "Edit with IDLE" action associated with .py files as well.  I was able to configure both of these things manually on Windows XP but can not figure out how setup the "Edit with IDLE" action on Windows 7.

FWIW: I can run this command from a dos box and get the desired effect.
"C:\Python32\pythonw.exe" "C:\Python32\Lib\idlelib\idle.pyw" -n -e "Test.py"
and I expect the command to be registered with the .py file extension would be
"C:\Python32\pythonw.exe" "C:\Python32\Lib\idlelib\idle.pyw" -n -e "%1"


pythondb

The installer should just do this so python files have reasonable actions associated with them as soon as the install is complete.

----------
components: IDLE, Installation
messages: 127767
nosy: darren
priority: normal
severity: normal
status: open
title: Python 3.2 installer doesn't register file extensions on Windows 7
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  2 22:41:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Feb 2011 21:41:36 +0000
Subject: [issue6465] email.feedparser regular expression bug (NLCRE_crack)
In-Reply-To: <1247342320.74.0.342668726051.issue6465@psf.upfronthosting.co.za>
Message-ID: <1296682896.9.0.996502210845.issue6465@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good to me.  I've added the #6510 as superseder, though I doubt we'll ever make use of that info :)

----------
superseder:  -> email feedparser.py CRLFLF bug: $ vs \Z

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

From report at bugs.python.org  Wed Feb  2 22:51:04 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Feb 2011 21:51:04 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296683464.88.0.866735133882.issue11103@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Works for me. Just ran the 3.2 RC2 installer and did the following:

(type is like a Windows equivalent of `cat` on *nix) 

>type test.py
import sys
print(sys.version_info)

>test.py
sys.version_info(major=3, minor=2, micro=0, releaselevel='candidate', serial=2)


Additionally, "Edit with IDLE" shows up when right clicking on the file.

Did you get any errors when running the installer? What permissions does your account have?

----------
components: +Windows
nosy: +brian.curtin

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

From report at bugs.python.org  Wed Feb  2 23:08:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Feb 2011 22:08:52 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1296684532.25.0.745392470916.issue10951@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

gcc 4.6 bug has been fixed (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47271). So setup.py can compile extensions using gcc 4.6, and here are new warnings:
---
building dbm using bdb
/home/haypo/prog/GIT/py3k/Modules/_pickle.c: In function 'load':
/home/haypo/prog/GIT/py3k/Modules/_pickle.c:5267:9: warning: case value '0' not in enumerated type 'enum opcode' [-Wswitch]
/home/haypo/prog/GIT/py3k/Modules/_csv.c: In function 'parse_grow_buff':
/home/haypo/prog/GIT/py3k/Modules/_csv.c:537:21: warning: operation on 'self->field' may be undefined [-Wsequence-point]
/home/haypo/prog/GIT/py3k/Modules/_csv.c: In function 'join_check_rec_size':
/home/haypo/prog/GIT/py3k/Modules/_csv.c:1058:23: warning: operation on 'self->rec' may be undefined [-Wsequence-point]
/home/haypo/prog/GIT/py3k/Modules/_posixsubprocess.c:4:0: warning: "_GNU_SOURCE" redefined [enabled by default]
./pyconfig.h:1151:0: note: this is the location of the previous definition
/home/haypo/prog/GIT/py3k/Modules/socketmodule.c: In function 'socket_gethostbyname_ex':
/home/haypo/prog/GIT/py3k/Modules/socketmodule.c:3318:9: warning: variable 'result' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/socketmodule.c: In function 'socket_gethostbyaddr':
/home/haypo/prog/GIT/py3k/Modules/socketmodule.c:3396:9: warning: variable 'result' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/_sqlite/connection.c: In function '_pysqlite_final_callback':
/home/haypo/prog/GIT/py3k/Modules/_sqlite/connection.c:676:15: warning: variable 'aggregate_class' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/_sqlite/cursor.c: In function 'pysqlite_cursor_dealloc':
/home/haypo/prog/GIT/py3k/Modules/_sqlite/cursor.c:129:9: warning: variable 'rc' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/_sqlite/statement.c: In function 'pysqlite_statement_dealloc':
/home/haypo/prog/GIT/py3k/Modules/_sqlite/statement.c:372:9: warning: variable 'rc' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/_tkinter.c: In function 'PythonCmd':
/home/haypo/prog/GIT/py3k/Modules/_tkinter.c:2008:15: warning: variable 'self' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/tkappinit.c: In function 'Tcl_AppInit':
/home/haypo/prog/GIT/py3k/Modules/tkappinit.c:29:15: warning: variable 'main_window' set but not used [-Wunused-but-set-variable]
(...)
/home/haypo/prog/GIT/py3k/Modules/_ctypes/cfield.c: In function 'PyCField_FromDesc':
/home/haypo/prog/GIT/py3k/Modules/_ctypes/cfield.c:55:29: warning: variable 'length' set but not used [-Wunused-but-set-variable]
/home/haypo/prog/GIT/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function 'mmap_resize':
/home/haypo/prog/GIT/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3193:5: warning: implicit declaration of function 'mremap' [-Wimplicit-function-declaration]
/home/haypo/prog/GIT/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3193:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
/home/haypo/prog/GIT/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function 'sys_trim':
/home/haypo/prog/GIT/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3612:62: warning: comparison between pointer and integer [enabled by default]
---

----------

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

From report at bugs.python.org  Wed Feb  2 23:16:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 02 Feb 2011 22:16:42 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1296685002.89.0.942289719994.issue6253@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Jan, are you still interested in this?

----------

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

From report at bugs.python.org  Wed Feb  2 23:19:41 2011
From: report at bugs.python.org (Darren)
Date: Wed, 02 Feb 2011 22:19:41 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296685181.23.0.273231804476.issue11103@psf.upfronthosting.co.za>


Darren <darrenb at sybase.com> added the comment:

Perhaps it was just fixed in RC2?  I did my install last week with RC1.  My account has admin privileges and UAC is disabled on my machine.  There were no errors when I ran the installer.  Tomorrow I will try uninstalling RC1 and reinstalling RC2 to see if that makes a difference.

I definitely have no Edit with Idle option when I right click files.

----------

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

From report at bugs.python.org  Wed Feb  2 23:25:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 22:25:31 +0000
Subject: [issue7111] abort when stderr is moved
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1296685531.24.0.409974950135.issue7111@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> If we want to allow for closed {stdin, stdout, stderr}, I'm not sure
> what the semantics should be. Should sys.std{in, out, err} be None? Or a
> file object which always throws an error?

I would say it should be a *pseudo*-file object which always throws a *descriptive* error.  Note that setting sys.stdout to None makes print() do nothing rather than report an error:

>>> sys.stdout = None
>>> print('abc')

See also issue6501.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Feb  2 23:30:50 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 02 Feb 2011 22:30:50 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296685850.03.0.949165461432.issue11103@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't think any changes were made around that feature, and it has always worked for the last few installations I've done. Please do follow up with your RC2 experience when you have a chance.

----------

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

From report at bugs.python.org  Wed Feb  2 23:36:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 22:36:39 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1296686199.53.0.506854452646.issue7111@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, as long as python used fd 2 as the "message stream of last resort", we should probably not allow it to run with fd 2 closed. The problem is that in this case fd 2 may become associated with a very important file contents of which you don't want to see replaced with a python error message.

----------
title: abort when stderr is moved -> abort when stderr is closed

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

From report at bugs.python.org  Thu Feb  3 00:01:03 2011
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Feb 2011 23:01:03 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1296687663.05.0.964852451032.issue10951@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just a comment on those warnings about unused assignments; think about commenting them out instead of flat-out deleting them. When I ran clang over Python 2.7 I got some blow-back from deleting some assignments as some found them to be like documentation. In instances where the assignment helps explain what is going on it is best to just comment the code out.

----------

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

From report at bugs.python.org  Thu Feb  3 00:15:34 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Feb 2011 23:15:34 +0000
Subject: [issue9592] Limitations in objects returned by multiprocessing Pool
In-Reply-To: <1281726168.11.0.648826556363.issue9592@psf.upfronthosting.co.za>
Message-ID: <1296688534.93.0.864759720112.issue9592@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Thu Feb  3 01:05:44 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:05:44 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>


New submission from John Dennis <jdennis at redhat.com>:

The behaviour of sdist has changed dramatically in Python 2.7. Some projects prefer to maintain their own manifest file instead of utilizing automatic manifest generation from a template. The defined behaviour of sdist is to check for the presence of both a template and a manifest, if the template is absent but a manifest exists sdist is supposed to read the existing manifest, it no longer does this. Instead it creates a default file list with the catastrophic result of omitting the bulk of a projects files.  

It appears this bug was introduced in r81255 and is discussed in #8688. Unfortunately #8688 contained a number of different issues and was closed addressing only a subset of the problems. Changeset r83996 was introduced to prevent sdist from overwriting a project maintained manifest by testing for a comment at the head of the manifest file. It's not clear to me this was necessary because the write_manifest() should never have been called if the template was absent but a manifest existed.

Even after the application of changeset r83996 one of the fundamental problems in #8688 remained, the manifest is not read. The solution is to check for both the manifest and template (as was formerly done) and if the template is absent but the manifest exists then the manifest should be read.

I have made modifications to get_file_list() to reintroduce the defined behaviour. With the introduction of r83996 it is now legal syntax to have comments in the manifest however read_manifest() was not enhanced to account for the possible presence of comments. I also modified read_manifest() to handle comments.

These suggested fixes are attached as a patch against the current 2.7 maintenance branch. I've also attached a file with the two modified methods because sometimes it's difficult to comprehend a patch.

----------
assignee: tarek
components: Distutils
messages: 127777
nosy: eric.araujo, jdennis, tarek
priority: normal
severity: normal
status: open
title: distutils sdist ignores MANIFEST
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  3 01:06:49 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:06:49 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296691609.36.0.445847885145.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20655/sdist.patch

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

From report at bugs.python.org  Thu Feb  3 01:08:20 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:08:20 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296691700.95.0.0778936208513.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


Added file: http://bugs.python.org/file20656/sdist_new

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

From report at bugs.python.org  Thu Feb  3 01:13:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 00:13:38 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1296692018.64.0.656659405111.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Backported in r88324 and r88328.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Thu Feb  3 01:25:22 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 03 Feb 2011 00:25:22 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1296692722.75.0.195460117289.issue11090@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

This incorrect section on unittest command line features was added by Eric according to svn blame.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Thu Feb  3 01:34:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 00:34:34 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1296693274.13.0.923402070011.issue11090@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch to remove the section about command-line usage + other things new in 3.2.

----------
keywords: +patch
Added file: http://bugs.python.org/file20657/fix-11090.diff

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

From report at bugs.python.org  Thu Feb  3 01:43:57 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:43:57 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296693837.29.0.636403720553.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


Removed file: http://bugs.python.org/file20655/sdist.patch

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

From report at bugs.python.org  Thu Feb  3 01:44:03 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:44:03 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296693843.46.0.357518745936.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


Removed file: http://bugs.python.org/file20656/sdist_new

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

From report at bugs.python.org  Thu Feb  3 01:44:40 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:44:40 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296693880.33.0.842739524108.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


Added file: http://bugs.python.org/file20658/sdist.patch

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

From report at bugs.python.org  Thu Feb  3 01:45:17 2011
From: report at bugs.python.org (John Dennis)
Date: Thu, 03 Feb 2011 00:45:17 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296693917.44.0.636430320318.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


Added file: http://bugs.python.org/file20659/sdist_new

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

From report at bugs.python.org  Thu Feb  3 03:27:30 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Feb 2011 02:27:30 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296700050.04.0.652933791102.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a patch that covers all of the relevant dead assignments that were detected.

----------
keywords: +patch
Added file: http://bugs.python.org/file20660/clang_analyzer.diff

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

From report at bugs.python.org  Thu Feb  3 03:47:05 2011
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Thu, 03 Feb 2011 02:47:05 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1296701225.14.0.911893689499.issue1602@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Feedback from Julie Solon of Microsoft:

> These console functions share a per-process heap that is 64K. There is some overhead, the heap can get fragmented, and calls from multiple threads all affect how much is available for this buffer. 

> I am working to update the documentation for this function [WriteConsoleW] and other affected functions with information along these lines, and will post it within the next week or two.

I replied thanking her and asking for clarification:

When you say that the heap can get fragmented, is this true only when
there are concurrent calls to the console functions, or can it occur
even with single-threaded use? I'm trying to determine whether acquiring
a process-global lock while calling these functions would be sufficient
to ensure that the available heap space will not be unexpectedly low.
(This assumes that the functions not used outside the lock by other
libraries in the same process.)

ReadConsoleW seems also to be affected, incidentally.

I've asked for clarification about whether acquiring a process-global lock when using these functions ...
Julie

----------

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

From report at bugs.python.org  Thu Feb  3 04:25:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 03:25:50 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296703550.1.0.649773826841.issue11071@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Thu Feb  3 06:02:40 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2011 05:02:40 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

You don't want to know why I was thinking about this...

$ ./python 
Python 3.2rc2+ (py3k:88302, Feb  1 2011, 19:02:10) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")
Segmentation fault

----------
messages: 127783
nosy: benjamin.peterson
priority: low
severity: normal
status: open
title: Compiling evil ast crashes interpreter
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Feb  3 06:14:40 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 03 Feb 2011 05:14:40 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1296710080.42.0.44898963839.issue9127@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

This has been fixed in 2.7 and 3.2 so I think that this issue can be closed.

----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Thu Feb  3 08:26:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2011 07:26:49 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296718009.8.0.390933445162.issue8914@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Nice work. I'm surprised there wasn't more dead code.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Feb  3 08:55:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Feb 2011 07:55:02 +0000
Subject: [issue9127] subprocess.Popen.communicate() and SIGCHLD handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1296719702.57.0.49759247432.issue9127@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the problem report.  And thanks for noticing the fix.

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Thu Feb  3 11:01:32 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 03 Feb 2011 10:01:32 +0000
Subject: [issue7678] subprocess.Popen pipeline example code in the
	documentation is lacking
In-Reply-To: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>
Message-ID: <1296727292.25.0.826363818484.issue7678@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

The docs should be updated. This has been noted in msg54949 and http://www.enricozini.org/2009/debian/python-pipes/

Perhaps this example will make it clear:
import subprocess

p1 = subprocess.Popen(["yes"], stdout=subprocess.PIPE)
p2 = subprocess.Popen(["head"], stdin=p1.stdout, stdout=subprocess.PIPE)
#p1.stdout.close()
p1.wait()

This example hangs. "yes" writes to "head" and head reads the first 10 lines and then exits. But, "yes" does not receive a SIGPIPE because the python process still has a p1.stdout open. Thus, p1.stdout should be closed after being passed to p2.

----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Thu Feb  3 12:57:37 2011
From: report at bugs.python.org (Alexey Luchko)
Date: Thu, 03 Feb 2011 11:57:37 +0000
Subject: [issue11098] syntax error at end of line in interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296734257.89.0.952468979645.issue11098@psf.upfronthosting.co.za>


Alexey Luchko <luch at ank-sia.com> added the comment:

I reported the issue just because I didn't find it is already known.
I don't think it is worth backporting.

----------

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

From report at bugs.python.org  Thu Feb  3 13:30:48 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Feb 2011 12:30:48 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296736248.84.0.378386159538.issue11079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

After discussions with Raymond, I now agree that it would be better to not copy the Tools into the Applications/Python 3.x directory since everything else there is of the double-clickable nature, i.e. aimed at the user more comfortable with a GUI interface.  Since the Tools files may be of interest to advanced command-line users, a better place for them is within the framework share directory as many other UNIX-like distributions install them in /usr/share.

The following two patches implement the following changes from 3.2rc2 OS X installer behavior.

issue11079_extras_py3k.patch:

1. modifies the Mac Makefile installextras target to put a copy of Tools/ in the framework at share/doc/pythonm.n/examples rather than in /Applications/Python m.n

2. updates the installer ReadMe file accordingly.

issue11079_doc_links.patch

3. places a link named "Python Documentation.html" in /Applications/Python m.n to the top-level index.html file of the installed documentation set.

4. places a link to the documentation directory in the framework at share/doc/pythonm.n/html

Summary of installed file differences:

/Applications/Python m.s/
  Extras/
    2.7/3.1: contained ReadMe and old Demo directories
    3.2rc2: contained Tools directory (note 1 below)
    3.2: no longer created
  Python Documentation.html
    2.7/3.1/3.2rc2: not created
    3.2: symlink to index page of standard documentation:
           /Library/Frameworks/Python.framework/Versions/3.2/\
             Resources/English.lproj/Documentation/index.html

/Library/Frameworks/Python.framework/Versions/m.n/
  share/doc/pythonm.n/examples
    2.7/3.1/3.2rc2: not created
    3.2: contains Tools directory
  share/doc/pythonm.n/html
    2.7/3.1/3.2rc1: not created
    3.2: relative symlink to standard documentation location:
           ../../../Resources/English.lproj/Documentation

The included changes affect only the Mac installer script and the Mac Makefile.  Both variants of the installer were built with these fixes and tested on 10.5 and 10.6 as appropriate.  If after review, the patches meet expectations, I ask for release manager approval to apply for 3.2final.


Note 1: If the user had installed one of the Python 3.2rc installers, the Extras directory and its contents will not be removed by the 3.2final installer.

Note 2: The additional documentation links should also be backported to 2.7.

----------
keywords: +after moratorium, buildbot, easy, gsoc, needs review, patch
nosy: +georg.brandl
priority: normal -> critical
stage:  -> commit review
Added file: http://bugs.python.org/file20661/issue11079_doc_links.patch

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

From report at bugs.python.org  Thu Feb  3 13:31:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Feb 2011 12:31:27 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296736287.16.0.696138515155.issue11079@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file20662/issue11079_extras_py3k.patch

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

From report at bugs.python.org  Thu Feb  3 13:34:06 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 12:34:06 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296736446.82.0.125917468057.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Here are some real micro benchmarks (note that the pybench benchmarks actually do lots of other stuff besides slicing):

base line:

$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)' 'l[s]'
1000000 loops, best of 3: 0.464 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None)' 'l[s]'
10000000 loops, best of 3: 0.149 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None,1)' 'l[s]'
10000000 loops, best of 3: 0.135 usec per loop


patched:

$ ./python -m timeit -s 'l = list(range(100))' 'l[:1]'
10000000 loops, best of 3: 0.158 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[:]'
1000000 loops, best of 3: 0.49 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[1:]'
1000000 loops, best of 3: 0.487 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[1:3]'
10000000 loops, best of 3: 0.184 usec per loop

$ ./python -m timeit -s 'l = list(range(10))' 'l[:]'
10000000 loops, best of 3: 0.185 usec per loop
$ ./python -m timeit -s 'l = list(range(10))' 'l[1:]'
10000000 loops, best of 3: 0.181 usec per loop


original:

$ ./python -m timeit -s 'l = list(range(100))' 'l[:1]'
10000000 loops, best of 3: 0.171 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[:]'
1000000 loops, best of 3: 0.499 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[1:]'
1000000 loops, best of 3: 0.509 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[1:3]'
10000000 loops, best of 3: 0.198 usec per loop

$ ./python -m timeit -s 'l = list(range(10))' 'l[:]'
10000000 loops, best of 3: 0.188 usec per loop
$ ./python -m timeit -s 'l = list(range(10))' 'l[1:]'
1000000 loops, best of 3: 0.196 usec per loop


So the maximum impact seems to be 8% for very short slices (<10) and it quickly goes down for longer slices where the copy impact clearly dominates. There's still some 2% for 100 items, though.

I find it interesting that the base line is way below the other timings. That makes me think it's actually worth caching constant slice instances, as CPython already does for tuples. Cython also caches both now. I would expect that constant slices like [:], [1:] or [:-1] are extremely common. As you can see above, caching them could speed up slicing by up to 30% for short lists, and still some 7% for a list of length 100.

Stefan

----------

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

From report at bugs.python.org  Thu Feb  3 13:39:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Feb 2011 12:39:39 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296736779.02.0.309198673878.issue11079@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords:  -after moratorium, buildbot, easy, gsoc, patch

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

From report at bugs.python.org  Thu Feb  3 14:22:02 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 13:22:02 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296739322.67.0.744997494009.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Here's another base line test: slicing an empty list

patched:

$ ./python -m timeit -s 'l = []' 'l[:]'
10000000 loops, best of 3: 0.0847 usec per loop

original:

$ ./python -m timeit -s 'l = []' 'l[:]'
10000000 loops, best of 3: 0.0977 usec per loop

That's about 13% less overhead.

----------

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

From report at bugs.python.org  Thu Feb  3 14:32:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 13:32:51 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1296736446.82.0.125917468057.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296739968.3705.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I find it interesting that the base line is way below the other
> timings. That makes me think it's actually worth caching constant
> slice instances, as CPython already does for tuples.

Indeed. I have never touched it, but I suppose it needs an upgrade of
the marshal format to support slices.
(of course, this will not help for other common cases such as l[x:x+2]).

----------

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

From report at bugs.python.org  Thu Feb  3 14:53:03 2011
From: report at bugs.python.org (=?utf-8?q?Ernst_Sj=C3=B6strand?=)
Date: Thu, 03 Feb 2011 13:53:03 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1296741183.16.0.517710034995.issue1757072@psf.upfronthosting.co.za>


Changes by Ernst Sj?strand <ernstp at gmail.com>:


----------
nosy: +Ernst.Sj?strand

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

From report at bugs.python.org  Thu Feb  3 15:32:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Feb 2011 14:32:14 +0000
Subject: [issue11098] syntax error at end of line in interactive python -u
In-Reply-To: <1296645535.22.0.821023606978.issue11098@psf.upfronthosting.co.za>
Message-ID: <1296743534.86.0.267749319652.issue11098@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Great.  Thanks for reporting it, and I'm glad we managed to already have it fixed :)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  3 15:58:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 14:58:34 +0000
Subject: [issue11087] Speeding up the interpreter with a few lines of code
In-Reply-To: <1296547053.5.0.194611271072.issue11087@psf.upfronthosting.co.za>
Message-ID: <1296745114.09.0.111607428639.issue11087@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, things are at best 3-4% faster here (often unchanged).

----------
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Feb  3 16:32:15 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 15:32:15 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296747135.41.0.791099215238.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

> of course, this will not help for other common cases such as l[x:x+2]

... which is exactly what this slice caching patch is there for. ;-)

----------

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

From report at bugs.python.org  Thu Feb  3 16:50:46 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 15:50:46 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296748246.02.0.475197395616.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

A quick test against the py3k stdlib:

find -name "*.py" | while read file; do egrep '\[[-0-9]*:[-0-9]*\]' "$file"; done | wc -l

This finds 2096 lines in 393 files.

----------

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

From report at bugs.python.org  Thu Feb  3 18:00:33 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 17:00:33 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1296752433.45.0.101254250853.issue11105@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looks like a stack overflow caused by an infinite recursion.  I am not sure if it is possible to add cycle detection code without sacrificing performance or setting some arbitrary limits.

I wonder: Why ast nodes need to be mutable?

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Feb  3 18:08:02 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2011 17:08:02 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296752433.45.0.101254250853.issue11105@psf.upfronthosting.co.za>
Message-ID: <AANLkTikas2vtwjRCKKLzjjjHSL+9KDx_9BYWU6AMvhRJ@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/2/3 Alexander Belopolsky <report at bugs.python.org>:
>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> Looks like a stack overflow caused by an infinite recursion. ?I am not sure if it is possible to add cycle detection code without sacrificing performance or setting some arbitrary limits.

Yes, it's definitely low priority. It's probably easier to crash the
interpreter by producing differently malformed ast anyway.

>
> I wonder: Why ast nodes need to be mutable?

So people can change them.

----------

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

From report at bugs.python.org  Thu Feb  3 18:21:43 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 17:21:43 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <AANLkTikas2vtwjRCKKLzjjjHSL+9KDx_9BYWU6AMvhRJ@mail.gmail.com>
Message-ID: <AANLkTimaGRZYef8mGC0zRY30yFHG_WGQnf97Upy2Wa0U@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 3, 2011 at 12:08 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
..
>> I wonder: Why ast nodes need to be mutable?
>
> So people can change them.

Well, they are hashable, so this needs to be done carefully.  Is this
necessary for AST-based optimizations?  Does Python actually change
AST after it has been created?  Note that for some optimizations it
may be more appropriate to build a new tree rather than mutate the old
one.  Depending on the algorithm, you may or may not need to change
the nodes after they have been created in the process.

----------

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

From report at bugs.python.org  Thu Feb  3 18:27:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2011 17:27:15 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <AANLkTimaGRZYef8mGC0zRY30yFHG_WGQnf97Upy2Wa0U@mail.gmail.com>
Message-ID: <AANLkTinHs870HhVWxzH7+PVS0PWkYudM4DtUbsSFQVLr@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/2/3 Alexander Belopolsky <report at bugs.python.org>:
>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> On Thu, Feb 3, 2011 at 12:08 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
> ..
>>> I wonder: Why ast nodes need to be mutable?
>>
>> So people can change them.
>
> Well, they are hashable, so this needs to be done carefully. ?Is this
> necessary for AST-based optimizations? ?Does Python actually change
> AST after it has been created? ?Note that for some optimizations it
> may be more appropriate to build a new tree rather than mutate the old
> one. ?Depending on the algorithm, you may or may not need to change
> the nodes after they have been created in the process.

Other people are, though. The hash is by identity anyway.

----------

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

From report at bugs.python.org  Thu Feb  3 18:28:07 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Feb 2011 17:28:07 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <AANLkTimaGRZYef8mGC0zRY30yFHG_WGQnf97Upy2Wa0U@mail.gmail.com>
Message-ID: <AANLkTinHs870HhVWxzH7+PVS0PWkYudM4DtUbsSFQVLr@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2011/2/3 Alexander Belopolsky <report at bugs.python.org>:
>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> On Thu, Feb 3, 2011 at 12:08 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
> ..
>>> I wonder: Why ast nodes need to be mutable?
>>
>> So people can change them.
>
> Well, they are hashable, so this needs to be done carefully. ?Is this
> necessary for AST-based optimizations? ?Does Python actually change
> AST after it has been created? ?Note that for some optimizations it
> may be more appropriate to build a new tree rather than mutate the old
> one. ?Depending on the algorithm, you may or may not need to change
> the nodes after they have been created in the process.

Other people are, though. The hash is by identity anyway.

----------

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

From report at bugs.python.org  Thu Feb  3 18:31:11 2011
From: report at bugs.python.org (H Xu)
Date: Thu, 03 Feb 2011 17:31:11 +0000
Subject: [issue11106] python 2.6.6 and python 2.7.1 cannot be built
	successfully because of an segment fault on NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>


New submission from H Xu <xuhdev at gmail.com>:

Build python 2.6.6 and python 2.7.1 on a NetBSD-5.1-sparc machine.

1. Run './configure';
2. Run 'make';
3. Run 'make install'.

There will be a problem after run 'make install'.
The last few lines of error messages are like the following:

Compiling /usr/local/lib/python2.6/test/test_binop.py ...
Compiling /usr/local/lib/python2.6/test/test_bisect.py ...
Compiling /usr/local/lib/python2.6/test/test_bool.py ...
Compiling /usr/local/lib/python2.6/test/test_bsddb.py ...
Compiling /usr/local/lib/python2.6/test/test_bsddb185.py ...
Compiling /usr/local/lib/python2.6/test/test_bsddb3.py ...
Compiling /usr/local/lib/python2.6/test/test_buffer.py ...
Compiling /usr/local/lib/python2.6/test/test_bufio.py ...
Compiling /usr/local/lib/python2.6/test/test_builtin.py ...
[1]   Segmentation fault (core dumped) PYTHONPATH=/usr/...
*** Error code 139

Stop.
make: stopped in /home/xuh/src/Python-2.6.6

Same thing with python 2.7.1.

----------
components: Build
messages: 127802
nosy: H.Xu
priority: normal
severity: normal
status: open
title: python 2.6.6 and python 2.7.1 cannot be built successfully because of an segment fault on NetBSD-5.1-sparc
type: compile error
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Feb  3 19:33:03 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 03 Feb 2011 18:33:03 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1296757983.24.0.472289612168.issue7111@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

That's an interesting point.

Do you know of places where we use fd 2 instead of sys.stderr?

----------

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

From report at bugs.python.org  Thu Feb  3 20:25:21 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 19:25:21 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>


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

Follow-up to ticket 10227. The following facts seem to indicate that it would be worth caching constant instances of the slice type, such as in [:] or [:-1].

with cached slice instance:

$ ./python -m timeit -s 'l = list(range(100)); s=slice(None)' 'l[s]'
1000000 loops, best of 3: 0.464 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None)' 'l[s]'
10000000 loops, best of 3: 0.149 usec per loop
$ ./python -m timeit -s 'l = list(range(10)); s=slice(None,1)' 'l[s]'
10000000 loops, best of 3: 0.135 usec per loop

uncached normal usage:

$ ./python -m timeit -s 'l = list(range(100))' 'l[:]'
1000000 loops, best of 3: 0.499 usec per loop
$ ./python -m timeit -s 'l = list(range(100))' 'l[:1]'
10000000 loops, best of 3: 0.171 usec per loop

Timings based on Python 3.2 rc2.

A quick grep against the py3k stdlib finds 2096 lines in 393 files that use constant slices.

----------
components: Interpreter Core
messages: 127804
nosy: scoder
priority: normal
severity: normal
status: open
title: Cache constant "slice" instances
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb  3 20:26:34 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 19:26:34 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1296761194.72.0.323725978773.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Created follow-up issue 11107 for caching constant slice objects.

----------

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

From report at bugs.python.org  Thu Feb  3 20:27:21 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 19:27:21 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296761241.79.0.5924970085.issue11107@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Erm, issue 10227.

----------

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

From report at bugs.python.org  Thu Feb  3 20:28:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Feb 2011 19:28:08 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296761288.1.0.928940670556.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This was just dead assignments. I have not tackled Idempotent operations, dead increments, dead initializations, dead nested assignments, possible deref of NULL, deref of unassigned pointer, division by zero, undefined/garbage results, or undefined alloc of 0 bytes.

IOW I tackled 36 out of 164 reported issues. =)

----------

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

From report at bugs.python.org  Thu Feb  3 20:35:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 19:35:39 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296761739.06.0.473789532089.issue11107@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Similar idea has been rejected in issue2268 because the win was too small to justify the number of changes that had to be made.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Feb  3 20:44:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 19:44:48 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1296757983.24.0.472289612168.issue7111@psf.upfronthosting.co.za>
Message-ID: <1296762284.3925.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's an interesting point.
> 
> Do you know of places where we use fd 2 instead of sys.stderr?

We normally don't. One reason is that buffering inside sys.stderr can
make ordering of output incorrect. There are some places in C code where
we do "fprintf(stderr, ...)" but that's for specialized debugging
(disabled in normal builds) or fatal error messages.

----------

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

From report at bugs.python.org  Thu Feb  3 20:47:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 19:47:03 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296762423.61.0.371349720367.issue11107@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb  3 20:48:57 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Feb 2011 19:48:57 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296762537.96.0.525531898123.issue11107@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Hmm, ok, but AFAICT, your patch was rejected rather because of the way it approached the problem, not so much because of the issue itself.

Plus, the fact that Python 3 requires slices in more places than Python 2 (which had the lower level getslice protocol) makes this a bigger issue now than it was three years ago.

----------

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

From report at bugs.python.org  Thu Feb  3 20:56:37 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 19:56:37 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1296762284.3925.4.camel@localhost.localdomain>
Message-ID: <AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 3, 2011 at 2:44 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> Do you know of places where we use fd 2 instead of sys.stderr?
>
> We normally don't. One reason is that buffering inside sys.stderr can
> make ordering of output incorrect. There are some places in C code where
> we do "fprintf(stderr, ...)" but that's for specialized debugging
> (disabled in normal builds) or fatal error messages.

This is the case that I had in mind.  What does non-debug build do on
a fatal error?  Also, can we be sure that Python does not call C
library functions that write to stderr behind the scenes?  If vanilla
Python is safe to run with closed fd 2, that may not be the case for
3rd party extensions.    What is the use case for "python >&-"?    Is
it important enough to justify the risk of accidental data loss?

----------

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

From report at bugs.python.org  Thu Feb  3 20:59:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 19:59:26 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com>
Message-ID: <AANLkTikeuotA2vJj_r8tZ9XMXP+C90X2EMORGjZkjvzE@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> On Thu, Feb 3, 2011 at 2:44 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> ..
>> Do you know of places where we use fd 2 instead of sys.stderr?
>
> We normally don't.

Hmm, grep "fprintf(stderr," returned 122 hits in the py3k branch.
Are you sure these are all debug-build only?

----------

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

From report at bugs.python.org  Thu Feb  3 21:05:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 20:05:09 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1255335800.65.0.921782203194.issue7111@psf.upfronthosting.co.za>
Message-ID: <1296763509.56.0.825887747326.issue7111@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +exarkun, loewis

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

From report at bugs.python.org  Thu Feb  3 21:06:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 20:06:46 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com>
Message-ID: <1296763603.3925.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > We normally don't. One reason is that buffering inside sys.stderr can
> > make ordering of output incorrect. There are some places in C code where
> > we do "fprintf(stderr, ...)" but that's for specialized debugging
> > (disabled in normal builds) or fatal error messages.
> 
> This is the case that I had in mind.  What does non-debug build do on
> a fatal error?

It uses fprintf(stderr, ...). That's the only thing it can do (there's
no way sys.stderr is guaranteed to be usable at that point). If C stderr
is invalid, then too bad.

> Also, can we be sure that Python does not call C
> library functions that write to stderr behind the scenes?

I think you can guess the answer :)

> What is the use case for "python >&-"?    Is
> it important enough to justify the risk of accidental data loss?

I don't think so. One more important use case is when running a Unix
daemon, which has (AFAIK) to close all std handles. I don't know how
that interacts with using C stderr, especially if the handle closing is
done in Python (and therefore only calls C close() and not fclose()!).

Perhaps we should provide a sys function to fclose() C std{in,out,err}.

----------

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

From report at bugs.python.org  Thu Feb  3 21:07:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 20:07:11 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <AANLkTikeuotA2vJj_r8tZ9XMXP+C90X2EMORGjZkjvzE@mail.gmail.com>
Message-ID: <1296763628.3925.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 03 f?vrier 2011 ? 19:59 +0000, Alexander Belopolsky a ?crit :
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> > On Thu, Feb 3, 2011 at 2:44 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> > ..
> >> Do you know of places where we use fd 2 instead of sys.stderr?
> >
> > We normally don't.
> 
> Hmm, grep "fprintf(stderr," returned 122 hits in the py3k branch.
> Are you sure these are all debug-build only?

"grep -C2" seems to say most of them are. I haven't done a survey.

----------

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

From report at bugs.python.org  Thu Feb  3 21:12:57 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 03 Feb 2011 20:12:57 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <AANLkTi=usftfBpySWubqmw=6Oxa=eXcAN3kzhVH9zda-@mail.gmail.com>
Message-ID: <AANLkTinYJF6rW1L8BV54ejfPviz-W09dp755Vij62Se8@mail.gmail.com>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Thu, Feb 3, 2011 at 11:56 AM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> 3rd party extensions. ? ?What is the use case for "python >&-"? ? ?Is
> it important enough to justify the risk of accidental data loss?

I don't think closing stderr via the command line is an important use
case, but pythonw.exe and Unix daemon processes are important use
cases.

----------

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

From report at bugs.python.org  Thu Feb  3 21:14:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Feb 2011 20:14:55 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1296764095.93.0.263935553917.issue11105@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Alex: If the node attributes were not mutable, it would be extremely awkward, not to say inefficient, to mutate an already existing AST as returned by ast.parse().

The AST objects in the _ast module aren't what Python works with internally, anyway. When calling ast.parse(), the AST is converted to Python objects (these are defined in Python-ast.c), and compile()ing such an object converts them back to the internal tree representation.  This conversion is where recursions would need to be handled.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Feb  3 21:18:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 20:18:49 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1296763603.3925.9.camel@localhost.localdomain>
Message-ID: <1296764326.3925.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't think so. One more important use case is when running a Unix
> daemon, which has (AFAIK) to close all std handles.

I just took a look at http://pypi.python.org/pypi/python-daemon/, and it
uses dup2() to redirect standard streams, which is far nicer.

----------

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

From report at bugs.python.org  Thu Feb  3 21:20:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 03 Feb 2011 20:20:16 +0000
Subject: [issue11107] Cache constant "slice" instances
In-Reply-To: <1296762537.96.0.525531898123.issue11107@psf.upfronthosting.co.za>
Message-ID: <1296764413.3925.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hmm, ok, but AFAICT, your patch was rejected rather because of the way
> it approached the problem, not so much because of the issue itself.

I would be rather for the patch myself. The bytecode currently generated
for sliced indexing is awfully suboptimal.

> Plus, the fact that Python 3 requires slices in more places than
> Python 2 (which had the lower level getslice protocol) makes this a
> bigger issue now than it was three years ago.

True.

----------

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

From report at bugs.python.org  Thu Feb  3 21:34:08 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Feb 2011 20:34:08 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296765248.21.0.956081212226.issue8914@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am looking forward to the rest.
This will be a nice cleanup.

----------

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

From report at bugs.python.org  Thu Feb  3 21:34:18 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Feb 2011 20:34:18 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296765258.85.0.699841477127.issue8914@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20660/clang_analyzer.diff

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

From report at bugs.python.org  Thu Feb  3 21:34:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 03 Feb 2011 20:34:52 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296765292.25.0.674942729141.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

New patch which covers dead assignments and increments.

----------
Added file: http://bugs.python.org/file20663/clang_analyzer.diff

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

From report at bugs.python.org  Thu Feb  3 21:49:11 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 03 Feb 2011 20:49:11 +0000
Subject: [issue7111] abort when stderr is closed
In-Reply-To: <1296764326.3925.15.camel@localhost.localdomain>
Message-ID: <AANLkTi=VTHTqHTQJjghUu4XR7LD74BbJkzarkXYSth0c@mail.gmail.com>


Daniel Stutzbach <stutzbach at google.com> added the comment:

On Thu, Feb 3, 2011 at 12:18 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> I just took a look at http://pypi.python.org/pypi/python-daemon/, and it
> uses dup2() to redirect standard streams, which is far nicer.

I'm more worried about the case where a daemon launches python.

At startup, could we check that 2 and 3 are valid file descriptors,
and, if not, open /dev/null?  That way, they cannot later be
inadvertently assigned to some other file?

----------

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

From report at bugs.python.org  Thu Feb  3 22:08:09 2011
From: report at bugs.python.org (Carlos Corbacho)
Date: Thu, 03 Feb 2011 21:08:09 +0000
Subject: [issue11108] Intermittent AttributeError when using time.strptime in
	threads
In-Reply-To: <1296767289.19.0.293158150558.issue11108@psf.upfronthosting.co.za>
Message-ID: <1296767289.19.0.293158150558.issue11108@psf.upfronthosting.co.za>


New submission from Carlos Corbacho <cathectic at gmail.com>:

time.strptime() intermittently (and I mean _really_ intermittently) throws an AttributeError.

Steps to reproduce:

Run the attached script (you may have to do this quite a lot of times; in an evening of trying, I could only trigger this bug once...) - this just starts lots of threads so that we have lots of time.strptime()'s running in parallel.

Expected:

It just keeps running every time.

Actual:

On one run, the script bailed out almost immediately -

ccorbacho at valkyrie:~/chroots/trunk/home/ccorbacho/scratch/ccorbacho$ python test_time.py
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "test_time.py", line 13, in run
    time.strptime("30 Nov 00", "%d %b %y")
AttributeError: _strptime_time

---
This is with Python 2.6.6. However, at work we have been seeing this very intermittently with Python 2.5 in threaded code doing time.strptime() as well (though we just get AttributeError: strptime, but I don't have any code I can provide to reproduce on 2.5), hence I'm raising the bug.

----------
components: None
files: test_time.py
messages: 127822
nosy: ccorbacho
priority: normal
severity: normal
status: open
title: Intermittent AttributeError when using time.strptime in threads
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file20664/test_time.py

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

From report at bugs.python.org  Thu Feb  3 22:20:17 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 03 Feb 2011 21:20:17 +0000
Subject: [issue11106] python 2.6.6 and python 2.7.1 cannot be built
	successfully because of an segment fault on NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296768017.08.0.4919969037.issue11106@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you debug this, e.g. by inspecting the core file?

----------
nosy: +loewis

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

From report at bugs.python.org  Thu Feb  3 22:24:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Feb 2011 21:24:04 +0000
Subject: [issue11106] python 2.6.6 and python 2.7.1 cannot be built
	successfully because of an segment fault on NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296768244.68.0.101608482865.issue11106@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you try to get a backtrace? Use make install SHELL="bash -x" to display executed shell commands. And then rerun the last command in gdb: after the crash, the "where" command will give you a backtrace.

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Feb  3 23:01:14 2011
From: report at bugs.python.org (Justin)
Date: Thu, 03 Feb 2011 22:01:14 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>


New submission from Justin <justin.warkentin at gmail.com>:

This is the same issue as was reported here: http://bugs.python.org/issue1954. It is still a problem in Python 3.1. I'm writing a server that will be receiving a massive number of requests and I'd like to eliminate the zombie problem. Once I figured out what was going on, I tried adding a call to collect_children() in the serve_forever() loop. It worked very well. I've included a patch of what I did, however, I obviously can't leave this change in my socketserver.py because we will be deploying this on a lot of servers.

Is there any reason not to collect_children() in the serve_forever() loop? It seems like the place to do it to me. The patch will only collect children if there are any, so it doesn't have to call it every time through the loop.

----------
components: Library (Lib)
files: collect_children.patch
keywords: patch
messages: 127825
nosy: jwark
priority: normal
severity: normal
status: open
title: socketserver.ForkingMixIn leaves zombies
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file20665/collect_children.patch

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

From report at bugs.python.org  Thu Feb  3 23:28:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Feb 2011 22:28:52 +0000
Subject: [issue11106] python 2.6.6 and python 2.7.1 cannot be built
	successfully because of an segment fault on NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296772132.79.0.110341374969.issue11106@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This seems to be a duplicate of #7424.

----------
nosy: +skrah
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> segmentation fault in listextend during install

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

From report at bugs.python.org  Thu Feb  3 23:28:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Feb 2011 22:28:58 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1296772138.04.0.56286267516.issue7424@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

See also:

http://gnats.netbsd.org/42627

----------
nosy: +H.Xu, haypo, loewis, skrah

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

From report at bugs.python.org  Thu Feb  3 23:48:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Feb 2011 22:48:54 +0000
Subject: [issue9045] 2.7rc1: 64-bit OSX installer is not built with 64-bit
	tkinter
In-Reply-To: <1277143341.0.0.74848452771.issue9045@psf.upfronthosting.co.za>
Message-ID: <1296773334.46.0.518970973186.issue9045@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Build
type: crash -> behavior

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

From report at bugs.python.org  Thu Feb  3 23:56:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 22:56:45 +0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1296773805.59.0.479548492586.issue1038909@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note that similar (duplicate?) #426740 was rejected, so maybe the discussion here is moot.

FWIW, I believe using a decorator or a custom metaclass to explicitly inherit a docstring is a good way of achieving what you want.

----------
nosy: +calvin
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Thu Feb  3 23:59:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 22:59:31 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1296773971.99.0.17157614566.issue8887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, same bug.

Possibly related: #410336 (I have to read it again to make sure).

----------

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

From report at bugs.python.org  Fri Feb  4 00:50:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Feb 2011 23:50:53 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296777053.67.0.310167453376.issue9364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> In the Python interpreter, do "from pydoc import help" to provide online
>> help.  Calling help(thing) on a Python object documents the object.
> Which is no longer accurate, because the help() function has long ago
> become a built-in.
To be pedantic, help is not available if python was started with -S.  (The docs for site and -S are cross-linked, so that should be discoverable easily enough.)  +1 on removing the outdated piece of advice.

> 1. The output from help(help) could be made more clear.
Agreed.

> Why should help special-case itself (with a slightly garbled line?)
> This would be a code patch to pydoc.help
I haven?t found any special-casing code.  Quick testing shows it?s just how pydoc displays help for instances of Python classes.  I think making the docstring of site._Helper better (i.e. explain what the class is for + tell people to call help() to access the doc system) would be enough, nothing to change in pydoc.py unless I?ve missed something.

(BTW, pydoc code is quite intricated, reminds me a bit of distutils!  Who wants to make a graph explaining how help works?)

> "This is a wrapper around pydoc.help" good so far "(with a twist)" thanks a lot.
> I think the comment should be either removed or explained.
Agreed.  I think the ?twist? is that the import is lazy and that help has a useful repr (wow, talk about a twist!).  Those details need not be alluded to, just remove the comment (?wrapper? is IMO enough to raise curiosity, the source is here to find what?s the wrapping).

> Replace "Define the built-in 'help'." with something clearer and more accurate,
> such as "The name 'help' is injected in module builtins after being bound
> to an instance of this class.".
I think that?s too much detail.  ?Class used to implement the built-in help function? is enough for my taste.

> 2. Improve manual chapter for site module.
+1 on better explaining behavior where needed, -1 on documenting implementation details starting with underscores.

> Add "inject 'help' into builtins and " after append.
-1.  help is documented in http://docs.python.org/dev/library/functions#help ; quit, exit, license, copyright and credits are documented in http://docs.python.org/dev/library/constants#constants-added-by-the-site-module (see #652749).  To prevent duplication, let?s just add a link from site to constants.

(You don?t want to know how much time the previous paragraph has cost me.)

> "This module contains a class (_Helper) that wraps function pydoc.help.
> An instance of the class is bound to name 'help' in the builtins module."
-1.  Counter-proposal: Add a link to library/functions#help from library/constants; add a link from library/site to library/constants.

> A recent discussion on pydev or maybe python-list (in the thread mentioned
> above?) implied that one could usefully make another instance of _Helper or maybe a
> subclass thereof. I did not pay enough attention, though, to really get it.
I?m curious about the use cases. Eli, can you give us the date of the private email from Terry so that someone can dig up the thread?

> "XXX Update documentation"
This comment refers to new functions in site to support PEP 370.

> "XXX document python -m site --user-base --user-site"
We can reuse the example written by Raymond for the whatsnew/3.2 document.

To sum up: needs one patch for Lib/site.py, one to add cross-links in Doc/library, one to add missing functions/data from PEP 370 in Doc/library/site.rst, another one to the same file to document the command-line interface of site (those last two may be one, if the contributor is motivated).  I suggest to wait for replies to my points above, and if there is consensus or lack of disagreement, someone can turn my suggestions into patches.

----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Feb  4 01:03:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:03:52 +0000
Subject: [issue1613479] pydoc info for a package doesn't list all package
	contents
Message-ID: <1296777832.67.0.0902072432265.issue1613479@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve just tested that the behavior is now correct.  I reproduced the tree structure, set PYTHONPATH, ran ?pydoc foo? to get only ?one? listed, added the pkgutil call in first/path/foo/__init__.py, re-ran ?pydoc foo?, got ?one? and ?two? listed.  I can also import both submodules.

The pydoc code now uses pkgutil.iter_modules.  Someone must have fixed that before 2.6, closing.  Thanks for the report nonetheless!

----------
nosy: +eric.araujo -BreamoreBoy
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb  4 01:05:42 2011
From: report at bugs.python.org (Carsten Klein)
Date: Fri, 04 Feb 2011 00:05:42 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296777942.18.0.054237192216.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

if you'd take a close look at the following lines accepted as part of the patch for stripping out unwanted/non standard cookies over trac:

+                try:
+                    old_set(key, real_value, coded_value)
+                except CookieError:
+                    bad_cookies.append(key)

then you will find that trac actually behaves just like what is requested in the "original" RFC, namely that the colon is part of the reserved or special characters not meant for inclusion with the cookie name or, as it was stated in the referred rfc, the token.

Please do not fix.

----------
nosy: +carsten.klein at axn-software.de

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

From report at bugs.python.org  Fri Feb  4 01:08:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:08:25 +0000
Subject: [issue3835] tkinter goes into an infinite loop (pydoc.gui)
In-Reply-To: <1221139272.34.0.29160759745.issue3835@psf.upfronthosting.co.za>
Message-ID: <1296778105.53.0.674115961367.issue3835@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Tkinter
versions: +Python 3.3 -Python 3.0

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

From report at bugs.python.org  Fri Feb  4 01:09:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:09:28 +0000
Subject: [issue8637] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1296778168.93.0.575580865205.issue8637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is there a standard documenting MANPAGER somewhere?

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Feb  4 01:11:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 00:11:08 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296778268.33.0.146368752417.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a new patch which includes setting the noreturn attribute on Py_FatalError() and Py_Exit() in order to make the null pointer deref analysis results more tractable.

----------
Added file: http://bugs.python.org/file20666/analyzer_fixes.diff

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

From report at bugs.python.org  Fri Feb  4 01:12:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 00:12:52 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296778372.76.0.0548635582006.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is a new set of results with the analyzer_fixes.diff file applied using the latest analyzer.

----------
Added file: http://bugs.python.org/file20667/checker_254_2011-02-03.tar.xz

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

From report at bugs.python.org  Fri Feb  4 01:15:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 00:15:38 +0000
Subject: [issue8637] pydoc should respect MANPAGER over PAGER.
In-Reply-To: <1296778168.93.0.575580865205.issue8637@psf.upfronthosting.co.za>
Message-ID: <AANLkTinkTHqUWxGmAAac+N-KUJKu=gyJJHTySEpGfsre@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 3, 2011 at 7:09 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Is there a standard documenting MANPAGER somewhere?
>

Not really a standard, but man page for man on my OSX laptop says:

"""
       -P  pager
              Specify which pager to use.  This option overrides the
MANPAGER environment variable, which in turn overrides the PAGER
variable.
"""

POSIX only mandates PAGER.  See
<http://pubs.opengroup.org/onlinepubs/007908799/xcu/man.html>.

As I said before, since pydoc is not man, if we want a pydoc-specific
variable to override PAGER, it should be callled PYDOCPAGER.

----------

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

From report at bugs.python.org  Fri Feb  4 01:24:08 2011
From: report at bugs.python.org (Carsten Klein)
Date: Fri, 04 Feb 2011 00:24:08 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1296779048.85.0.677071186958.issue2193@psf.upfronthosting.co.za>


Carsten Klein <carsten.klein at axn-software.de> added the comment:

Besides that, BM is wrong in the assumption that *who ever he is* Davi M. Kristol states that the colon is a valid character.
There is no such notion in the article. In fact, DMK repeats the definition found in the original RFC on cookies, which also was referred to in the follow up RFC and then again referred to in the current RFC which seeks to get rid of the set-cookie2 directive, combining the two RFCs into a single RFC/pseudo standard.

----------

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

From report at bugs.python.org  Fri Feb  4 01:26:42 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 00:26:42 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1296779202.06.0.89880180178.issue3367@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't have a working valgrind or purify, but I was able to reproduce the problem using a poor man's solution of adding

         assert(0xcbcbcbcbcbcbcbcb != tok->line_start);

before

         if (a >= tok->line_start)
 
With that assert the debug build indeed crashes once I hit Ctrl-D.  Attached patch fixes that. 

I have also added tok->line_start in a few tok constructors for which I don't have a test case demonstrating access to uninitialized value, but it seems to be good defensive programming.

----------
nosy: +belopolsky
Added file: http://bugs.python.org/file20668/issue3367.diff

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

From report at bugs.python.org  Fri Feb  4 01:27:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Feb 2011 00:27:15 +0000
Subject: [issue11108] Intermittent AttributeError when using time.strptime in
	threads
In-Reply-To: <1296767289.19.0.293158150558.issue11108@psf.upfronthosting.co.za>
Message-ID: <1296779235.09.0.746198727455.issue11108@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's a duplicate of issue7980.
One workaround is to call strptime() once in the main thread.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> time.strptime not thread safe

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

From report at bugs.python.org  Fri Feb  4 01:32:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:32:47 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1296779567.02.0.0960866739971.issue940286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I just added another comment on Rietveld because I thought this was not fixed :)  Demo session:

  $ pydoc3.2 nonlocal  # will launch my pager, then print to stdout
  
  Related help topics: global, NAMESPACES

Kevin Le, would you like to write a failing test to confirm my bug?

----------

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

From report at bugs.python.org  Fri Feb  4 01:39:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:39:33 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1296779973.78.0.289297806126.issue8637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My man(1) also respects MANPAGER (it?s the one from http://man-db.nongnu.org/), but given the lack of a standard, I agree with you.

However, I?m reluctant to add another env variable.  There are workarounds, for example using a shell alias like ?docpy="PAGER=most pydoc"?.  I think this warrants a python-ideas discussion.

Justin: what exactly is a pager that does not support man pages?

----------
stage: unit test needed -> 
title: pydoc should respect MANPAGER over PAGER. -> Add PYDOCPAGER envvar to specify pager for pydoc

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

From report at bugs.python.org  Fri Feb  4 01:45:27 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 00:45:27 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1296780327.82.0.407098803243.issue3367@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

George,

This is not really important enough to get into the 3.2 release, but uninitialized variable bugs tend to be nasty when they bite you, so I'll ask your opinion before bumping the version.

----------
assignee:  -> georg.brandl
nosy: +georg.brandl
stage: unit test needed -> patch review

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

From report at bugs.python.org  Fri Feb  4 01:51:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 00:51:49 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1296779973.78.0.289297806126.issue8637@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Raf8EmnrVf9=ivuC-66uyd=RkkfPnT=duAUMV@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 3, 2011 at 7:39 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Justin: what exactly is a pager that does not support man pages?

I may know the answer to this one.  A common PAGER setting is "less
-rs" which makes less skip whitespace lines and passes through
terminal control chars.  Nether of these options are needed for pydoc,
but I don't know if they cause any harm.

----------

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

From report at bugs.python.org  Fri Feb  4 01:52:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:52:19 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1296780739.93.0.637434779052.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for working on a patch, especially with such comprehensive tests.

> The object returned by :func:`.open` supports the same basic functionality as
> -dictionaries
> +:mod:`collection`.MutableMapping

The previous text was okay, I wouldn?t have changed it.

>     def items(self):
>+        return set([(key, self[key]) for key in self._index.keys()])
I don?t know if you should use a plain set or a collections.ItemsView here.  In dict objects, KeysView and ValuesView are set-like objects with added behavior, for example they yield their elements in the same order.  Raymond, can you comment?

Style remarks: you can iter without calling _index.keys(); you can avoid the intermediary list (IOW, remove enclosing [ and ]).

In the tests, you can use specialized methods like assertIn and assertIsNone, they remove some boilerplate and can give better error output.

I can?t review the C code. :)

----------
nosy: +rhettinger
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Feb  4 01:56:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:56:41 +0000
Subject: [issue6045] Add more dict methods to dbm interfaces
In-Reply-To: <1242549989.17.0.48305033807.issue6045@psf.upfronthosting.co.za>
Message-ID: <1296781001.55.0.285369317747.issue6045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I believe this is now superseded by #9523, which has less discussion but a patch.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Improve dbm modules

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

From report at bugs.python.org  Fri Feb  4 01:58:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 00:58:08 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1296781088.88.0.113891048494.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #5736 for a patch adding iteration support.  If the patch attached to his report supersedes the other one, I?ll close the other bug as duplicate.

----------

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

From report at bugs.python.org  Fri Feb  4 02:04:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:04:09 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296781449.89.0.288091337692.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This behavior change is actually present in 2.7.1, 3.1.3 and 3.2.  I?m concerned that you?ve found a bug with it (thanks for the report), and that we may have to change behavior again.

First, could you open another report about comment handling in read_manifest?  I overlooked that, and it should be fixed as quickly as possible, although there?s very little change this will make it into 3.2.0 (we?ll have 3.2.1 though).

Second, can you give us a test script (shell or Python) or a set of instructions we can reproduce to observe the behavior you say is defective?  Thanks in advance.

----------
components: +Distutils2
versions: +3rd party, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb  4 02:07:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:07:32 +0000
Subject: [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1296781652.09.0.271837819928.issue9189@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this report can be closed now.

----------
status: pending -> open

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

From report at bugs.python.org  Fri Feb  4 02:12:02 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 01:12:02 +0000
Subject: [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1296781922.97.0.208829851132.issue9189@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 02:12:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:12:16 +0000
Subject: [issue10847] Distutils drops -fno-strict-aliasing when CFLAGS are set
In-Reply-To: <1294348917.86.0.0652237323155.issue10847@psf.upfronthosting.co.za>
Message-ID: <1296781936.58.0.738517091273.issue10847@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  It came up on the debian-python ML recently too, and is actually already reported.  Following up on the other report.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> BASECFLAGS are not passed to module build line

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

From report at bugs.python.org  Fri Feb  4 02:16:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:16:14 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1296782174.02.0.444358560707.issue969718@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Pythons in Debian seem to be immune to this problem, thanks to this patch: http://deb.li/3ku1g (via http://lists.debian.org/debian-python/2010/12/msg00005.html).

I haven?t had time to learn the intricacies of make variables yet, so I can?t approve a patch.  I?m adding people from the nosy lists of other make variables bugs, hopefully someone will be able to review.

----------
nosy: +brett.cannon, georg.brandl, jyasskin, lemburg, lukasz.langa, mark.dickinson, pitrou, ronaldoussoren, skrah

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

From report at bugs.python.org  Fri Feb  4 02:18:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:18:19 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1296782299.2.0.606040475156.issue969718@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Duplicate report from Stephan Krah:

When CFLAGS are set, distutils drops -fno-strict-aliasing (among other
flags):


$ python2.7 setup.py build
...
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I./src -I/usr/local/include -I/usr/local/include/python2.7 -c src/gmpy.c -o build/temp.linux-x86_64-2.7/src/gmpy.o
...

$ CFLAGS="-fomit-frame-pointer" python2.7 setup.py build
...
gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fomit-frame-pointer -fPIC -I./src -I/usr/local/include -I/usr/local/include/python2.7 -c src/gmpy.c -o build/temp.linux-x86_64-2.7/src/gmpy.o
src/gmpy.c: In function ?_cmp_to_object?:
src/gmpy.c:4692: warning: dereferencing type-punned pointer will break strict-aliasing rules
...

I'm not sure if this is intentional. The documentation says:

"Compiler flags can also be supplied through setting the CFLAGS
environment variable. If set, the contents of CFLAGS will be added
to the compiler flags specified in the Setup file."

To me, this sounds as if they should be appended to the regular flags.

----------

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

From report at bugs.python.org  Fri Feb  4 02:21:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:21:19 +0000
Subject: [issue9168] setuid in smtp.py sheds privileges before binding port
In-Reply-To: <1278346841.06.0.147409219565.issue9168@psf.upfronthosting.co.za>
Message-ID: <1296782479.75.0.223818981012.issue9168@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review
stage:  -> patch review
type: crash -> behavior
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Feb  4 02:23:35 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 01:23:35 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1296782615.39.0.835842931473.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, done going through the results. Attached is a patch with all of the fixes (only one actual bug which I file an issue for separately; everything else is removing a little bit of dead code here and there).

----------
Added file: http://bugs.python.org/file20669/wheres_my_pony.diff

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

From report at bugs.python.org  Fri Feb  4 02:26:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 01:26:08 +0000
Subject: [issue11110] Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
In-Reply-To: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>
Message-ID: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>


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

Pretty straight forward change, but could potentially cause a NULL pointer deref in a rare situation.

diff --git a/Modules/_sqlite/module.c b/Modules/_sqlite/module.c
--- a/Modules/_sqlite/module.c
+++ b/Modules/_sqlite/module.c
@@ -329,7 +329,7 @@
         (pysqlite_statement_setup_types() < 0) ||
         (pysqlite_prepare_protocol_setup_types() < 0)
        ) {
-        Py_DECREF(module);
+        Py_XDECREF(module);
         return NULL;
     }

----------
components: Extension Modules
files: fix_sqlite.diff
keywords: patch
messages: 127853
nosy: brett.cannon, georg.brandl
priority: release blocker
severity: normal
stage: commit review
status: open
title: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
versions: Python 3.2
Added file: http://bugs.python.org/file20670/fix_sqlite.diff

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

From report at bugs.python.org  Fri Feb  4 02:27:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:27:34 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1296782854.79.0.698050057802.issue8933@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Fri Feb  4 02:38:16 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 04 Feb 2011 01:38:16 +0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1296783496.78.0.0109037944048.issue1038909@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I agree. It is close enough to be a duplicate. I suggest closing it.

As Ka-Ping noted in the other issue:
"There's a link to the base class provided if you want to find out what the base class does."

This is easy to do if your viewing pydoc output in a web browser.  And you can also look at the source code to see any comments.

At some point we can consider enhancing the command line help mode to make it easier to do the same.

----------

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

From report at bugs.python.org  Fri Feb  4 02:47:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 01:47:13 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1296784033.87.0.914652059317.issue9399@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the new patch.  It does not apply cleanly to the py3k branch, but that?s very easily corrected.


        self.file.write(self.message)
        self.file.write('\n')

Could be replaced by
        print(self.message, file=self.file)

print will use the right EOL for the platform and is just coooler.


By the way, self.file should not be rebound in __call__:
        if self.file is None:
            self.file = _sys.stdout
?
        file = (self.file if self.file is not None else _sys.stdout)


> Second, there are cases where you want whitespaces to be preserved,
> like printing out the license of your program (as I mentioned in my
> first post) Just look at this BSD license: [...]
> This is just plain ugly.

Agreed, but I did not suggest that the output be like that.  In my previous message, I suggested that argparse could replace \n with spaces and do its own line wrapping, to adapt to terminal length while avoiding chunking ugliness.  That?s Steven?s call anyway, I don?t have any strong feeling in favor of preserving whitespace or rewrapping.  If argparse wraps lines to the terminal width in other cases (like with epilog text), I think it should do so here too.

----------

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

From report at bugs.python.org  Fri Feb  4 02:50:05 2011
From: report at bugs.python.org (reynaldo)
Date: Fri, 04 Feb 2011 01:50:05 +0000
Subject: [issue11111] See "Gmail" on your Google homepage
In-Reply-To: <000e0cd215a2adb38b049b6b1962@google.com>
Message-ID: <000e0cd215a2adb38b049b6b1962@google.com>


New submission from reynaldo <renben77 at gmail.com>:

Your friend, renben77 at gmail.com, has sent you the following Google Gadget.

See "Gmail" on your Google homepage ??

screenshot

----------
files: unnamed
messages: 127856
nosy: renben
priority: normal
severity: normal
status: open
title: See "Gmail" on your Google homepage
Added file: http://bugs.python.org/file20671/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11111>
_______________________________________
-------------- next part --------------
Your friend, renben77 at gmail.com, has sent you the following Google Gadget.<br/><br/><div style="font-size:large"><b><a href="http://www.google.com/ig/adde?moduleurl=builtin_gmail.xml&source=imag">See "Gmail" on your Google homepage &raquo;</a></b></div><br/><br/><img style="border:1px solid #000;padding:12px" src="http://www.google.com/ig/modules/builtin_content/en_us/gmail.jpg" alt="screenshot">

From report at bugs.python.org  Fri Feb  4 02:51:18 2011
From: report at bugs.python.org (John Dennis)
Date: Fri, 04 Feb 2011 01:51:18 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296784278.57.0.380904421065.issue11104@psf.upfronthosting.co.za>


John Dennis <jdennis at redhat.com> added the comment:

$ tar xzf distutils_bug.tar.gz
$ cd distutils_bug
$ ./setup.py sdist

$ ./setup.py sdist
running sdist
running check
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

not writing to manually maintained manifest file 'MANIFEST'
creating foobar-1.0
making hard links in foobar-1.0...
hard linking README -> foobar-1.0
hard linking setup.py -> foobar-1.0
creating dist
Creating tar archive
removing 'foobar-1.0' (and everything under it)

$ cat MANIFEST 
README
setup.py
my_special_file

Note, the MANIFEST should have been read and the resulting tar file should have had my_special_file in it. sdist complains about a missing MANIFEST.in template which it shouldn't, it should use the existing MANIFEST, it also emits a warning about not overwriting a manually maintained MANIFEST which it shouldn't. It should just use the existing MANIFEST.

----------
Added file: http://bugs.python.org/file20672/distutils_bug.tar.gz

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

From report at bugs.python.org  Fri Feb  4 03:11:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 02:11:38 +0000
Subject: [issue11111] See "Gmail" on your Google homepage
In-Reply-To: <000e0cd215a2adb38b049b6b1962@google.com>
Message-ID: <1296785498.68.0.147871353188.issue11111@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Spam.

----------
nosy: +belopolsky -renben
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 03:21:37 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 02:21:37 +0000
Subject: [issue11110] Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
In-Reply-To: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>
Message-ID: <1296786097.38.0.394659083351.issue11110@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It may be clearer and match Python coding style better to fix it as follows:


Index: Modules/_sqlite/module.c
===================================================================
--- Modules/_sqlite/module.c	(revision 88320)
+++ Modules/_sqlite/module.c	(working copy)
@@ -321,14 +321,16 @@
 
     module = PyModule_Create(&_sqlite3module);
 
-    if (!module ||
-        (pysqlite_row_setup_types() < 0) ||
-        (pysqlite_cursor_setup_types() < 0) ||
-        (pysqlite_connection_setup_types() < 0) ||
-        (pysqlite_cache_setup_types() < 0) ||
-        (pysqlite_statement_setup_types() < 0) ||
-        (pysqlite_prepare_protocol_setup_types() < 0)
-       ) {
+    if (module == NULL)
+        return NULL;
+
+    if (pysqlite_row_setup_types() < 0 ||
+        pysqlite_cursor_setup_types() < 0 ||
+        pysqlite_connection_setup_types() < 0 ||
+        pysqlite_cache_setup_types() < 0 ||
+        pysqlite_statement_setup_types() < 0 ||
+        pysqlite_prepare_protocol_setup_types() < 0)
+    {
         Py_DECREF(module);
         return NULL;
     }

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Feb  4 03:46:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 02:46:52 +0000
Subject: [issue11045] shutil._make_tarball
In-Reply-To: <1296222490.15.0.786706157889.issue11045@psf.upfronthosting.co.za>
Message-ID: <1296787612.4.0.697063971755.issue11045@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Arg, #9173 had a patch including a test.  Not sure which bug is superseded by the other.

----------
nosy: +fdrake, paulsmith, v_peter

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

From report at bugs.python.org  Fri Feb  4 03:49:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 02:49:12 +0000
Subject: [issue9173] logger statement not guarded in shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1296787752.46.0.968155220509.issue9173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Duplicate report #11045 was opened recently; I didn?t remember this report and committed a one-line fix without a test.  Should we try to get a test into 3.2.0?

----------
nosy: +georg.brandl, kelseyhightower, rhettinger

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

From report at bugs.python.org  Fri Feb  4 04:04:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 03:04:09 +0000
Subject: [issue6142] distutils2 clean command: Remove extension modules built
	in-place
In-Reply-To: <1243612271.53.0.396822187567.issue6142@psf.upfronthosting.co.za>
Message-ID: <1296788649.05.0.0696882450942.issue6142@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Discussion summary:
- clean is supposed to remove the products of build
- build_ext is a subcommand of build
- build_ext with the inplace option writes files that are not removed by clean
- removing .pyc files is out of scope (they?re products of normal Python behavior, not related to distutils)
? I?m reclassifying this as a distutils2 feature request concerning the products of build_ext --inplace.

I?m not sure whether we should remove those products when the --all option is given to clean, or add a new option that we could enable by default.

----------
assignee: tarek -> 
components: +Distutils2 -Distutils
stage:  -> needs patch
title: Distutils doesn't remove .pyc files -> distutils2 clean command: Remove extension modules built in-place
versions: +3rd party -Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Feb  4 04:06:03 2011
From: report at bugs.python.org (rmtew)
Date: Fri, 04 Feb 2011 03:06:03 +0000
Subject: [issue11112] UDPTimeoutTest derives from SocketTCPTest
In-Reply-To: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>
Message-ID: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>


New submission from rmtew <richard.m.tew at gmail.com>:

File: Lib\test\test_socket.py

Code: 

  class UDPTimeoutTest(SocketTCPTest):

Problem:

This test is intended to test UDP sockets, but derives from SocketTCPTest.  Logic dictates this should derive from SocketUDPTest.

I've searched for UDP (with differing case, as that seems to matter) in several different fields on this site, and found no relevant matches.

----------
components: Tests
messages: 127863
nosy: rmtew
priority: normal
severity: normal
status: open
title: UDPTimeoutTest derives from SocketTCPTest
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb  4 04:12:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 03:12:26 +0000
Subject: [issue9691] sdist includes files that are not in MANIFEST.in
In-Reply-To: <1282822249.86.0.974734126224.issue9691@psf.upfronthosting.co.za>
Message-ID: <1296789146.11.0.97964053408.issue9691@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can?t reproduce on POSIX (linux2) either.  Have you tested with 3.1, 3.2 and distutils2?

----------
components: +Windows

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

From report at bugs.python.org  Fri Feb  4 04:43:55 2011
From: report at bugs.python.org (Brian Jones)
Date: Fri, 04 Feb 2011 03:43:55 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In Python 3.2b2, html.entities.codepoint2name and name2codepoint only support the 252 HTML entity names defined in the HTML 4 spec from 1997. I'm wondering if there's a reason not to support W3C Recommendation 'XML Entity Definitions for Characters' 

http://www.w3.org/TR/xml-entity-names/

This standard contains significantly more characters, and it is noted in that spec that the HTML 5 drafts use that spec's entities. You can see the current HTML 5 'Named character references' here: 

http://www.w3.org/TR/html5/named-character-references.html#named-character-references

If this is just a matter of somebody going in to do the grunt work, let me know. 

If startup costs associated with importing a huge dictionary are a concern, perhaps a more efficient type that enables the same lookup interface can be defined. 

If other reasons exist to not move in this direction, please do let me know!

----------
components: Library (Lib), Unicode, XML
messages: 127865
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: html.entities mapping dicts need updating?
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  4 04:44:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 03:44:00 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1296791040.31.0.357322558878.issue10419@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Fri Feb  4 04:46:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 03:46:07 +0000
Subject: [issue2437] Distutils runtime_library_dirs broken on Windows
In-Reply-To: <1206044595.46.0.100105317073.issue2437@psf.upfronthosting.co.za>
Message-ID: <1296791167.11.0.528081827215.issue2437@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Fri Feb  4 04:47:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 03:47:39 +0000
Subject: [issue8688] distutils sdist is too lazy w.r.t. recalculating MANIFEST
In-Reply-To: <1273581168.94.0.337026684583.issue8688@psf.upfronthosting.co.za>
Message-ID: <1296791259.84.0.373020685064.issue8688@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There is a bug in the new code.  See #11104.

----------

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

From report at bugs.python.org  Fri Feb  4 04:47:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 03:47:41 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1296791261.27.0.620219885786.issue7100@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Fri Feb  4 04:51:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 03:51:50 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296791510.86.0.970214765374.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you, the bug is clear now.  To fix this regression, the first step is to turn your tarball and instructions into a unit test and then fix the logic in the code.  If you want to do it, there are some process guidelines at http://wiki.python.org/moin/Distutils/FixingBugs

----------
assignee: tarek -> eric.araujo

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

From report at bugs.python.org  Fri Feb  4 05:16:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 04:16:44 +0000
Subject: [issue10860] Handle empty port after port delimiter in httplib
In-Reply-To: <1294427670.55.0.855321383674.issue10860@psf.upfronthosting.co.za>
Message-ID: <1296793004.9.0.406385978952.issue10860@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From RFC 3986, section 6.2.3 ?Scheme-Based Normalization?:

   The syntax and semantics of URIs vary from scheme to scheme, as
   described by the defining specification for each scheme.
   Implementations may use scheme-specific rules, at further processing
   cost, to reduce the probability of false negatives.  For example,
   because the "http" scheme makes use of an authority component, has a
   default port of "80", and defines an empty path to be equivalent to
   "/", the following four URIs are equivalent:

      http://example.com
      http://example.com/
      http://example.com:/
      http://example.com:80/

IOW, the empty string is not an invalid port.  The patch fixes that.  It includes tests but lacks a doc update.  I think it works for https URIs too, but I?d like a test to make sure.

----------
resolution: invalid -> 
stage: needs patch -> patch review
status: pending -> open
versions: +Python 3.3

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

From report at bugs.python.org  Fri Feb  4 05:54:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 04:54:19 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1296795259.01.0.739948825072.issue9756@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is a somewhat more straightforward way to reproduce the problem:

>>> class X:
...    __class__ = int
... 
[55910 refs]
>>> isinstance(X(), int)
True
[55914 refs]
>>> int.bit_length(X())
Assertion failed: (PyLong_Check(v)), function long_bit_length, file ../py3k-commit/Objects/longobject.c, line 4413.
Abort trap

The place to implement a stricter check would be in methoddescr_call() function defined in Objects/descrobject.c, but it may affect legitimate tricks.  On the other hand, requiring that every C implemented method checks the type of self in a type-specific way is probably not feasible either.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Feb  4 06:18:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 05:18:08 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1296796688.99.0.0678104726857.issue10042@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type: crash -> behavior
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Feb  4 06:43:12 2011
From: report at bugs.python.org (H Xu)
Date: Fri, 04 Feb 2011 05:43:12 +0000
Subject: [issue11106] python 2.6.6 and python 2.7.1 cannot be built
	successfully because of an segment fault on NetBSD-5.1-sparc
In-Reply-To: <1296754271.48.0.967126521261.issue11106@psf.upfronthosting.co.za>
Message-ID: <1296798192.7.0.306427812326.issue11106@psf.upfronthosting.co.za>


H Xu <xuhdev at gmail.com> added the comment:

The result of 'make install SHELL="bash -x"' seems nothing different with the "make install". Could there be any other way to debug?

----------

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

From report at bugs.python.org  Fri Feb  4 08:38:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 04 Feb 2011 07:38:38 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1296805118.19.0.677110018298.issue10736@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

After looking into these two test failures a bit more, it looks like both are due to regressions and/or bugs in the ActiveState Tk 8.5.9 Cocoa behavior versus the Apple Cocoa Tk 8.5.7, with which neither test fails.

The test_tab_identifiers failure may be a test case error where the test is making unwarranted assumptions about how the Notebook widget lays out its tabs.

The test_traversal failure may need to be modified to use a different key modifier for OS X (<alt> -> <option>) but there appears to be a deeper problem within Cocoa Tk on how the traversal is implemented (hint, option-char can run into the dead key problem documented in Issue10973).

http://docs.python.org/py3k/library/tkinter.ttk.html#tkinter.ttk.Notebook.enable_traversal

Neither of these failures appear to indicate any problems with tkinter itself.  At this stage in the 3.2 cycle, the failures can either be ignored or, if necessary, conditionally disabled for platform 'darwin'. This should be a release manager call.  Otherwise, the next step would be to isolate further and report as possible upstream bugs.

Also, the "setCanCycle: is deprecated" warnings have subsequently been shown to be avoidable by a change in the upstream Tcl/Tk build process and are expected to disappear in the next release of ActiveState Tcl/Tk 8.5.

----------

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

From report at bugs.python.org  Fri Feb  4 09:08:13 2011
From: report at bugs.python.org (Carlos Corbacho)
Date: Fri, 04 Feb 2011 08:08:13 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1296806893.18.0.433262792486.issue7980@psf.upfronthosting.co.za>


Carlos Corbacho <cathectic at gmail.com> added the comment:

As per my comments on Issue11108 - I suspect that PyImport_ImportModuleNoBlock is a bit of a red herring here - in Python 2.5 and earlier versions (well before PyImport_ImportModuleNoBlock was added), we have occasionally seen 'AttributeError: strptime' from threaded code calling time.strptime(), so whatever this bug is, I don't believe it's caused by the call now being non-blocking from 2.6 onwards.

----------
nosy: +ccorbacho

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

From report at bugs.python.org  Fri Feb  4 09:31:49 2011
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 04 Feb 2011 08:31:49 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296808309.36.0.0689633112715.issue11067@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

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

From report at bugs.python.org  Fri Feb  4 09:33:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 08:33:12 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1296808392.84.0.105610458191.issue11113@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Supporting the ones in HTML 5 would be fine with me. Supporting those of xml-entity-names would be inappropriate - it's not clear (to me, at least) that all of them are really meant for use in HTML.

----------
nosy: +loewis

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

From report at bugs.python.org  Fri Feb  4 09:52:37 2011
From: report at bugs.python.org (Laurens)
Date: Fri, 04 Feb 2011 08:52:37 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>


New submission from Laurens <3.14159265358 at xs4all.nl>:

file.tell() has become extremely slow in version 3.2, both rc1 and rc2. This problem did not exist in version 2.7.1, nor in version 3.1. It could be reproduced both on mac and windows xp.

----------
components: IO
messages: 127874
nosy: Laurens
priority: normal
severity: normal
status: open
title: file.tell extremely slow
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb  4 10:03:33 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 04 Feb 2011 09:03:33 +0000
Subject: [issue11112] UDPTimeoutTest derives from SocketTCPTest
In-Reply-To: <1296788763.68.0.867412797858.issue11112@psf.upfronthosting.co.za>
Message-ID: <1296810213.23.0.627065138701.issue11112@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report.  That does indeed seem to be a bug in the test:

"UDPTimeoutTest(SocketTCPTest)" should be "UDPTimeoutTest(SocketUDPTest)"

As the 3.2 release is in its final release candidate stage and this is not a release critical issue, the fix should wait until the source tree has opened up again for general fixes.

----------
nosy: +ned.deily
stage:  -> needs patch
versions: +Python 3.3 -Python 2.5, Python 2.6

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

From report at bugs.python.org  Fri Feb  4 10:39:23 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 04 Feb 2011 09:39:23 +0000
Subject: [issue11115] csv readers and writers should be context managers
In-Reply-To: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>
Message-ID: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

The context managers should simply forward to the underlying file object.

----------
components: Library (Lib)
messages: 127876
nosy: djc
priority: normal
severity: normal
status: open
title: csv readers and writers should be context managers
versions: Python 2.6

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

From report at bugs.python.org  Fri Feb  4 10:39:56 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 04 Feb 2011 09:39:56 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296812396.36.0.873287494065.issue11114@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Do you have a benchmark program you can post?

----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri Feb  4 10:40:02 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 04 Feb 2011 09:40:02 +0000
Subject: [issue11115] csv readers and writers should be context managers
In-Reply-To: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>
Message-ID: <1296812402.18.0.474902006564.issue11115@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
type:  -> feature request
versions:  -Python 2.6

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

From report at bugs.python.org  Fri Feb  4 10:42:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 09:42:10 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1296812530.11.0.800709911594.issue10994@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I can propose a specification of getsizeof: if you somehow manage to traverse all objects (without considering an object twice), and sum up the getsizeof results, you should end up with something close to, but smaller than the actual memory consumption. How close is a quality-of-implementation issue (so always returning 0 would be correct-but-useless).

It may be that implementations can also support counting certain hidden memory usage (headers, blocks shared across instances that are not objects themselves). Such functions would should have different names and interfaces (e.g. sys.gethiddenblocks(o) may return a list of (address, size) pairs); CPython doesn't provide any such function (although sys.mallocoverhead might be useful).

In any case: I'm not convinced that it is useful to mark functions as CPython-specific in the documentation. This clutters the documentation, and is of interest only for language lawyers. So if implementation details are to be documented, I'd prefer this to happen in a separate document.

----------
nosy: +loewis

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

From report at bugs.python.org  Fri Feb  4 10:50:02 2011
From: report at bugs.python.org (Nicolas Delaby)
Date: Fri, 04 Feb 2011 09:50:02 +0000
Subject: [issue10664] xml.sax.expatreader should support namespace prefixes
In-Reply-To: <1291929062.2.0.554979073686.issue10664@psf.upfronthosting.co.za>
Message-ID: <1296813002.35.0.377386832405.issue10664@psf.upfronthosting.co.za>


Nicolas Delaby <delaby.nicolas at gmail.com> added the comment:

the PyXML sax parser support this feature.
May be it can be backported into stdlib ?

----------
nosy: +Nicolas.Delaby

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

From report at bugs.python.org  Fri Feb  4 11:39:48 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 10:39:48 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Following Issue 9124 discussion: it took longer than i thought, but now i could rework my thing and got errors.  I've also tried Lib/test/test_mailbox.py, and that produces 0xA errors and 0xA failures.  I'll attach the entire tracebacks and test output as email_mbox.txt.
My local Py3K repo is at changeset HG:33774ca03c96 (SVN:r88332)
Here are only the exceptions:

==========

| [Opening mailbox "OLD.sdaoden.mbox" as mbox
| * Box contains 8 messages
|   * Dispatching message 1
ERROR: failed to handle box "OLD.sdaoden.mbox"
  Traceback (most recent call last):
    File "./s-postman.py", line 1078, in _walk
      self._do_mailbox(mailbox)
    File "./s-postman.py", line 1088, in _do_mailbox
      Ticket.process_message(msg)
    File "./s-postman.py", line 987, in process_message
      print(msg)
    File "usr/lib/python3.2/email/message.py", line 152, in __str__
      return self.as_string()
    File "usr/lib/python3.2/email/message.py", line 167, in as_string
      g.flatten(self, unixfrom=unixfrom)
    File "usr/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "usr/lib/python3.2/email/generator.py", line 141, in _write
      self._write_headers(msg)
    File "usr/lib/python3.2/email/generator.py", line 176, in _write_headers
      self.write(header.encode(linesep=self._NL)+self._NL)
    File "usr/lib/python3.2/email/header.py", line 317, in encode
      formatter.feed(lines[0], charset)
  Exception: IndexError: list index out of range
Continue [yY - else no]? n
Exit due to errors as above

===========

PANIC: Box test.mdir: message-add failed, mails may be lost
       FIXME about fetch modus which saves the stuff somewhere
  Traceback (most recent call last):
    File "./s-postman.py", line 739, in add_ticket
      mailbox.add(ticket.message)
    File "usr/lib/python3.2/mailbox.py", line 269, in add
      self._dump_message(message, tmp_file)
    File "usr/lib/python3.2/mailbox.py", line 215, in _dump_message
      gen.flatten(message)
    File "usr/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "usr/lib/python3.2/email/generator.py", line 141, in _write
      self._write_headers(msg)
    File "usr/lib/python3.2/email/generator.py", line 373, in _write_headers
      self.write(header.encode(linesep=self._NL)+self._NL)
    File "usr/lib/python3.2/email/header.py", line 317, in encode
      formatter.feed(lines[0], charset)
  Exception: IndexError: list index out of range

==========

> Changing Ticket.process_message() to:
>    def process_message(msg):
>        print("Message-Type: ", msg.__name__)

ERROR: failed to handle box "src/s-postman/OLD.sdaoden.mbox"
  Traceback (most recent call last):
    File "./s-postman.py", line 1078, in _walk
      self._do_mailbox(mailbox)
    File "./s-postman.py", line 1088, in _do_mailbox
      Ticket.process_message(msg)
    File "./s-postman.py", line 987, in process_message
      print("Message-Type: ", msg.__name__)
  Exception: AttributeError: 'mboxMessage' object has no attribute '__name__'
Continue [yY - else no]? n
Exit due to errors as above

==========

> And this is about Lib/test/test_mailbox.py

21:30 ~/py3k.hg/Lib/test $ python3 test_mailbox.py > ~/tmp/test.txt

Traceback (most recent call last):
  File "test_mailbox.py", line 2091, in <module>
    test_main()
  File "test_mailbox.py", line 2086, in test_main
    support.run_unittest(*tests)
  File "/usr/lib/python3.2/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/usr/lib/python3.2/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

----------
components: Library (Lib)
files: email_mbox.txt
messages: 127880
nosy: sdaoden
priority: normal
severity: normal
status: open
title: mailbox and email errors
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20673/email_mbox.txt

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

From report at bugs.python.org  Fri Feb  4 11:40:18 2011
From: report at bugs.python.org (Laurens)
Date: Fri, 04 Feb 2011 10:40:18 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296816018.7.0.98439320731.issue11114@psf.upfronthosting.co.za>


Laurens <3.14159265358 at xs4all.nl> added the comment:

Correction: the problem also exists in version 3.1. I created a benchmark program an ran it on my machine (iMac, snow leopard 10.6), with the following results:

------------------------------------------
2.6.6 (r266:84292, Dec 30 2010, 09:20:14) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 0.0009 s.
------------------------------------------
2.7.1 (r271:86832, Jan 13 2011, 07:38:03) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 0.0008 s.
------------------------------------------
3.1.3 (r313:86882M, Nov 30 2010, 09:55:56) 
[GCC 4.0.1 (Apple Inc. build 5494)]
result: 9.5682 s.
------------------------------------------
3.2rc2 (r32rc2:88269, Jan 30 2011, 14:30:28) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 8.3531 s.

Removing the line containing "tell" gives the following results:

------------------------------------------
2.6.6 (r266:84292, Dec 30 2010, 09:20:14) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 0.0007 s.
------------------------------------------
2.7.1 (r271:86832, Jan 13 2011, 07:38:03) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 0.0006 s.
------------------------------------------
3.1.3 (r313:86882M, Nov 30 2010, 09:55:56) 
[GCC 4.0.1 (Apple Inc. build 5494)]
result: 0.0093 s.
------------------------------------------
3.2rc2 (r32rc2:88269, Jan 30 2011, 14:30:28) 
[GCC 4.2.1 (Apple Inc. build 5664)]
result: 0.0007 s.


(Apparently, reading a file became a lot faster from 3.1 to 3.2.)

Conclusion: Execution of file.tell() makes the program about 10000 times slower.

Remark: the file mdutch.txt is a dummy text file containing 1000 lines with one word on each line.

----------
Added file: http://bugs.python.org/file20674/tell v01.py

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

From report at bugs.python.org  Fri Feb  4 11:45:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 10:45:51 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296816351.35.0.523834361816.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Oops - please be aware that these outputs were saved at the end of a frustrating session.  I'm doing things to show *you* what's passed around and the like, i.e. that the message is indeed a mboxMessage etc.  The error which occurs is always:

    File "usr/lib/python3.2/email/header.py", line 317, in encode
      formatter.feed(lines[0], charset)

----------

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

From report at bugs.python.org  Fri Feb  4 11:46:33 2011
From: report at bugs.python.org (lekma)
Date: Fri, 04 Feb 2011 10:46:33 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1296816393.05.0.799326214776.issue10271@psf.upfronthosting.co.za>


lekma <lekmalek at gmail.com> added the comment:

brett,

is there any chance for this to make it in?

----------

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

From report at bugs.python.org  Fri Feb  4 12:48:57 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 11:48:57 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296820137.15.0.286799028347.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This simplemost patch (email_header.patch) seems to work at first glance.  It heals *everything* (except for babyl format, see issue 11062).  (I feel a bit like Charlie Chaplin and i think you know what i mean.)

----------
keywords: +patch
Added file: http://bugs.python.org/file20675/email_header.patch

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

From report at bugs.python.org  Fri Feb  4 12:49:34 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 11:49:34 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296820174.96.0.226928424222.issue11116@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20673/email_mbox.txt

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

From report at bugs.python.org  Fri Feb  4 12:50:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 11:50:51 +0000
Subject: [issue11116] (mailbox and) email (errors) -> patch
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296820251.02.0.476854604518.issue11116@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
title: mailbox and email errors -> (mailbox and) email (errors) -> patch

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

From report at bugs.python.org  Fri Feb  4 12:54:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Feb 2011 11:54:13 +0000
Subject: [issue11116] (mailbox and) email (errors) -> patch
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296820453.42.0.287368506103.issue11116@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +r.david.murray

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

From report at bugs.python.org  Fri Feb  4 13:56:35 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 04 Feb 2011 12:56:35 +0000
Subject: [issue11116] (mailbox and) email (errors) -> patch
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296824195.36.0.376004166778.issue11116@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

The patch would be better to say:

if not lines:
    continue

However, it could be even simpler to do:

for string, charset in self._chunks:
    if not string: continue

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Fri Feb  4 14:21:39 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 04 Feb 2011 13:21:39 +0000
Subject: [issue9756] Crash with custom __getattribute__
In-Reply-To: <1283515984.36.0.673218996521.issue9756@psf.upfronthosting.co.za>
Message-ID: <1296825699.38.0.448163453788.issue9756@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

See also issue #10922.

----------

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

From report at bugs.python.org  Fri Feb  4 14:44:23 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Feb 2011 13:44:23 +0000
Subject: [issue11115] csv readers and writers should be context managers
In-Reply-To: <1296812363.95.0.525000547121.issue11115@psf.upfronthosting.co.za>
Message-ID: <1296827063.58.0.0444529247924.issue11115@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There is no underlying file object.  I presume you mean the reader/writer object?  Which have no close method, so there is no point in making them a context manager.  There is zero benefit and positive cost (an additional nesting level).  Just use with to open the file you then wrap in a reader/writer instance.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 14:53:37 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Feb 2011 13:53:37 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296827617.25.0.244650528683.issue11114@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I found that adding "infile._CHUNK_SIZE = 20" makes the test much faster - 'only' 5 times slower than 2.7.

----------
nosy: +amaury.forgeotdarc, pitrou

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

From report at bugs.python.org  Fri Feb  4 14:56:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Feb 2011 13:56:35 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296827795.6.0.394382474864.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Steffen, I appreciate your testing this.  Your error report doesn't have enough information for me to reproduce the problem.  Can you post a short test case, including a sample email/mailbox file if needed, that reproduces the problem you are seeing?  With a reproducible test case I can fix it quickly, without one I feel like I'm groping in the dark.  I need to be able to to create a unit test that demonstrates the problem in order to check in a fix; having a reproducible test case I can run will also help with writing that.

You also seem to report a failure in test_mailbox.  test_mailbox passes for me and on all the buildbots.  Are you running RC2?  What OS?

----------
stage:  -> unit test needed
title: (mailbox and) email (errors) -> patch -> mailbox and email errors

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

From report at bugs.python.org  Fri Feb  4 14:56:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Feb 2011 13:56:44 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296827804.47.0.296421137485.issue11116@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

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

From report at bugs.python.org  Fri Feb  4 15:01:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Feb 2011 14:01:06 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296828066.09.0.655989342867.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Perhaps your problem with test_mailbox is that you are running the test_mailbox from a checkout, but using an installed python3 that is not RC2, rather than the python3 built from the checkout?

----------

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

From report at bugs.python.org  Fri Feb  4 15:02:29 2011
From: report at bugs.python.org (DSM)
Date: Fri, 04 Feb 2011 14:02:29 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296828149.35.0.353289645242.issue11114@psf.upfronthosting.co.za>


DSM <dsm001 at users.sourceforge.net> added the comment:

With a similar setup (OS X 10.6) I see the same problem.  It seems to go away if the file is opened in binary mode for reading.  @Laurens, can you confirm?

----------
nosy: +dsm001

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

From report at bugs.python.org  Fri Feb  4 15:04:59 2011
From: report at bugs.python.org (DSM)
Date: Fri, 04 Feb 2011 14:04:59 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296828299.99.0.58661485557.issue11114@psf.upfronthosting.co.za>


DSM <dsm001 at users.sourceforge.net> added the comment:

(By "go away" I mean "stop being pathological", not "stop differing": I still see a factor of 2.)

----------

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

From report at bugs.python.org  Fri Feb  4 15:10:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 14:10:50 +0000
Subject: [issue11114] file.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296828650.11.0.746292106026.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That's expected. seek() and tell() on text (unicode) files are slow by construction. You should open your file in binary mode instead, if you want to do any seeking.

Maybe I should add a note in http://docs.python.org/dev/library/io.html#performance

----------

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

From report at bugs.python.org  Fri Feb  4 15:47:02 2011
From: report at bugs.python.org (John Dennis)
Date: Fri, 04 Feb 2011 14:47:02 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296830822.18.0.958417206023.issue11104@psf.upfronthosting.co.za>


John Dennis <jdennis at redhat.com> added the comment:

No, I don't think I'm going to turn the tarball into a unit test, etc. I didn't break the code but I did report the problem, researched the history, provided a clear explanation, a reproducer and a patch to fix the problem. I think I've done my part as a community member.

----------

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

From report at bugs.python.org  Fri Feb  4 15:47:52 2011
From: report at bugs.python.org (William Wu)
Date: Fri, 04 Feb 2011 14:47:52 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296830872.82.0.331125606687.issue11082@psf.upfronthosting.co.za>


William Wu <willie.tw at gmail.com> added the comment:

So, what's the decision to be taken? I'm willing to provide patches (if I need to), but I need to know *the reasonable behaviors*. :)

----------

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

From report at bugs.python.org  Fri Feb  4 16:07:39 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Feb 2011 15:07:39 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296830872.82.0.331125606687.issue11082@psf.upfronthosting.co.za>
Message-ID: <AANLkTik0+jxo6_iAmgzBs5tphiw_a8ye99ti=bt4M8nV@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

For this particular issue, I think, it is good idea to disallow str
explicitly, instead of letting it go through the Iterable and raise a
ValueError with a different message.

----------

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

From report at bugs.python.org  Fri Feb  4 16:26:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 04 Feb 2011 15:26:41 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>


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

This issue is a placeholder for exposing Async IO thru Python.

The relevant mail thread is at:

http://mail.python.org/pipermail/python-dev/2010-October/104770.html


Relevant resources:

http://feedproxy.google.com/~r/Wwwc0t0d0s0org/~3/snM0BJ8evv4/7147-Synchronicity-in-asynchronicity.html

http://www.opengroup.org/onlinepubs/000095399/basedefs/aio.h.html

----------
assignee: jcea
components: Extension Modules
messages: 127898
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Implementing Async IO
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Fri Feb  4 16:37:32 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 04 Feb 2011 15:37:32 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296833852.06.0.244802724898.issue11117@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Feb  4 16:41:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 15:41:32 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296834092.25.0.755382139457.issue11117@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

>From the python-dev thread:

http://mail.python.org/pipermail/python-dev/2010-October/104782.html

?os._exit is useful. os.open is useful. aio_* are *not* useful. For anything. If there's anything you think you want to use them for, you're wrong. It either won't work properly or it will worse performing than the simpler alternatives.?

http://mail.python.org/pipermail/python-dev/2010-October/104786.html

?I'd like to echo this sentiment.  This is not about providing a 'safe' wrapper to hide some powerful feature of these APIs: the POSIX aio_* functions are really completely useless.

[...]

Not only is the performance usually worse than expected, the behavior of aio_* functions require all kinds of subtle and mysterious coordination with signal handling, which I'm not entirely sure Python would even be able to pull off without some modifications to the signal module.  (And, as Jean-Paul mentioned, if your OS kernel runs out of space in a queue somewhere, completion notifications might just never be delivered at all.)?

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Feb  4 17:22:14 2011
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 04 Feb 2011 16:22:14 +0000
Subject: [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1296836534.74.0.427166827903.issue10994@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Martin: I kind of agree with you, although I guess that for pratical reasons if you don't have a reasonable sys.getsizeof() implementation then it's better to raise TypeError than return 0 (like CPython, which may raise "TypeError: Type %.100s doesn't define __sizeof__").

I agree that it's not really useful to mark functions as CPython-specific in the documentation, if only because whenever a new implementation like PyPy comes along, then it's going to have a rather different set of functions that it wants to consider implementation details.  I would say that more than half the functions in the sys module marked CPython-specific in the doc are implemented in PyPy just fine, and there is an equal number of functions not marked CPython-specific that have no chance to be implemented in PyPy.

----------

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

From report at bugs.python.org  Fri Feb  4 17:26:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 16:26:09 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296836769.12.0.666588679747.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That said, I think it is possible to make algorithmic improvements to TextIOWrapper.tell() so that at least performance becomes acceptable.

----------
stage:  -> needs patch
title: file.tell extremely slow -> TextIOWrapper.tell extremely slow
type:  -> performance
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Feb  4 17:28:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 16:28:30 +0000
Subject: [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1296836910.39.0.277388570065.issue10891@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I do think that "list.sort() method of a list" is a bit too much.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Fri Feb  4 17:31:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 04 Feb 2011 16:31:11 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296837071.78.0.723571974005.issue11117@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Feb  4 17:32:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 16:32:15 +0000
Subject: [issue11110] Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
In-Reply-To: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>
Message-ID: <1296837135.65.0.18002803429.issue11110@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Either one of these fixes (I prefer Brett's since it's shorter) should make it into 3.2.

----------

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

From report at bugs.python.org  Fri Feb  4 17:33:04 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 16:33:04 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1296837184.1.0.588454218465.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Then let us do that.

Senthil, what about urlencode of bytes values returning a str?

----------

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

From report at bugs.python.org  Fri Feb  4 17:34:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 16:34:29 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1296837269.88.0.624356360963.issue10736@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I would prefer just letting the tests fail.  Disabled tests are usually forgotten, and never re-enabled.

----------

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

From report at bugs.python.org  Fri Feb  4 17:35:51 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 16:35:51 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1296837351.52.0.559432303211.issue3367@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No need to bump the version, it can go into 3.2.1.  But seeing the history of this case, I don't want to play around here before 3.2 final.

----------

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

From report at bugs.python.org  Fri Feb  4 17:54:36 2011
From: report at bugs.python.org (Laurens)
Date: Fri, 04 Feb 2011 16:54:36 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296838476.36.0.527954777529.issue11114@psf.upfronthosting.co.za>


Laurens <3.14159265358 at xs4all.nl> added the comment:

First of all, thanks to all for your cooperation, it is very much appreciated.

I made some minor changes to the benchmark program. Conclusions are:

 * setting file._CHUNK_SIZE to 20 has a dramatic effect, changing execution time in 3.2rc2 from 8.4s to 0.06s, so more than a factor 100 improvement. It's a bit clumsy, but acceptable as a performance work around.

 * opening file binary has a dramatic effect as well, I would say. After 2 minutes I stopped execution of the program, concluding that this change made the program at least a factor 10 *slower* instead of faster. So I cannot confirm DSM's statement that the performance hit would be a factor 2. Instead, I see a performance hit of at least a factor 100000 (10e5) compared tot 2.7.1, which is presumably not by construction ;-).

----------

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

From report at bugs.python.org  Fri Feb  4 17:57:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 16:57:12 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296838632.38.0.317382238798.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> opening file binary has a dramatic effect as well, I would say. After 2 
> minutes I stopped execution of the program

Hint: b'' is not equal to '' ;)

----------

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

From report at bugs.python.org  Fri Feb  4 18:17:54 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 04 Feb 2011 17:17:54 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296839874.75.0.368168398105.issue9364@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +ron_adam

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

From report at bugs.python.org  Fri Feb  4 18:26:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:26:48 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296840408.59.0.257307469866.issue11061@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 18:28:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:28:57 +0000
Subject: [issue11061] Verify command option before parsing config file
In-Reply-To: <1296314455.37.0.770288704329.issue11061@psf.upfronthosting.co.za>
Message-ID: <1296840537.06.0.259362939792.issue11061@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
type: behavior -> performance

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

From report at bugs.python.org  Fri Feb  4 18:30:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:30:19 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1296840619.2.0.748984304085.issue11060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Strange, the regex comes straight from the PEP, which has had careful review.  It must be somewhere else in the code.  Would you like to work on a patch, or a test first?  We have to find out if sdist is responsible, or metadata, or version, etc.

----------
keywords: +easy
versions: +3rd party

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

From report at bugs.python.org  Fri Feb  4 18:35:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 17:35:38 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1296837351.52.0.559432303211.issue3367@psf.upfronthosting.co.za>
Message-ID: <AANLkTin9HX66R7DeJ=Ro8wa6atz-sSFvLC5DecPOCRRX@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Feb 4, 2011 at 11:35 AM, Georg Brandl <report at bugs.python.org> wrote:

>..?But seeing the history of this case, I don't want to play around here before 3.2 final.

Here is my understanding of the history of this case:  tmp1.patch was
applied in r65539 and reverted in r65543 with the log entry saying:

------------------------------------------------------------------------
r65543 | andrew.kuchling | 2008-08-04 22:05:23 -0400 (Mon, 04 Aug 2008) | 1 line

#3367: revert rev. 65539: this change causes test_parser to fail
------------------------------------------------------------------------

Revision 65539 has never been applied to py3k, but it would be
equivalent to the following diff:

Index: Parser/tokenizer.c
===================================================================
--- Parser/tokenizer.c	(revision 88320)
+++ Parser/tokenizer.c	(working copy)
@@ -1289,7 +1289,7 @@
     register int c;
     int blankline, nonascii;

-    *p_start = *p_end = NULL;
+    tok->line_start = *p_start = *p_end = NULL;
   nextline:
     tok->start = NULL;
     blankline = 0;

Applying the above diff now makes test_parser crash on a debug and
fail on a regular build.  The problem with initializing
tok->line_start to NULL is that doing so trades one undefined behavior
for another: pointer comparison such as a >= tok->line_start is only
defined if both pointers point to the same buffer.  Ordering between
NULL and non-NULL pointers is undefined.  My patch does not have this
issue because it initializes tok->line_start to tok->buf.

----------

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

From report at bugs.python.org  Fri Feb  4 18:39:26 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Feb 2011 17:39:26 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1296841166.0.0.605355244182.issue3367@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: georg.brandl -> belopolsky

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

From report at bugs.python.org  Fri Feb  4 18:40:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:40:01 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1296841201.06.0.429783580887.issue11113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Martin.  I wonder if we should provide a means to use only HTML 4.01 entity references (say with a function parameter html5 defaulting to True) or we should just update the mapping.

----------
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Fri Feb  4 18:43:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:43:31 +0000
Subject: [issue11101] plistlib has no graceful way of handing None values
In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za>
Message-ID: <1296841411.52.0.131186665903.issue11101@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +jvr, ronaldoussoren

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

From report at bugs.python.org  Fri Feb  4 18:43:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:43:51 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1296841431.72.0.434874774621.issue11090@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

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

From report at bugs.python.org  Fri Feb  4 18:46:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:46:33 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296841593.9.0.36072044072.issue11086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.  Not sure this needs unit tests; I suppose you plan to add a note to the docs.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Feb  4 18:50:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 17:50:58 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296841858.97.0.817436703266.issue11085@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Seems a good idea to me.

Regarding the implementation, knowing your reluctance to turn modules into packages, I guess you?re talking about exposing collections.abc in a similar manner to os.path, which is fine IMO.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Feb  4 19:10:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 18:10:05 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296843005.88.0.261989456349.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a proof-of-concept patch for the pure Python version of TextIOWrapper.tell(). It turns the O(CHUNK_SIZE) operation into an O(1) operation most of time (still O(CHUNK_SIZE) worst-case - weird decoders and/or crazy input).

----------
keywords: +patch
Added file: http://bugs.python.org/file20676/textiotell.patch

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

From report at bugs.python.org  Fri Feb  4 19:20:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 18:20:00 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296843005.88.0.261989456349.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296843596.3774.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here is a proof-of-concept patch for the pure Python version of
> TextIOWrapper.tell(). It turns the O(CHUNK_SIZE) operation into an
> O(1) operation most of time (still O(CHUNK_SIZE) worst-case - weird
> decoders and/or crazy input).

Actually, that's wrong. The patch is still O(CHUNK_SIZE) but with a
vastly different multiplier (and, optimistically, much smaller, as
common codecs are codecs in C).

----------

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

From report at bugs.python.org  Fri Feb  4 19:43:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 18:43:09 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296844989.5.0.346628925387.issue11076@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice idea indeed, thanks for the patch.

For the doc section, I?d prefer to de-emplasize the specific use case of **kwargs, in favor of mentioning dict conversion in a general way:

  Converting the namespace to a dict
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  
  Namespace objects are iterable so you can easily convert them to a
  :class:`dict`::

     args = parser.parse_args()
     argdict = dict(args)

  This makes it easy to introspect the namespace or to pass the
  command-line arguments to a function taking a bunch of keyword
  arguments::

     somefunction(**dict(parser.parse_args()))

 
+    def __iter__(self):
+        return iter(self.__dict__.items())
Isn?t ?return self.__dict__.items()? sufficient in 3.x?


Alternate idea: don?t implement __iter__, which is sorta too broad, and implement a method that just returns a dict.

Musing: Isn?t Namespace (technically: _AttributeHolder) very much like a named tuple?  Could some code be removed by using named tuples in argparse?  Note that named tuples provide a method to convert themselves to a dict, and are efficient (IIRC).

----------
nosy: +bethard, eric.araujo
stage:  -> patch review

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

From report at bugs.python.org  Fri Feb  4 19:50:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 18:50:28 +0000
Subject: [issue11118] Fix python3 None export
In-Reply-To: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>
Message-ID: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

The None export of python3.dll is bogus; attached is a fix. This also regenerates python3stub.def, which contained some exports that had already been deleted from python3.def.

----------
files: none.diff
keywords: patch
messages: 127917
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Fix python3 None export
versions: Python 3.2
Added file: http://bugs.python.org/file20677/none.diff

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

From report at bugs.python.org  Fri Feb  4 19:51:32 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 04 Feb 2011 18:51:32 +0000
Subject: [issue11050] email.utils.getaddresses behavior contradicts RFC2822
In-Reply-To: <1296253802.55.0.925837101087.issue11050@psf.upfronthosting.co.za>
Message-ID: <1296845492.45.0.203544565154.issue11050@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
nosy: +v+python

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

From report at bugs.python.org  Fri Feb  4 20:03:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 04 Feb 2011 19:03:44 +0000
Subject: [issue11118] Fix python3 None export
In-Reply-To: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>
Message-ID: <1296846224.96.0.364420455747.issue11118@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Looks fine to me.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Feb  4 20:06:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Feb 2011 19:06:40 +0000
Subject: [issue11118] Fix python3 None export
In-Reply-To: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>
Message-ID: <1296846400.68.0.936301808418.issue11118@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Me too.

----------

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

From report at bugs.python.org  Fri Feb  4 20:09:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 19:09:37 +0000
Subject: [issue11118] Fix python3 None export
In-Reply-To: <1296845428.15.0.394711490398.issue11118@psf.upfronthosting.co.za>
Message-ID: <1296846577.71.0.909991785049.issue11118@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the quick review. Committed as r88333.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 20:22:30 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 19:22:30 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296847350.88.0.0488996415496.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

You're right, the python3 executable is indeed

20:05 ~/tmp $ python3 -V
Python 3.2rc1+

The relevant .py files (mailbox.py, email/*.py, (email/mime/*.py), test/test_mailbox.py are symlinked to the repo files.
(And, different to this morning - sorry, *sorry*: lunch break - they all point to HG:33774ca03c96 (SVN:r88332) files.
I've removed my patch and this is what happens (only five errors remain).
The traceback:

Traceback (most recent call last):
  File "test_mailbox.py", line 2092, in <module>
    test_main()
  File "test_mailbox.py", line 2087, in test_main
    support.run_unittest(*tests)
  File "/Users/steffen/usr/lib/python3.2/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/Users/steffen/usr/lib/python3.2/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: multiple errors occurred

==========
This is the stripped output:

test_add_binary_file (__main__.TestMaildir) ... ERROR
test_add_binary_file (__main__.TestMbox) ... ERROR
test_add_binary_file (__main__.TestMMDF) ... ERROR
test_add_binary_file (__main__.TestMH) ... ERROR
test_add_binary_file (__main__.TestBabyl) ... ERROR

======================================================================
ERROR: test_add_binary_file (__main__.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 146, in test_add_binary_file
    sys.exit(1)
SystemExit: 1

======================================================================
ERROR: test_add_binary_file (__main__.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 146, in test_add_binary_file
    sys.exit(1)
SystemExit: 1

======================================================================
ERROR: test_add_binary_file (__main__.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 146, in test_add_binary_file
    sys.exit(1)
SystemExit: 1

======================================================================
ERROR: test_add_binary_file (__main__.TestMH)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 146, in test_add_binary_file
    sys.exit(1)
SystemExit: 1

======================================================================
ERROR: test_add_binary_file (__main__.TestBabyl)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_mailbox.py", line 146, in test_add_binary_file
    sys.exit(1)
SystemExit: 1

----------------------------------------------------------------------
Ran 327 tests in 8.540s

----------

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

From report at bugs.python.org  Fri Feb  4 20:24:23 2011
From: report at bugs.python.org (pen hill)
Date: Fri, 04 Feb 2011 19:24:23 +0000
Subject: [issue11119] Passing a socket to a process (multiprocessing module)
In-Reply-To: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>
Message-ID: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>


New submission from pen hill <imbenhill at gmail.com>:

When I run the following listing (server_multi.py) by using multiprocessing module of python, it runs successfully on a Linux machine. However, on a 64-bit windows machine I get the following error:

pickle.PicklingError: Can't pickle <built-in method recvfrom_into of _socket.socket object at 0x0000000002D2CF10>: it's not found as __main__.recvfrom_into

This module is from the book Foundations of Python Network Programming, 2nd Edition. I am pasting the code with the permission of the author. It seems that socket "listen_sock" cannot be pickled under 64-bit
Windows, however it can be pickled under Linux. How can we remove this issue on Windows? It is interesting that if I use the threading module, it works for both Windows and Linux. Thanks. 

server_multi.py :
#usage: $ python server_multi.py localhost process
#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - server_multi.py
# Using multiple threads or processes to serve several clients in parallel.

import sys, time, lancelot
from multiprocessing import Process
from server_simple import server_loop
from threading import Thread

WORKER_CLASSES = {'thread': Thread, 'process': Process}
WORKER_MAX = 10

def start_worker(Worker, listen_sock):
    worker = Worker(target=server_loop, args=(listen_sock,))
    worker.daemon = True  # exit when the main process does
    worker.start()
    return worker

if __name__ == '__main__':
    if len(sys.argv) != 3 or sys.argv[2] not in WORKER_CLASSES:
        print >>sys.stderr, 'usage: server_multi.py interface thread|process'
        sys.exit(2)
    Worker = WORKER_CLASSES[sys.argv.pop()]  # setup() wants len(argv)==2

    # Every worker will accept() forever on the same listening socket.

    listen_sock = lancelot.setup()
    workers = []
    for i in range(WORKER_MAX):
        workers.append(start_worker(Worker, listen_sock))

    # Check every two seconds for dead workers, and replace them.

    while True:
        time.sleep(2)
        for worker in workers:
            if not worker.is_alive():
                print worker.name, "died; starting replacement worker"
                workers.remove(worker)
                workers.append(start_worker(Worker, listen_sock))

lancelot.py:

#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - lancelot.py
# Constants and routines for supporting a certain network conversation.

import socket, sys

PORT = 1060
qa = (('What is your name?', 'My name is Sir Lancelot of Camelot.'),
      ('What is your quest?', 'To seek the Holy Grail.'),
      ('What is your favorite color?', 'Blue.'))
qadict = dict(qa)

def recv_until(sock, suffix):
    message = ''
    while not message.endswith(suffix):
        data = sock.recv(4096)
        if not data:
            raise EOFError('socket closed before we saw %r' % suffix)
        message += data
    return message

def setup():
    if len(sys.argv) != 2:
        print >>sys.stderr, 'usage: %s interface' % sys.argv[0]
        exit(2)
    interface = sys.argv[1]
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    sock.bind((interface, PORT))
    sock.listen(128)
    print 'Ready and listening at %r port %d' % (interface, PORT)
    return sock

server_simple.py:

#!/usr/bin/env python
# Foundations of Python Network Programming - Chapter 7 - server_simple.py
# Simple server that only serves one client at a time; others have to wait.

import lancelot

def handle_client(client_sock):
    try:
        while True:
            question = lancelot.recv_until(client_sock, '?')
            answer = lancelot.qadict[question]
            client_sock.sendall(answer)
    except EOFError:
        client_sock.close()

def server_loop(listen_sock):
    while True:
        client_sock, sockname = listen_sock.accept()
        handle_client(client_sock)

if __name__ == '__main__':
    listen_sock = lancelot.setup()
    server_loop(listen_sock)

----------
components: None
messages: 127922
nosy: pen hill
priority: normal
severity: normal
status: open
title: Passing a socket to a process (multiprocessing module)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 20:24:32 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 19:24:32 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296847472.81.0.103713952978.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.S.: it's that messed UNIX with the nice user-experience *G*UI.  And the __pycache__ files state 'cpython-32'.

----------

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

From report at bugs.python.org  Fri Feb  4 20:30:12 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 19:30:12 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296847812.16.0.9066505146.issue11067@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is the patch I'd like to add to 3.2: this adds PyType_GetFlags, so that the fast checks remain available.

----------
nosy: +georg.brandl
priority: normal -> release blocker
Added file: http://bugs.python.org/file20678/tp_flags.diff

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

From report at bugs.python.org  Fri Feb  4 20:34:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 19:34:45 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296848085.56.0.592000080839.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Dear RDM, now i'm really ashamed.  To be absolutely sure that i am up-to-date if diff'd and found that test_mailbox.py contained a sys.exit(1) i've inserted this - it was the lunch break, really!
Forget everything i've posted.  Please close this.  Shame on me.

----------

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

From report at bugs.python.org  Fri Feb  4 20:37:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 19:37:09 +0000
Subject: [issue11074] fix tokenize so it can be reloaded
In-Reply-To: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za>
Message-ID: <1296848229.98.0.917080893994.issue11074@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Feb  4 20:38:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 19:38:20 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296848300.05.0.13713594052.issue11063@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Feb  4 20:48:16 2011
From: report at bugs.python.org (cardinalbiggles)
Date: Fri, 04 Feb 2011 19:48:16 +0000
Subject: [issue11120] threading.Thread.daemon Documentation Incomplete
In-Reply-To: <1296848896.87.0.703380092713.issue11120@psf.upfronthosting.co.za>
Message-ID: <1296848896.87.0.703380092713.issue11120@psf.upfronthosting.co.za>


New submission from cardinalbiggles <jmandersen at gmail.com>:

In the threading module, the documentation for Thread.isDaemon()/Thread.setDaemon() indicates they are the old API for Thread.daemon, which does not indicate the version in which it was introduced (2.6 I believe). 

Additionally, the documentation for Thread.setDaemon() should at least include the daemonic parameter, if not the full usage documentation for those targeting older versions.

Targeting Python 2.4, and being unable to (as) efficiently navigate the old documentation site, I have come to rely on the various 'Changed/New in version 2.X' messages in the current documentation. This caused some confusion on my part.

----------
assignee: docs at python
components: Documentation
messages: 127927
nosy: cardinalbiggles, docs at python
priority: normal
severity: normal
status: open
title: threading.Thread.daemon Documentation Incomplete
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 20:56:04 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 19:56:04 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296849364.68.0.140204957169.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I thought about it.  It's worse.  You did a good job and i was not even able to create symlinks the way it should have been done.  This is a real shame - for me.

----------

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

From report at bugs.python.org  Fri Feb  4 20:57:13 2011
From: report at bugs.python.org (Matthew Walker)
Date: Fri, 04 Feb 2011 19:57:13 +0000
Subject: [issue9207] multiprocessing occasionally spits out exception during
	shutdown (_handle_workers)
In-Reply-To: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za>
Message-ID: <1296849433.99.0.979055169428.issue9207@psf.upfronthosting.co.za>


Matthew Walker <mattgwwalker at gmail.com> added the comment:

It looks to me as if this issue has already been pretty much sorted out already.  Maybe all it lacks is to be officially closed, but just in case I just wanted to add that I too saw this bug (stock python 2.7, Ubuntu 10.04 64 bit).

My example code was:

#!/usr/bin/env python

import multiprocessing
import os
import time

def f(i):
    print "I am process number",os.getpid(),": i =",i
    time.sleep(10)
    return i*i

pool = multiprocessing.Pool(maxtasksperchild=1)

print pool.map(f, range(10))

----------
nosy: +Matthew.Walker

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

From report at bugs.python.org  Fri Feb  4 21:01:17 2011
From: report at bugs.python.org (Matthew Walker)
Date: Fri, 04 Feb 2011 20:01:17 +0000
Subject: [issue9207] multiprocessing occasionally spits out exception during
	shutdown (_handle_workers)
In-Reply-To: <1278619533.83.0.0853433126095.issue9207@psf.upfronthosting.co.za>
Message-ID: <1296849677.38.0.054446859476.issue9207@psf.upfronthosting.co.za>


Matthew Walker <mattgwwalker at gmail.com> added the comment:

Oh, and the stack trace was identical to Greg's:

$ ./test.py 
I am process number 10378 : i = 0
[...]
I am process number 10390 : i = 9
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/gel/usr/mawal32/system/lib/python2.7/threading.py", line 530, in __bootstrap_inner
  File "/gel/usr/mawal32/system/lib/python2.7/threading.py", line 483, in run
  File "/gel/usr/mawal32/system/lib/python2.7/multiprocessing/pool.py", line 272, in _handle_workers
<type 'exceptions.TypeError'>: 'NoneType' object is not callable

----------

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

From report at bugs.python.org  Fri Feb  4 21:02:59 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 04 Feb 2011 20:02:59 +0000
Subject: [issue11121] libpython3.so support with --enable-shared
In-Reply-To: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>
Message-ID: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When configuring r88333 with --enable-shared, the error message

./configure: line 4924: test: ==: unary operator expected

is produced. The attached patch fixes the problem.

----------
files: pydebug.diff
keywords: patch
messages: 127931
nosy: loewis
priority: release blocker
severity: normal
status: open
title: libpython3.so support with --enable-shared
Added file: http://bugs.python.org/file20679/pydebug.diff

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

From report at bugs.python.org  Fri Feb  4 21:04:45 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 20:04:45 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1296849885.52.0.101827400036.issue11086@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yeah, probably some little mention in the docs.

----------

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

From report at bugs.python.org  Fri Feb  4 21:06:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 20:06:02 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296849962.56.0.714541908303.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch also optimizing the C version. tell() can be more than 100x faster now (still much slower than binary tell()).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20680/textiotell2.patch

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

From report at bugs.python.org  Fri Feb  4 21:06:48 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 04 Feb 2011 20:06:48 +0000
Subject: [issue11121] libpython3.so support with --enable-shared
In-Reply-To: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>
Message-ID: <1296850008.87.0.897772012683.issue11121@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever, georg.brandl
versions: +Python 3.2

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

From report at bugs.python.org  Fri Feb  4 21:09:29 2011
From: report at bugs.python.org (Laurens)
Date: Fri, 04 Feb 2011 20:09:29 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1296850169.75.0.901734424017.issue11114@psf.upfronthosting.co.za>


Laurens <3.14159265358 at xs4all.nl> added the comment:

All,

thanks for your help. Opening the file in binary mode worked immediately in the toy program (that is, the benchmark code I sent you). (Antoine, thanks for the hint.) In my real world program, I solved the problem by reading a line from a binary input file, and decode it explicitly and immediately to a string. The performance has become acceptable now, and I propose to close this issue.


Thanks again, cheers,

Laurens

----------
resolution:  -> accepted

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

From report at bugs.python.org  Fri Feb  4 21:09:50 2011
From: report at bugs.python.org (Oren Held)
Date: Fri, 04 Feb 2011 20:09:50 +0000
Subject: [issue11102] configure doesn't find "major()" on HP-UX v11.31
In-Reply-To: <1296677130.56.0.432506284039.issue11102@psf.upfronthosting.co.za>
Message-ID: <1296850190.57.0.887244984994.issue11102@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

Just a small note: after this patch applied, building Python 2.7.1 was successful on Linux (SLES 11, RHEL 5, Ubuntu 10.10), Solaris 10, and HP-UX 11 v3. (I didn't get to build Python on other platforms)

----------

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

From report at bugs.python.org  Fri Feb  4 21:20:15 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 20:20:15 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1296850815.37.0.168682326932.issue10271@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Not for 3.2.0, no as it's such a minor "fix". Chance this can go into 3.2.1, though. Definitely for 3.3.

----------

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

From report at bugs.python.org  Fri Feb  4 21:21:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 20:21:16 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1296850876.53.0.585334453067.issue11104@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I didn?t mean to imply you had to, I just asked if you wanted to.  Reporting the bug is a valuable contribution indeed, I?ll take over for the rest.

----------

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

From report at bugs.python.org  Fri Feb  4 21:30:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Feb 2011 20:30:44 +0000
Subject: [issue11110] Py_DECREF->Py_XDECREF in Module/_sqlite/module.c
In-Reply-To: <1296782768.85.0.000422256440074.issue11110@psf.upfronthosting.co.za>
Message-ID: <1296851444.46.0.319696109115.issue11110@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

py3k: r88337
3.1: 88339
2.7 (blocked): 88338

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  4 21:35:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 20:35:11 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296851711.1.0.790870239761.issue11067@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The doc needs a versionadded attribute. Otherwise, looks good to me.

----------
nosy: +pitrou
resolution:  -> accepted
stage:  -> commit review

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

From report at bugs.python.org  Fri Feb  4 21:37:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 20:37:56 +0000
Subject: [issue11121] libpython3.so support with --enable-shared
In-Reply-To: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>
Message-ID: <1296851876.24.0.411106287782.issue11121@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me.

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Feb  4 22:18:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 04 Feb 2011 21:18:20 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296854300.0.0.396929310725.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

However, as a last peep from me before i'll burn to ashes, and now with all fresh Python 3.2rc2+ all through, i do want to ask a question.

I'm still not finished with my broken thing, so the usual exception still occurs in respect to the malformed spam mail which made its way into Lib/test/test_mailbox.py - this is still my fault.  The thing i want to point out is that the target mailbox will end with these lines after the program fails:

>
>
>
> From MAILER-DAEMON Fri Feb  4 20:17:03 2011<- EOF here

Shouldn't this be suppressed?  Or, otherwise, shouldn't

[> Status: RO]
[> Content-Length: 0]
[> Lines: 0]
>
>

be appended in case of an exception?  The current result does not comply to <http://qmail.org./man/man5/mbox.html> (which is linked by <http://tools.ietf.org/html/rfc4155>).  mutt(1) is still capable to open it (it modifies the mailbox as shown above, including bracket lines), but i don't know if that applies to all mail-clients out there.

----------

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

From report at bugs.python.org  Fri Feb  4 22:19:22 2011
From: report at bugs.python.org (James)
Date: Fri, 04 Feb 2011 21:19:22 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>


New submission from James <purpleidea at gmail.com>:

Hi distutils,

When I run:

./setup.py bdist --formats=rpm

on my source directory, I get the error:

rpm -ba --define _topdir /home/james/code/scantran/build/bdist.linux-x86_64/rpm --clean build/bdist.linux-x86_64/rpm/SPECS/scantran.spec
-ba: unknown option
error: command 'rpm' failed with exit status 1

It seems the problem can be fixed by installing the rpm-build package (on fedora 14 anyways) and so perhaps something should be done so that this is more obvious...

HTH,
James

----------
assignee: tarek
components: Distutils
messages: 127942
nosy: eric.araujo, purpleidea, tarek
priority: normal
severity: normal
status: open
title: bdist_rpm fails
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  4 22:23:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 21:23:42 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296854622.54.0.891112914721.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does this mean that there is one rpm command that does not have all options, and that rpm-build overwrites that command with another one that does the right thing?

----------

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

From report at bugs.python.org  Fri Feb  4 22:32:14 2011
From: report at bugs.python.org (James)
Date: Fri, 04 Feb 2011 21:32:14 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296855134.93.0.78353979213.issue11122@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

In the source for distutils it seems to attempt to use 'rpmbuild' if it exists, but otherwise falls back on regular 'rpm', however in my rpm:

$ rpm --version
RPM version 4.8.1

this fails as there is no -ba option.

James

----------

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

From report at bugs.python.org  Fri Feb  4 22:37:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 21:37:33 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296855453.85.0.291848023296.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What is your OS name and version?  Is that rpm version considered obsolete or not?

----------

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

From report at bugs.python.org  Fri Feb  4 22:56:02 2011
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 04 Feb 2011 21:56:02 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296856562.42.0.283285503819.issue11076@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

What's wrong with `vars(args)`? That's the standard way of getting a dict from an object, no?

Note that you're not always guaranteed to get a Namespace back (e.g. if you pass the namespace= argument to parse_args), and I'd generally like to keep Namespace as simple as possible.

----------

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

From report at bugs.python.org  Fri Feb  4 23:41:23 2011
From: report at bugs.python.org ($$Coffeepot$$)
Date: Fri, 04 Feb 2011 22:41:23 +0000
Subject: [issue11123] problem with packaged dependency extracter script, pdeps
In-Reply-To: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>
Message-ID: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>


New submission from $$Coffeepot$$ <coffeepottttttttt at yahoo.com>:

This bug concerns the pdeps script, <python directory>\Tools\Scripts\pdeps.py. This script opens a list of files and extracts a list of their inter-dependencies.

I'm running Python 3.1.1 on Windows XP, installed via binary installer, but have confirmed that the bug is present in the source distribution of Python 3.2 rc2, the newest code I know of. (In fact, the only difference between the pdeps.py files in each version was the shebang line, 3.2 rc2 shebang line: "#! /usr/bin/env python3", 3.1.1 shebang line: "#! /usr/bin/env python".)

When I tried out the module I found a series of small bugs, basically typos, each of which caused the script to crash due to an unhandled exception.

1.

The relevant section of the unmodified pdeps.py file
----
# Compiled regular expressions to search for import statements
#
m_import = re.compile('^[ \t]*from[ \t]+([^ \t]+)[ \t]+')
m_from = re.compile('^[ \t]*import[ \t]+([^#]+)')


# Collect data from one file
#
def process(filename, table):
...
        if m_import.match(line) >= 0:
            (a, b), (a1, b1) = m_import.regs[:2]
        elif m_from.match(line) >= 0:
            (a, b), (a1, b1) = m_from.regs[:2]
...

The match method of a compiled regular expression returns an SREMatch object, so the conditionals must be changed. In addition, the regs data is a member of the match object itself, not the compiled expression object, so the right side of the assignments must also be changed.

modified version
----
...
        import_match = m_import.match(line)
        from_match = m_from.match(line)
        if import_match:
            (a, b), (a1, b1) = import_match.regs[:2]
        elif from_match:
            (a, b), (a1, b1) = from_match.regs[:2]
...

2.

unmodified
----
# Invert a table (this is again totally general).
# All keys of the original table are made keys of the inverse,
# so there may be empty lists in the inverse.
#
def inverse(table):
    inv = {}
    for key in table.keys():
        if not inv.has_key(key):
            inv[key] = []
        for item in table[key]:
            store(inv, item, key)
    return inv

Dictionaries have no has_key method, though I vaguely recall that they used to. That's a quick fix though.

modified
----
# Invert a table (this is again totally general).
# All keys of the original table are made keys of the inverse,
# so there may be empty lists in the inverse.
#
def inverse(table):
    inv = {}
    for key in table.keys():
        if key in inv:
            inv[key] = []
        for item in table[key]:
            store(inv, item, key)
    return inv

output of fc, windows file comparing utility, run on the pdeps file from 3.2 rc2, and the modified pdeps file from 3.1.1
----
>fc original-pdeps.py pdeps.py
Comparing files original-pdeps.py and PDEPS.PY
***** original-pdeps.py 
#! /usr/bin/env python3

***** PDEPS.PY
#! /usr/bin/env python

*****

***** original-pdeps.py 
            line = line[:-1] + nextline
        if m_import.match(line) >= 0:
            (a, b), (a1, b1) = m_import.regs[:2]
        elif m_from.match(line) >= 0:
            (a, b), (a1, b1) = m_from.regs[:2]
        else: continue
***** PDEPS.PY
            line = line[:-1] + nextline
        import_match = m_import.match(line)
        from_match = m_from.match(line)
        if import_match:
            (a, b), (a1, b1) = import_match.regs[:2]
        elif from_match:
            (a, b), (a1, b1) = from_match.regs[:2]
        else: continue
*****

***** original-pdeps.py 
    for key in table.keys():
        if not inv.has_key(key):
            inv[key] = []
***** PDEPS.PY
    for key in table.keys():
        if key in inv:
            inv[key] = []
*****

With these changes the pdep script works as expected.

This is a pretty lower priority bug imho. It prevents anyone from using the script, but fixing the bug took about 5 minutes, and I doubt the pdeps script gets much use anyway. This bug is unlikely to inconvenience anyone.

----------
components: Demos and Tools
messages: 127947
nosy: $$Coffeepot$$
priority: normal
severity: normal
status: open
title: problem with packaged dependency extracter script, pdeps
type: crash
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Feb  4 23:45:24 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 04 Feb 2011 22:45:24 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296859524.79.0.249969637359.issue11122@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

"rpm -ba" is very old. I think it's been at least since 2002 that "-ba" was supported by rpm.

I believe bdist_rpm is calling "rpmbuild -ba", and if that doesn't exist, then "rpm -ba" is a transition strategy until all systems supported "rpmbuild". This transition period should be over. Unfortunately today it's far more likely that "rpm -ba" will not be what you want to call, but "rpm" will almost always be found, giving this error.

Most systems (certain RedHat based) ship rpmbuild as a separate command. RedHat installs it via the rpm-build package.

I'd suggest just switching bdist_rpm to always use rpmbuild. Then at least the error would be that rpmbuild isn't found.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sat Feb  5 00:12:06 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Feb 2011 23:12:06 +0000
Subject: [issue11123] problem with packaged dependency extracter script, pdeps
In-Reply-To: <1296859283.38.0.970778705728.issue11123@psf.upfronthosting.co.za>
Message-ID: <1296861126.9.0.733137353349.issue11123@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This script is indeed unusable. Here is a proper patch file, tested by running it on a few files.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file20681/pdeps.patch

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

From report at bugs.python.org  Sat Feb  5 00:12:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Feb 2011 23:12:21 +0000
Subject: [issue11124] test_posix failure on the Leopard buildbot
In-Reply-To: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>
Message-ID: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>


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

test_posix has started failing deterministically on the Leopard buildbot. Stephen, did you change something in its configuration?

http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.x/builds/786/steps/test/logs/stdio


======================================================================
FAIL: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_posix.py", line 390, in test_getgroups
    set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the first set but not the second:
108

----------
components: Library (Lib), Tests
messages: 127950
nosy: ixokai, ned.deily, pitrou, ronaldoussoren
priority: critical
severity: normal
status: open
title: test_posix failure on the Leopard buildbot
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Feb  5 00:17:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 23:17:43 +0000
Subject: [issue11111] See "Gmail" on your Google homepage
In-Reply-To: <000e0cd215a2adb38b049b6b1962@google.com>
Message-ID: <1296861463.2.0.0512276477819.issue11111@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20671/unnamed

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

From report at bugs.python.org  Sat Feb  5 00:17:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 23:17:46 +0000
Subject: [issue11111] See "Gmail" on your Google homepage
In-Reply-To: <1296785498.68.0.147871353188.issue11111@psf.upfronthosting.co.za>
Message-ID: <1296861466.38.0.0956520409721.issue11111@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg127856

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

From report at bugs.python.org  Sat Feb  5 00:33:34 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 04 Feb 2011 23:33:34 +0000
Subject: [issue11124] test_posix failure on the Leopard buildbot
In-Reply-To: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>
Message-ID: <1296862414.39.0.569982758137.issue11124@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

This is just http://bugs.python.org/issue7900 all over again.

In the meantime, I restarted the buildslave and re-submitted the jobs so the failures should go away. (I still advocate that the test is fundamentally wrong/flawed on Mac and should be disabled at least -- but that discussion is over on issue7900).

----------

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

From report at bugs.python.org  Sat Feb  5 00:34:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 23:34:10 +0000
Subject: [issue6958] Add Python command line flags to configure logging
In-Reply-To: <1253532197.53.0.626663388601.issue6958@psf.upfronthosting.co.za>
Message-ID: <1296862450.54.0.253781346666.issue6958@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think Antoine?s envvar idea was a good one, similar to PYTHONWARNINGS.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Feb  5 00:46:19 2011
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 04 Feb 2011 23:46:19 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1296863179.06.0.309112197409.issue7108@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I can confirm that this test has been failing on my slave, and that the patch fixes it. Recommend commit. Red is bad.

----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ixokai, ronaldoussoren

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

From report at bugs.python.org  Sat Feb  5 00:47:22 2011
From: report at bugs.python.org (Eric Smith)
Date: Fri, 04 Feb 2011 23:47:22 +0000
Subject: [issue11125] csv documentation should not use open() without close()
In-Reply-To: <1296863241.98.0.986933657012.issue11125@psf.upfronthosting.co.za>
Message-ID: <1296863241.98.0.986933657012.issue11125@psf.upfronthosting.co.za>


New submission from Eric Smith <eric at trueblade.com>:

Many places open() is shown as a parameter to a csv method, but close() can't be called. This is not a practice we should be advocating. Better would be to show a 'with' statement, or at least a note explaining this isn't an ideal usage.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 127954
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: csv documentation should not use open() without close()
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  5 00:50:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Feb 2011 23:50:35 +0000
Subject: [issue11125] csv documentation should not use open() without close()
In-Reply-To: <1296863241.98.0.986933657012.issue11125@psf.upfronthosting.co.za>
Message-ID: <1296863435.66.0.730549965321.issue11125@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed.  I have to take some time to update my patch on the other bug.  Hope you won?t mind me closing this one as duplicate.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Use with statement throughout the docs

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

From report at bugs.python.org  Sat Feb  5 01:00:48 2011
From: report at bugs.python.org (jtidman)
Date: Sat, 05 Feb 2011 00:00:48 +0000
Subject: [issue11126] Wave.py does not always write proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>


New submission from jtidman <jtidman at siliconcoral.com>:

wave.py does not always honor the sampwidth setting, especially on little endian machines.  If sampwidth is not one and big_endian is not set, then datawritten will not be muliplied by sampwidth, causing the header to be incorrect, and the file to appear to contain less data than it chould.

----------
components: Library (Lib)
files: patch.txt
messages: 127956
nosy: jtidman
priority: normal
severity: normal
status: open
title: Wave.py does not always write proper length in header
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20682/patch.txt

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

From report at bugs.python.org  Sat Feb  5 01:57:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Feb 2011 00:57:18 +0000
Subject: [issue9723] Add shlex.quote
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1296867438.92.0.758205189574.issue9723@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A note from Ian Bicking in http://mail.python.org/pipermail/stdlib-sig/2010-May/000948.html:

> I've had to do this sort of thing for similar reasons, like calling remote
> ssh commands, where a shell command is embedded in a positional argument.  I
> implemented my own thing, but the way pipes.quote works would have been
> nicer (the implementation could use a couple regexes instead of iterating
> over strings though).

----------

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

From report at bugs.python.org  Sat Feb  5 02:01:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Feb 2011 01:01:19 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296867679.02.0.431960956172.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a gray area between bugfix and bahavior change forbidden by the feature freeze.  Would it be okay for you to add a note in the docs and close this report?

----------
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Feb  5 02:02:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Feb 2011 01:02:31 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296867751.25.0.776751271873.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Would it be okay for you to add a note in the docs and close this report?

I meant to ask whether you would agree with that outcome, not that you should do the work (you?re welcome to provide a patch if you want to, but that?s not required).

----------

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

From report at bugs.python.org  Sat Feb  5 02:05:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:05:52 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1296867952.29.0.250570914388.issue9504@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems that my patch for issue10956 also fixes this issue (although it doesn't try to fix FileIO). It also has tests and fixes read() as well as write().
I'm sorry for not noticing that the two issues were so similar. Suggest closing this issue as duplicate.

----------
resolution:  -> duplicate
superseder:  -> file.write and file.read don't handle EINTR

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

From report at bugs.python.org  Sat Feb  5 02:06:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:06:30 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1296867990.53.0.965301929372.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I hadn't noticed that issue9504 is similar. The patch there does less things, although it also touches FileIO.readall().

----------

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

From report at bugs.python.org  Sat Feb  5 02:09:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 01:09:08 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296868148.71.0.0401050644068.issue11077@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Thread' is not found in the somewhat skimpy tkinter doc. Given the general state of Python with threads, I think it reasonable to take 'not thread-safe' as the default, making this a feature request. In any case, the point is moot until there is a tested fix. The use case presented, though, does make this look like a desireable new feature.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  5 02:12:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 01:12:56 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296868376.91.0.374767903041.issue11085@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

However done, I would prefer separation also.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  5 02:12:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:12:58 +0000
Subject: [issue9504] signal.signal/signal.alarm not working as expected
In-Reply-To: <1280910836.88.0.645209486589.issue9504@psf.upfronthosting.co.za>
Message-ID: <1296868378.74.0.878137043168.issue9504@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, bad analysis. The patch in issue10956 only seemed to work because my system is too fast and "find /" in the script returned in less than 5 seconds. Replacing it with "yes" shows that the two issued are actually independent.

----------
resolution: duplicate -> 
stage:  -> patch review
superseder: file.write and file.read don't handle EINTR -> 
versions: +Python 2.7

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

From report at bugs.python.org  Sat Feb  5 02:13:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:13:11 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1296868391.15.0.166462174639.issue10956@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
nosy: +neologix

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

From report at bugs.python.org  Sat Feb  5 02:21:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:21:29 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296868889.98.0.398796883883.issue11085@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Regarding the implementation, knowing your reluctance to turn modules
> into packages, I guess you?re talking about exposing collections.abc in 
> a similar manner to os.path, which is fine IMO.

That makes things confusing:

>>> import os.path
>>> os.path.__name__
'posixpath'

>>> import collections
>>> collections.Mapping
<class '_abcoll.Mapping'>

yikes?

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Feb  5 02:30:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 01:30:46 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1296869446.0.0.191647720561.issue7108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Feb  5 02:34:12 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 01:34:12 +0000
Subject: [issue11096] Multiple turtle tracers
In-Reply-To: <1296622965.34.0.0682804917272.issue11096@psf.upfronthosting.co.za>
Message-ID: <1296869652.51.0.774873217593.issue11096@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is only open for security fixes.

In 3.x "The methods Turtle.tracer(), Turtle.window_width() and Turtle.window_height() have been eliminated. Methods with these names and functionality are now available only as methods of Screen."

So it seems that perhaps the fix was to make what you did impossible ;-). Hence, I am inclined to close this as 'out-of-date'. The deletion was not done in 2.7 for back-compatibility reasons.

Replacing "    t.tracer(10)" with "\nScreen().tracer(10)", the rosette is drawn in under a second (on my several-year-old machine). I cannot see any difference.

----------
nosy: +gregorlingl, terry.reedy
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Feb  5 02:59:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 01:59:41 +0000
Subject: [issue1252236] Simplying Tkinter's event loop
Message-ID: <1296871181.25.0.474298650559.issue1252236@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

See 11077 for motivation for reopening.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  5 03:05:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 02:05:07 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296871507.85.0.411772987485.issue11103@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On my winxp system, 'open' opens with notepad, perhaps because I set that several years ago. I would like the installer to change that (and not change other stuff that it does change ;-).

The 'open with' submenu does include idle.

----------
nosy: +loewis, terry.reedy

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

From report at bugs.python.org  Sat Feb  5 03:11:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 05 Feb 2011 02:11:40 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296871900.12.0.101895816408.issue11085@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, I plead guilty of premature implementation talk.  The clean solution is just moving collections.py to collections/__init__.py and _abcoll.py to collections/abc.py, but I will defer to Raymond here.

----------

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

From report at bugs.python.org  Sat Feb  5 03:26:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Feb 2011 02:26:08 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296872768.12.0.364210637374.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Again, can you provide example input data and a short program that demonstrates the problem?  There's nothing I can reproduce in your report/question.  

As far as I noticed, the caught exceptions all occur at places where no output has yet been done to the mailbox/message.  If you have an example where this is not true, please point it out more specifically.

----------

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

From report at bugs.python.org  Sat Feb  5 03:32:22 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Feb 2011 02:32:22 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1296873142.21.0.898105761304.issue7074@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not a duplicate because this issue is about the stdlib turtle module doing something wrong and needing to be fixed. Also, this issue does not involve threads, at least none that I starting.

"It is not safe to call graphic primitives in event callbacks."

This is a confusing statement. The tutorial at
http://www.tkdocs.com/tutorial/canvas.html
by an experienced tk developer (19 years) includes this:

def addLine(event):
    global lastx, lasty
    canvas.create_line((lastx, lasty, event.x, event.y))
    lastx, lasty = event.x, event.y

Is canvas.create_line a primitive or not?

At the very least, unless I missed something, some change to turtle doc is needed.

----------
resolution: duplicate -> 
status: closed -> open

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

From report at bugs.python.org  Sat Feb  5 04:17:50 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 05 Feb 2011 03:17:50 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296875870.27.0.507481519968.issue11077@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

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

From report at bugs.python.org  Sat Feb  5 05:42:42 2011
From: report at bugs.python.org (Justin)
Date: Sat, 05 Feb 2011 04:42:42 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296880962.8.0.894675890375.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

I guess I didn't really explain the issue much. The problem is that if the server receives say, 10 requests at once, and then forks a process for each, after those processes finish they will sit as zombies until process_request() is called again, which calls collect_children(). So that patch simply moves the call to collect_children() into the serve_forever() loop so that it doesn't leave zombies sitting around.

----------

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

From report at bugs.python.org  Sat Feb  5 05:56:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Feb 2011 04:56:07 +0000
Subject: [issue11119] Passing a socket to a process (multiprocessing module)
In-Reply-To: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>
Message-ID: <1296881767.83.0.294464933486.issue11119@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib) -None
nosy: +asksol, jnoller
type: crash -> behavior

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

From report at bugs.python.org  Sat Feb  5 06:49:50 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 05 Feb 2011 05:49:50 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296884990.41.0.657078676528.issue9364@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric - your suggestions look good to me. 

The correspondence with Terry was on July 16th, 2010 - maybe he can remember which thread in pydev it was exactly.

----------

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

From report at bugs.python.org  Sat Feb  5 07:45:34 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Sat, 05 Feb 2011 06:45:34 +0000
Subject: [issue10911] cgi: add more tests
In-Reply-To: <1295040877.8.0.0807786274615.issue10911@psf.upfronthosting.co.za>
Message-ID: <1296888334.43.0.226545544002.issue10911@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

I opened issue #11066 for the code refactoring

----------

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

From report at bugs.python.org  Sat Feb  5 09:17:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 08:17:43 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296893863.22.0.904057334976.issue11109@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.1

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

From report at bugs.python.org  Sat Feb  5 09:25:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 08:25:07 +0000
Subject: [issue11119] Passing a socket to a process (multiprocessing module)
In-Reply-To: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>
Message-ID: <1296894307.36.0.53669843253.issue11119@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, sockets cannot be pickled on any platform:

>>> sock = socket.create_connection(("www.python.org", 80))
__main__:1: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
>>> s = pickle.loads(pickle.dumps(sock))
>>> s.getpeername()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
socket.error: getsockaddrlen: bad family
>>> s.fileno()
-1

The reason your code works under Linux is that multiprocessing uses fork() and therefore all objects and file handles are transparently inherited by the child. Windows doesn't have fork(), it instead spawns a new process to which it must marshal objects using pickle. You'll have to create your socket in the child for it to work at all.

By the way, multi-threading is much more appropriate than multi-processing when writing servers under Windows. Also, see the socketserver module for helpers to write both multi-threaded and multi-processed servers: http://docs.python.org/library/socketserver.html

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Sat Feb  5 09:30:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 08:30:26 +0000
Subject: [issue11127] sockets should not be pickleable
In-Reply-To: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>
Message-ID: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>


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

Like already done for file objects, sockets should refuse pickling by raising a TypeError.

----------
components: Library (Lib)
messages: 127976
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sockets should not be pickleable
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb  5 09:31:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 08:31:29 +0000
Subject: [issue11119] Passing a socket to a process (multiprocessing module)
In-Reply-To: <1296847463.51.0.1677089654.issue11119@psf.upfronthosting.co.za>
Message-ID: <1296894689.02.0.468767304383.issue11119@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Opened issue11127 for raising a TypeError when trying to pickle any socket.

----------
status: pending -> closed

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

From report at bugs.python.org  Sat Feb  5 10:29:06 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Feb 2011 09:29:06 +0000
Subject: [issue11124] test_posix failure on the Leopard buildbot
In-Reply-To: <1296861141.91.0.462525688325.issue11124@psf.upfronthosting.co.za>
Message-ID: <1296898146.35.0.381811970222.issue11124@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> posix.getgroups() failure on Mac OS X

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

From report at bugs.python.org  Sat Feb  5 10:50:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Feb 2011 09:50:00 +0000
Subject: [issue1227748] subprocess: inheritance of std descriptors inconsistent
Message-ID: <1296899400.38.0.352820536683.issue1227748@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: astrand -> docs at python
nosy: +docs at python
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Feb  5 12:02:30 2011
From: report at bugs.python.org (Virgil Dupras)
Date: Sat, 05 Feb 2011 11:02:30 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296903750.71.0.247062364954.issue11076@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

I didn't know about vars() (well, I knew it existed, but never was quite sure what it did).

Given that I'm not a Python newbie, I'm guessing I'm not alone in this situation. Maybe that instead of making the Namespace iterable, we should just add an example usage of vars() in argparse's documentation?

----------

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

From report at bugs.python.org  Sat Feb  5 12:18:56 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 11:18:56 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296904736.33.0.600778804886.issue11077@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

My claim is that Tkinter is thread-safe as it stands. A lot of thought has been put into making Tkinter thread-safe, so if there is any claim to the contrary, we would need more details: what exact Python version is being used, what exact operating system is being used, what exact code is run, and what exact output is produced.

----------
nosy: +loewis

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

From report at bugs.python.org  Sat Feb  5 12:24:47 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 11:24:47 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1296905087.93.0.828593160086.issue11103@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Terry, if you are installing Python "for all users", but have the Open rebound just for yourself, it is unreasonable to expect that the Python installation procedure changes it. Per-user settings override machine settings; this is by Microsoft design.

Darren: did you install "for all users" or "just for me"?

----------

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

From report at bugs.python.org  Sat Feb  5 12:46:52 2011
From: report at bugs.python.org (Scott M)
Date: Sat, 05 Feb 2011 11:46:52 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296904736.33.0.600778804886.issue11077@psf.upfronthosting.co.za>
Message-ID: <000a01cbc52a$5c662f10$15328d30$@mayo@comcast.net>


Scott M <scott.mayo at comcast.net> added the comment:

I'll look into making the crash easier to reproduce this coming week.

Is Tkinter's thread safety new? Because after I started getting crashes, I did my due diligence in Google and found a number of people writing about how it was necessary to use a Queue and Tkinter's after() timer, to draw from multiple threads. And in experiments in 2.7.1 on Windows, it turned out that it wasn't just the drawing calls from a thread other than the mainloop() thread, that invited a crash; even just trying to set an .after() timer from a different thread caused tracebacks, randomly.

At any rate this is less of an issue now, for me at least. I'm putting together a small graphic library for my coworkers. It will have a tiny fraction of Tkinter's capabilities, it will be Windows-only and won't even have native Windows look and feel; but it will be completely, rock-solid, idiot-proof thread safe - any operation (including widget deletes), any thread, any time, with no polling or timers needed. My coworkers are not technical and will get instantly lost if I have to describe queues and timers just to draw a line on a screen.

----------

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

From report at bugs.python.org  Sat Feb  5 13:08:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 12:08:10 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <000a01cbc52a$5c662f10$15328d30$@mayo@comcast.net>
Message-ID: <4D4D3DA8.8090906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is Tkinter's thread safety new?

It's supported on Unix since 1.5.1, and on Windows since 2.3.

----------

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

From report at bugs.python.org  Sat Feb  5 13:09:42 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 05 Feb 2011 12:09:42 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296907782.72.0.570380805079.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Well, here is the long-asked-for 'fp_mailbox.py' test thing.
Note: it generates a 'test.mbox' in CWD!

    print("USAGE: fp_mailbox.py 0|1|2",
          "       0 = use raw UTF-8 string",
          "       1 = use UTF-8 string",
          "       2 = use escaped byte string", sep="\n")

It does not use FeedParser directly, but email.message_from_*.  It's simple minded, but a dumb new python(1) user (like me) does not know otherwise, i guess.  Of course the input is malformed, but, you know, shit happens (you may trust me in respect to that).  I want to point out that .defects is the empty list, even though the input is *not* correctly converted (quopri/base64) and blows mailbox.add later on for test cases 0 and 1 (resulting in corrupted mailbox files).  2 does not cause a traceback and is mailbox.add()ed, but the resulting mail is not standart-conforming either.  For me and my (S-)Postman all of this means that i have to encapsulate all of this with a 'MessageBuilder' layer on top of the python(1) builtin email package.



  I personally will encapsulate the email.* stuff with a MessageBuilder

----------
Added file: http://bugs.python.org/file20683/fp_mailbox.py

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

From report at bugs.python.org  Sat Feb  5 13:36:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 05 Feb 2011 12:36:35 +0000
Subject: [issue11046] setup.py/configure [darwin]
In-Reply-To: <1296224784.81.0.0525228154056.issue11046@psf.upfronthosting.co.za>
Message-ID: <1296909395.96.0.85678490714.issue11046@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

ronaldoussoren: thanks for the MACOSX_DEPLOYMENT_TARGET=10.5 hint!!  I did Py3K yesterday, and it was a matter of 'configure --prefix=x YZ && make && make install' as if it were a real UNIX!

I *really* think there should be a configure command line option for this thing - i would *not* have found that out on my own!

And of course the problem with libedit is it's ignorance for a long-time-grown multi-UNIX multi-term '.inputrc'.

----------

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

From report at bugs.python.org  Sat Feb  5 13:36:42 2011
From: report at bugs.python.org (Scott M)
Date: Sat, 05 Feb 2011 12:36:42 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296909402.12.0.323426248731.issue11077@psf.upfronthosting.co.za>


Scott M <scott.mayo at comcast.net> added the comment:

The new version runs 40 parabolas, then quits. I usually have to run this version 20 times or so to get the crash, so be patient. In general if it's going to crash it does so in the first 6 or so parabolas. Caveat: creates up to 40 threads, so a bit of a CPU pig. You may want to change the 40 in (self.tracks > 40) to 8.

Here's one crash. I got this by double clicking the .py file from Windows explorer, but I can get them with F5 in IDLE too.
---
UpdateStringProc should not be invoked for type cmdName

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Exception in thread Thread-6:
Traceback (most recent call last):
  File "C:\Python27\lib\threading.py", line 530, in __bootstrap_inner
    self.run()
  File "H:\PMT2\MyProjects\TkinterCrash2.py", line 47, in run
    self.deliverToQueue((self.target, z, y))
  File "H:\PMT2\MyProjects\TkinterCrash2.py", line 129, in arrival_122
    new_yz[1])
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2201, in create_line
    return self._create('line', args, kw)
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 2189, in _create
    *(args + self._options(cnf, kw))))
TclError: bad screen distance "create"

----------
versions: +Python 2.7 -Python 3.3
Added file: http://bugs.python.org/file20684/TkinterCrash2.py

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

From report at bugs.python.org  Sat Feb  5 14:06:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 13:06:49 +0000
Subject: [issue11128] decimal.py: to_integral() corner cases
In-Reply-To: <1296911209.51.0.925327858699.issue11128@psf.upfronthosting.co.za>
Message-ID: <1296911209.51.0.925327858699.issue11128@psf.upfronthosting.co.za>


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

Hi,

to_integral() should behave like quantize() for negative exponents:

"Otherwise (the operand has a negative exponent) the result is the
 same as using the quantize operation using the given operand as the
 left-hand-operand, 1E+0 as the right-hand-operand, and the precision
 of the operand as the precision setting. The rounding mode is taken
 from the context, as usual."


There are some corner cases where this matters:


>>> from decimal import *
>>> c = Context(prec=1, Emin=-1, Emax=1, traps=[])
>>> d = Context(prec=4, Emin=-1, Emax=1, traps=[])
>>> 
>>> c.to_integral(Decimal("999.9"))
Decimal('1000')
>>> d.quantize(Decimal("999.9"), Decimal("1e0"))
Decimal('NaN')


Indeed, decNumber returns NaN for to_integral(). This is an odd
situation, since for the result it is possible to exceed the
precision but not Emax:


>>> c = Context(prec=3, Emin=-3, Emax=3, traps=[])
>>> d = Context(prec=4, Emin=-3, Emax=3, traps=[])
>>> c.to_integral(Decimal("999.9"))
Decimal('1000')
>>> d.quantize(Decimal("999.9"), Decimal("1e0"))
Decimal('1000')


The specification is on the side of decNumber, but I wonder if this is
an oversight.

----------
components: Library (Lib)
messages: 127986
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: to_integral() corner cases
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Feb  5 14:42:06 2011
From: report at bugs.python.org (David Beazley)
Date: Sat, 05 Feb 2011 13:42:06 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296913326.37.0.0434885291471.issue11117@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Anyone contemplating the use of aio_ functions should first go read "The Story of Mel".

http://www.catb.org/jargon/html/story-of-mel.html

----------
nosy: +dabeaz

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

From report at bugs.python.org  Sat Feb  5 14:47:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 13:47:10 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296913630.87.0.12315092204.issue11077@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce either, but the latest traceback posted in msg127985 seems to hint at a parameter marshalling problem. "create" is one of the parameters to the called Tk function, but it seemed to be mistaken for another.

Since it's arguably threading-related, saying "I can't reproduce" doesn't seem like a sufficient reason to close the issue. There can be all kinds of influencing factors (OS, CPU, background tasks) and the marshalling code in Modules/_tkinter.c is far from trivial.

----------
nosy: +amaury.forgeotdarc, pitrou
type: feature request -> crash

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

From report at bugs.python.org  Sat Feb  5 15:05:25 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sat, 05 Feb 2011 14:05:25 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296914725.97.0.339244887668.issue11063@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

I think launching external tools like ifconfig and ipconfig can be avoided pretty easily. There are many recipes around the net how to use native API's.
About ctypes' horrible logic during find_library call - don't know yet.

----------
nosy: +nvetoshkin

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

From report at bugs.python.org  Sat Feb  5 15:11:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 05 Feb 2011 14:11:57 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296915117.37.0.606657508627.issue11117@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Thanks, David, for the link. The story is really touching :-).

----------

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

From report at bugs.python.org  Sat Feb  5 15:22:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 14:22:25 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296915745.62.0.593383368161.issue11077@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Tk produces "bad screen distance" in Tk_GetScreenMM (convert string to screen millimeters) and TkGetDoublePixels (convert string to number of pixels) when strtod fails on the string being passed. It also produces the error in SetPixelAny (convert object to pixel) if the string doesn't start with a double, and SetMMFromAny (convert object to millimeters) if the string either is no double, or not followed by "[cimp]". Finally, TkPixelParseProc returns the error if TkGetDoublePixels returns a negative number.

In relationship to the canvas line command, TkPixelParseProc is used for converting the -width, -activewidth, and -disabledwidth arguments. None of these are used in the test case, though, so it's not clear which pixel parsing fails specifically.

----------

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

From report at bugs.python.org  Sat Feb  5 15:44:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Feb 2011 14:44:42 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>


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

When configuration is specified in external file, qualname attribute should allow several values. Maybe comma separated.

----------
messages: 127992
nosy: techtonik
priority: normal
severity: normal
status: open
title: logging: allow multiple entries in qualname config
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  5 15:49:01 2011
From: report at bugs.python.org (Scott M)
Date: Sat, 05 Feb 2011 14:49:01 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296915745.62.0.593383368161.issue11077@psf.upfronthosting.co.za>
Message-ID: <000b01cbc543$ce3a7790$6aaf66b0$@mayo@comcast.net>


Scott M <scott.mayo at comcast.net> added the comment:

If it helps, over the many iterations of this test code, there have been two kinds of issues:

1. pythonw.exe crashes with the Windows variant of a SEGV. No traceback, just a crash. These are rare.

2. Evidence of confusion over which string the code should be looking at, and it's always down in the create function of Tkinter. Variations of this confusion have been Int() complaining that it can't translate "None", strings like ".667748474.7464" not being recognized as parameter names...  all of it sounds like Tkinter has somehow managed to be looking at the wrong string. Even when the only Tkinter call I do outside the mainloop thread is .after(), the crashes would happen when I went to draw a line.

My (trivial) experience in extending Python makes me wonder if some reference count, somewhere, didn?t get mismanaged. The only times I ever got a hard crash out pythonw.exe in my own projects is when I mishandled a count.

As a side note, if Tkinter is intended to be thread safe, the documentation should say so. Clearly, and in the first paragraph. Once I started having problems, I started Googling, and everything I read lead me to conclude that neither Tkinter nor wx were even intended to be thread safe, so I've started to write my own GUI code. This is a project I might have skipped if it has been clear that Tkinter is at least intended to be thread safe.

----------

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

From report at bugs.python.org  Sat Feb  5 15:54:42 2011
From: report at bugs.python.org (David Beazley)
Date: Sat, 05 Feb 2011 14:54:42 +0000
Subject: [issue11117] Implementing Async IO
In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za>
Message-ID: <1296917682.66.0.864908636788.issue11117@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Glad you liked it!   I think there is a bit of a cautionary tale in there though. With aio_, there is the promise of better performance, but you're also going to need a *LOT* of advance planning and thought to avoid creating a tangled coding nightmare with it.

Just as an aside, one of the uses of aio_ related functions is to implement parts of user-level thread libraries in C (e.g., pthreads, etc.). A library might use the asynchronous I/O callbacks as part of implementing non-kernel (green) threads.  The code for doing this tends to be very low level and hairy with lots of signal handling--for example, if you want to context-switch between two user-level threads in C, you usually do it inside a signal handler (i.e., you thread-switch inside the signal handler called in response to aio_ completions). 

Whether it's feasible to expose aio_* all the way up to Python or not is an open question. I suspect it will be fraught with lots of tricky issues. In the end, it might just be easier to use threads.  Nevertheless, you'll learn a lot about Python internals by working on this :-).

----------

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

From report at bugs.python.org  Sat Feb  5 16:21:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 15:21:43 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296919303.13.0.0120885436984.issue11077@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The "UpdateStringProc should not be invoked for type cmdName" message (as quoted above in the traceback) apparently can mean that there's a mismanagement of Tcl reference counts.

>From http://sourceforge.net/tracker/?func=detail&atid=110894&aid=1326087&group_id=10894:

?This crash (actually, a panic) hints at defective Tcl_Obj
handling - possibly in the core, more likely in an extension
if you're using one. It indicates that Tcl_GetString() or
Tcl_GetStringFromObj() has been called on a cmdNameType
Tcl_Obj that has no string representation, a state that
should never occur.?

Intuitively, cmdNameType seems to refer to createcommand() / deletecommand(). Also, the following code in Tkinter.py looks a bit suspicious:

    def after(self, ms, func=None, *args):
        """Call function once after given time.

        MS specifies the time in milliseconds. FUNC gives the
        function which shall be called. Additional parameters
        are given as parameters to the function call.  Return
        identifier to cancel scheduling with after_cancel."""
        if not func:
            # I'd rather use time.sleep(ms*0.001)
            self.tk.call('after', ms)
        else:
            def callit():
                try:
                    func(*args)
                finally:
                    try:
                        self.deletecommand(name)
                    except TclError:
                        pass
            name = self._register(callit)
            return self.tk.call('after', ms, name)

That is, we call deletecommand() while the command is still being executed.
Perhaps that, together with concurrent memory allocation from another thread (Tcl_Alloc() doesn't use Python's "Tcl lock"), might explain why the cmdName or other things sometimes become corrupted ("Tcl_DeleteCommand deletes a command from a command interpreter. Once the call completes, attempts to invoke cmdName in interp will result in errors").

----------

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

From report at bugs.python.org  Sat Feb  5 16:28:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 15:28:33 +0000
Subject: [issue11077] Tkinter is not thread safe
In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za>
Message-ID: <1296919713.84.0.946309757939.issue11077@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As a side note, if Tkinter is intended to be thread safe, the 
> documentation should say so. Clearly, and in the first paragraph.

I'm no Tkinter specialist but, judging by its source code, Tkinter (the Python module) *is* intended to be thread-safe using locking and/or marshalling.

As for wxPython, you are right that it is not thread safe.

----------

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

From report at bugs.python.org  Sat Feb  5 16:33:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Feb 2011 15:33:21 +0000
Subject: [issue5285] hmac throws TypeErrors
In-Reply-To: <1234827307.61.0.0730804396483.issue5285@psf.upfronthosting.co.za>
Message-ID: <1296920001.65.0.926207846993.issue5285@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This damn bug ruined my day. MoinMoin couldn't reset password on many outdated wikies < 1.8.2 (including Python's one probably), because of it.

http://moinmo.in/MoinMoinBugs/1.8_ResetPasswordError

----------
nosy: +techtonik

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

From report at bugs.python.org  Sat Feb  5 16:55:52 2011
From: report at bugs.python.org (Kenny Meyer)
Date: Sat, 05 Feb 2011 15:55:52 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296921352.35.0.606608954019.issue11063@psf.upfronthosting.co.za>


Kenny Meyer <knny.myer at gmail.com> added the comment:

With the attached patch the "heavy work" will be done on request, when calling uuid1() or uuid4() not on import.

I am working off from the py3k svn branch. Is it necessary to submit a separate patch for py2 branch?

----------
keywords: +patch
nosy: +knny-myer
Added file: http://bugs.python.org/file20685/issue11063.patch

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

From report at bugs.python.org  Sat Feb  5 17:57:25 2011
From: report at bugs.python.org (ProgVal)
Date: Sat, 05 Feb 2011 16:57:25 +0000
Subject: [issue11130] SocketServer: server_address is... a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>


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

Hello,

I have issues with a script I'm programming (TypeError at every client connection), so I edited BaseServer's __init__():
    def __init__(self, server_address, RequestHandlerClass):
        """Constructor.  May be extended, do not override."""
        if isinstance(server_address, socket._socketobject):
            raise Exception()
        self.server_address = server_address
        self.RequestHandlerClass = RequestHandlerClass
        self.__is_shut_down = threading.Event()
        self.__shutdown_request = False
And it raises sometimes this traceback:
Exception happened during processing of request from ('127.0.0.1', 32810)
Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 285, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 311, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 324, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.6/SocketServer.py", line 400, in __init__
    BaseServer.__init__(self, server_address, RequestHandlerClass)
  File "/usr/lib/python2.6/SocketServer.py", line 198, in __init__
    raise Exception()

Best regards,
ProgVal

----------
components: Library (Lib)
messages: 127999
nosy: ProgVal
priority: normal
severity: normal
status: open
title: SocketServer: server_address is... a socket
versions: Python 2.6

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

From report at bugs.python.org  Sat Feb  5 17:59:46 2011
From: report at bugs.python.org (ProgVal)
Date: Sat, 05 Feb 2011 16:59:46 +0000
Subject: [issue11130] SocketServer: server_address is... a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296925186.84.0.368027745204.issue11130@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

The problem happens on Python 2.7 too.

Additionaly, here is the traceback, if I don't edit the library:
Exception happened during processing of request from ('127.0.0.1', 50378)
Traceback (most recent call last):
  File "/usr/lib/python2.7/SocketServer.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python2.7/SocketServer.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python2.7/SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python2.7/SocketServer.py", line 408, in __init__
    self.server_bind()
  File "/usr/lib/python2.7/SocketServer.py", line 419, in server_bind
    self.socket.bind(self.server_address)
  File "/usr/lib/python2.7/socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
TypeError: getsockaddrarg: AF_INET address must be tuple, not _socketobject

----------
versions: +Python 2.7

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

From report at bugs.python.org  Sat Feb  5 18:10:37 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 05 Feb 2011 17:10:37 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296925837.23.0.798150265042.issue11063@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Kenny, I don't see a problem with uuid is *imported*, it just creates a couple of STANDARD UUID class objects for use later. And this seems to just set the number and validates it. I don't see any subprocess calls performed. Perhaps you were referring to scenarios of using uuid1/uuid5 methods in mac and suggesting improvements to it by your patch?

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sat Feb  5 18:12:21 2011
From: report at bugs.python.org (ProgVal)
Date: Sat, 05 Feb 2011 17:12:21 +0000
Subject: [issue11130] SocketServer: server_address is... a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296925941.73.0.695466140646.issue11130@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

This seems odd to me: this line:
        self.RequestHandlerClass(request, client_address, self)
calls TCPServer's constructor:
    def __init__(self, server_address, RequestHandlerClass, bind_and_activate=True):

----------

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

From report at bugs.python.org  Sat Feb  5 18:14:15 2011
From: report at bugs.python.org (ProgVal)
Date: Sat, 05 Feb 2011 17:14:15 +0000
Subject: [issue11130] SocketServer: server_address is... a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296926055.0.0.0920973960688.issue11130@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

Oooooh, excuse me, it's because of my code!

class MyRequestHandler(SocketServer.TCPServer):

----------
resolution:  -> invalid

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

From report at bugs.python.org  Sat Feb  5 18:15:46 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 05 Feb 2011 17:15:46 +0000
Subject: [issue11130] SocketServer: server_address is... a socket
In-Reply-To: <1296925045.21.0.871869148371.issue11130@psf.upfronthosting.co.za>
Message-ID: <1296926146.05.0.976446047008.issue11130@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Unable to determine the bug here. If you have questions with using python, please ask python-list at python.org

----------
nosy: +orsenthil
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sat Feb  5 18:41:13 2011
From: report at bugs.python.org (James)
Date: Sat, 05 Feb 2011 17:41:13 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296927673.07.0.820553543995.issue11122@psf.upfronthosting.co.za>


James <purpleidea at gmail.com> added the comment:

I'll write a docs and script patch for this next week...

I'm happy to do the work,

Thanks for the comments.

James

----------

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

From report at bugs.python.org  Sat Feb  5 18:47:54 2011
From: report at bugs.python.org (yeswanth)
Date: Sat, 05 Feb 2011 17:47:54 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296928074.43.0.11788006116.issue9364@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

Suggestions are good . One thing I came across when going through the doc is that when you run help(help) after importing help from pydoc , i noticed that the first line of the help utility is 

"""
Welcome to Python 3.2!  This is the online help utility.
"""
which could be changed to 

"Welcome to Python help utility" as the help utility is already inbuilt .

----------
nosy: +swamiyeswanth

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

From report at bugs.python.org  Sat Feb  5 19:04:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 18:04:49 +0000
Subject: [issue11131] decimal.py: plus/minus with ROUND_FLOOR
In-Reply-To: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>
Message-ID: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>


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

Another exciting corner case in plus/minus:

"The operations are evaluated using the same rules as add and subtract;
 the operations plus(a) and minus(a) (where a and b refer to any numbers)
 are calculated as the operations add(?0?, a) and subtract(?0?, b)
 respectively, where the ?0? has the same exponent as the operand."


But add and subtract have a special rule for the sign with ROUND_FLOOR:

"Otherwise, the sign of a zero result is 0 unless either both operands 
 were negative or the signs of the operands were different and the 
 rounding is round-floor."


So, +Decimal("-0") and -Decimal("0") should be a negative zero. I checked
this against decNumber. Currently:


>>> c = getcontext()
>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('0')
>>> -Decimal("0")
Decimal('0')

----------
components: Library (Lib)
messages: 128007
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: decimal.py: plus/minus with ROUND_FLOOR
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Feb  5 19:30:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Feb 2011 18:30:55 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296930655.83.0.0295848583743.issue11063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you do 'python -c "import uuid" under strace, _posixsubprocess is definitely loaded, and a pipe2 call is made.

Take a look at the code starting at (py3k trunk) line 418 (try:).  That's where the weird stuff happens, which is what the patch is addressing.

Ken: thanks for working on this.

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Sat Feb  5 19:43:43 2011
From: report at bugs.python.org (yeswanth)
Date: Sat, 05 Feb 2011 18:43:43 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296931423.38.0.898701186538.issue9364@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

Patch for the change i have suggested in pydoc .
@Eric I will try to implement the patch suggestions you have made. I still have to figure out how to make crosslinks

----------
keywords: +patch
Added file: http://bugs.python.org/file20686/pydoc.diff

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

From report at bugs.python.org  Sat Feb  5 19:44:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 18:44:33 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296931473.31.0.982628221128.issue11063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for posting a patch! I have two comments:
- Have you run test_uuid? When I run it, it seems to go into an infinite loop somewhere and I need to kill the process.
- uuid should work even when ctypes is not available, so you can't just put an import statement at the top-level without a fallback

----------
nosy: +pitrou
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Feb  5 19:51:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 05 Feb 2011 18:51:15 +0000
Subject: [issue11127] sockets should not be pickleable
In-Reply-To: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>
Message-ID: <1296931875.85.0.0260514939496.issue11127@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sat Feb  5 19:53:46 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 05 Feb 2011 18:53:46 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296932026.06.0.17447416005.issue11109@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Sat Feb  5 19:54:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Feb 2011 18:54:40 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1296932080.34.0.337221733745.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks, much easier to communicate when runnable code is involved :) Now I can see what you mean about it writing the From.  I will figure out why and fix it so that the From line is not written.

The traceback from email.generator is unfortunate.  I should have message_from-string reject non-ASCII input with a clear error message like mailbox.add does now, but I didn't think of it.  I will see if the release manager will let me make that change.

For case (2) it is working as designed: faithfully writing the non-conformant message to the mbox.  If you wish to do other sorts of handling of non-conformant email you need to write code to do that.  You can use the email package to make it technically conformant (and ASCII only) by doing something like message_from_string(str(message_from_bytes(non_conformant_message)))  I'm not sure why you'd want to do that, though :)

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Feb  5 20:01:57 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sat, 05 Feb 2011 19:01:57 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296932517.45.0.760389159377.issue11063@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

>uuid should work even when ctypes is not available
A bit of offtopic: why can't we assume that ctypes is available?

----------

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

From report at bugs.python.org  Sat Feb  5 20:04:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 19:04:58 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296932698.79.0.262448888267.issue11063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> A bit of offtopic: why can't we assume that ctypes is available?

Because ctypes (or, actually, the libffi it relies on) needs specific low-level code for each platform it runs on, and not all platforms have such code.

Another reason is that ctypes is dangerous and some administrators might prefer to disable it (especially on shared hosting ala Google App Engine).

----------

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

From report at bugs.python.org  Sat Feb  5 20:13:31 2011
From: report at bugs.python.org (Gerard van Helden)
Date: Sat, 05 Feb 2011 19:13:31 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1296933211.29.0.701475090302.issue9334@psf.upfronthosting.co.za>


Gerard van Helden <dremeltje at gmail.com> added the comment:

The reporter imho is 100% right. Simply because of the fact that in the current situation, there is no way to supply an argument starting with a dash (not even for instance a filename). That is, of course, total nonsense to be dictated by the parser library.

----------
nosy: +drm

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

From report at bugs.python.org  Sat Feb  5 20:14:41 2011
From: report at bugs.python.org (Kenny Meyer)
Date: Sat, 05 Feb 2011 19:14:41 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296932698.79.0.262448888267.issue11063@psf.upfronthosting.co.za>
Message-ID: <AANLkTinx-wuBWNbsj-dhjZVwAMaacG1Ag32hcz6g71Ne@mail.gmail.com>


Kenny Meyer <knny.myer at gmail.com> added the comment:

Thanks for pointing that out! I guess that is the reason you did the import
in a try block.

----------
Added file: http://bugs.python.org/file20687/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________
-------------- next part --------------
<font face="courier new,monospace">Thanks</font> for pointing that out! I guess that is the reason you did the import in a try block.<br>

From report at bugs.python.org  Sat Feb  5 20:15:00 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sat, 05 Feb 2011 19:15:00 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296933300.26.0.362233450347.issue11063@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Maybe I understood and ctypes ImportError simply must be handled and fallbacked to something else. But there are only 3 ways of getting MAC address:
1. using popen
2. using ctypes and native calls
3. using C API and performing native calls in extension

And ctypes seems to be the best choice: it's portable across Python VMs (better that 3) and faster (better than 1).

----------

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

From report at bugs.python.org  Sat Feb  5 20:17:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 19:17:43 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296933300.26.0.362233450347.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296933459.3736.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Maybe I understood and ctypes ImportError simply must be handled and
> fallbacked to something else.

Indeed.

> But there are only 3 ways of getting MAC address:
> 1. using popen
> 2. using ctypes and native calls
> 3. using C API and performing native calls in extension
> 
> And ctypes seems to be the best choice: it's portable across Python
> VMs (better that 3) and faster (better than 1).

Perhaps, but doing without ctypes should still be possible, otherwise
it's a regression.

----------

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

From report at bugs.python.org  Sat Feb  5 20:23:23 2011
From: report at bugs.python.org (Keith Dart)
Date: Sat, 05 Feb 2011 19:23:23 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296933803.44.0.34540541543.issue11063@psf.upfronthosting.co.za>


Keith Dart <keith at dartworks.biz> added the comment:

It's also possible using existing wrapped os system calls. One exaple is here: http://code.google.com/p/pycopia/source/browse/trunk/aid/pycopia/ifconfig.py

Although that one doesn't current support MAC addresses, but it could. The socket module also now support the netlink socket on Linux, so it shouldbe possible to use that for getting MAC address on Linux.

----------

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

From report at bugs.python.org  Sat Feb  5 20:27:42 2011
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sat, 05 Feb 2011 19:27:42 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296934062.07.0.851472781134.issue11063@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

>It's also possible using existing wrapped os system calls.
That's right, on linux we can use ioctls but windows would require win api calls like this one: http://stackoverflow.com/questions/166506/finding-local-ip-addresses-in-python/166992#166992

----------

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

From report at bugs.python.org  Sat Feb  5 20:31:36 2011
From: report at bugs.python.org (Kenny Meyer)
Date: Sat, 05 Feb 2011 19:31:36 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296934296.48.0.499666538703.issue11063@psf.upfronthosting.co.za>


Changes by Kenny Meyer <knny.myer at gmail.com>:


Removed file: http://bugs.python.org/file20687/unnamed

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

From report at bugs.python.org  Sat Feb  5 20:41:24 2011
From: report at bugs.python.org (Keith Dart)
Date: Sat, 05 Feb 2011 19:41:24 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296934884.56.0.755379155489.issue11063@psf.upfronthosting.co.za>


Keith Dart <keith at dartworks.biz> added the comment:

I'm thinking Python could use a general purpose ifconfig/mac-layer module that uuid.py could then just use.

----------

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

From report at bugs.python.org  Sat Feb  5 20:42:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 19:42:46 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296934884.56.0.755379155489.issue11063@psf.upfronthosting.co.za>
Message-ID: <1296934963.3736.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm thinking Python could use a general purpose ifconfig/mac-layer
> module that uuid.py could then just use.

Perhaps, but that's really out of scope for this issue. Feel free to
open another issue.

----------

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

From report at bugs.python.org  Sat Feb  5 21:27:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 20:27:09 +0000
Subject: [issue11121] libpython3.so support with --enable-shared
In-Reply-To: <1296849778.85.0.812666506214.issue11121@psf.upfronthosting.co.za>
Message-ID: <1296937629.95.0.417853767024.issue11121@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the review. Committed as r88350.

----------
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Sat Feb  5 21:36:14 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 05 Feb 2011 20:36:14 +0000
Subject: [issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
In-Reply-To: <1296336887.12.0.12161660566.issue11067@psf.upfronthosting.co.za>
Message-ID: <1296938174.94.0.00404031880166.issue11067@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the review. Committed as r88351.

----------
status: open -> closed

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

From report at bugs.python.org  Sat Feb  5 21:44:05 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 05 Feb 2011 20:44:05 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296938645.53.0.54197243873.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment provides a complete test suite.
It also fixes a problem which occurred on BSD platforms when using non-blocking sockets: EAGAIN/EBUSY are now raised if the transmitted data == 0 bytes reflecting socket's send() behavior:

+    if (ret < 0) {
+        if ((errno == EAGAIN) || (errno == EBUSY)) {
+            if (sbytes != 0) {
+                // some data has been sent
+                goto done;
+            }
+            else {
+                // no data has been sent; upper application is supposed
+                // to retry on EAGAIN or EBUSY
+                return posix_error();
+            }
+        }
+        return posix_error();
+    }
+    goto done;

The test suite shows that "trailer" argument does not work.
I couldn't manage to figure out what's wrong though.

----------
Added file: http://bugs.python.org/file20688/sendfile_v6.patch

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

From report at bugs.python.org  Sat Feb  5 21:54:38 2011
From: report at bugs.python.org (Eric Smith)
Date: Sat, 05 Feb 2011 20:54:38 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1296939278.25.0.584115216734.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

While I also dislike the existing behavior, note that you can get what you want by using an equal sign.

>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default=''
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '-1'])
Namespace(asciidoc_opts='-1')
>>> parser.parse_args(['--asciidoc-opts=-one'])
Namespace(asciidoc_opts='-one')

I always use the equal sign, so I've never noticed this behavior before.

I wish that help would display the equal sign, but that's another issue.

----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Sat Feb  5 21:59:25 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Feb 2011 20:59:25 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296939565.14.0.395842306517.issue11109@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Rather than depending on the internal details of ForkingMixIn in your BaseServer.serve_forever modification I'd prefer to see that simply call self._cleanup()

Define a do-nothing _periodic_cleanup method in BaseServer.  ForkingMixIn should implement its own _periodic_cleanup method that does the active_children test and calls collect_children as appropriate.

----------

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

From report at bugs.python.org  Sat Feb  5 22:10:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 21:10:40 +0000
Subject: [issue7108] test_commands.py failing on OS X 10.5.7 due to '@' in ls
	output
In-Reply-To: <1255304015.86.0.913588485284.issue7108@psf.upfronthosting.co.za>
Message-ID: <1296940240.33.0.284117273019.issue7108@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: ronaldoussoren -> 

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

From report at bugs.python.org  Sat Feb  5 22:31:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Feb 2011 21:31:41 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1296941501.99.0.624853583918.issue11085@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll use the packaging approach.  The os.path technique predated packages and is no longer the preferred way of doing things.

----------

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

From report at bugs.python.org  Sat Feb  5 22:49:28 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Feb 2011 21:49:28 +0000
Subject: [issue7678] subprocess.Popen pipeline example code in the
	documentation is lacking
In-Reply-To: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>
Message-ID: <1296942568.49.0.676537094545.issue7678@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

documentation updated in r88352.  thanks!

----------
assignee: docs at python -> gregory.p.smith
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Feb  5 23:04:57 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Feb 2011 22:04:57 +0000
Subject: [issue1615376] subprocess doesn\'t handle SIGPIPE
Message-ID: <1296943497.3.0.579182102495.issue1615376@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The need to call p1.stdout.close() has now been documented as part of issue7678.  Python 3.2's subprocess also has restore_signals=True as its default behavior so SIGPIPE is restored by default.

I do not think it is appropriate to to add the synchronization Peter suggested to the subprocess module to optimize that close call.  The potential delay due to python having to call p1.stdout.close() is non-fatal and should be assumed to exist anyways as you can't guarantee when an async event like a signal (in this case SIGPIPE) will actually reach the other process.

----------
assignee:  -> gregory.p.smith
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sat Feb  5 23:33:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Feb 2011 22:33:43 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296945223.45.0.218048577685.issue11079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ping!  Raymond, this needs review and release manager approval to make it into 3.2 final.

----------

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

From report at bugs.python.org  Sat Feb  5 23:34:01 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 22:34:01 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1296945241.33.0.191225714006.issue969718@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

?ric, the Debian patch looks good to me and it solves my build problem.

The only question I have is why EXTRA_CFLAGS still go behind CFLAGS
and cannot be overridden via the environment.

But as it is, the patch is an improvement. I'm attaching the version
for 2.7.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file20689/sysconfig-flags.patch

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

From report at bugs.python.org  Sat Feb  5 23:49:08 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Feb 2011 22:49:08 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1296946148.99.0.816143624073.issue969718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why is OPT duplicated in get_config_vars(...)?
Why do OPT and BASECFLAGS environ vars override their Makefile values instead of accumulating with them?
Why is EXTRA_CFLAGS not configurable through environ?

----------

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

From report at bugs.python.org  Sun Feb  6 00:16:24 2011
From: report at bugs.python.org (Justin)
Date: Sat, 05 Feb 2011 23:16:24 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296947784.19.0.470437533672.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

Good point. I was just writing up something quick that works. Here's another patch, is this acceptable?

----------
Added file: http://bugs.python.org/file20690/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 00:18:47 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 05 Feb 2011 23:18:47 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
In-Reply-To: <1296946148.99.0.816143624073.issue969718@psf.upfronthosting.co.za>
Message-ID: <20110205231823.GA31923@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> Why is OPT duplicated in get_config_vars(...)?

I missed that, thanks.

> Why do OPT and BASECFLAGS environ vars override their Makefile values
> instead of accumulating with them?

I think it would go too far to append in three places. If the environment
CFLAGS go to the end, everything can be overridden with a single variable.

> Why is EXTRA_CFLAGS not configurable through environ?

I don't know. Ideally the Debian people would comment if they had any
reasons for that. For me it would be sufficient if CFLAGS were configurable
without deleting OPT, BASECFLAGS or EXTRA_CFLAGS.

----------

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

From report at bugs.python.org  Sun Feb  6 02:05:39 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Feb 2011 01:05:39 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1296954339.42.0.11316361067.issue10826@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Your patch makes sense to me.  I'll commit it after the 3.2 release for 3.2.1.  The elease manager can feel free to commit it earlier if it is bothering an important buildbot.

----------
assignee:  -> gregory.p.smith

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

From report at bugs.python.org  Sun Feb  6 02:14:34 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Feb 2011 01:14:34 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296954874.2.0.108159780671.issue11109@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I believe that is good.  I'll commit it after the 3.2 release has been cut (we're in release candidate release blocker only lockdown right now).

Looking at ForkingMixIn.collect_children() there appears to be another buglet: it loops over self.active_children and calls self.active_children.remove(pid).  This modification of the list while looping over it will cause it to skip the next item in the list.  For every child waited on successfully, it skips checking one of the others.

----------
title: socketserver.ForkingMixIn leaves zombies -> socketserver.ForkingMixIn leaves zombies, also fails to reap all zombies in one pass

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

From report at bugs.python.org  Sun Feb  6 02:14:47 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Feb 2011 01:14:47 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296954887.05.0.334897654858.issue11109@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

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

From report at bugs.python.org  Sun Feb  6 03:18:29 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 02:18:29 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296958709.22.0.538923892335.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

I noticed that ForkingMixIn also was overriding handle_timeout() trying to cleanup zombies after 300 seconds of inactivity, which is useless on a busy server. I'm replacing the patch with one that also removes handle_timeout().

----------
Added file: http://bugs.python.org/file20691/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 03:18:44 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 02:18:44 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296958724.34.0.346551667124.issue11109@psf.upfronthosting.co.za>


Changes by Justin <justin.warkentin at gmail.com>:


Removed file: http://bugs.python.org/file20690/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 04:31:25 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 06 Feb 2011 03:31:25 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1296963085.03.0.500915652813.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's an update to the documentation for the bz2 module.

----------
Added file: http://bugs.python.org/file20692/bz2-doc.diff

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

From report at bugs.python.org  Sun Feb  6 05:14:05 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 04:14:05 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296965645.5.0.341050336401.issue11109@psf.upfronthosting.co.za>


Changes by Justin <justin.warkentin at gmail.com>:


Removed file: http://bugs.python.org/file20691/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 05:14:39 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 04:14:39 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296965679.38.0.473147914431.issue11109@psf.upfronthosting.co.za>


Changes by Justin <justin.warkentin at gmail.com>:


Added file: http://bugs.python.org/file20693/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 05:16:44 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 04:16:44 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296965804.4.0.458486381272.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

I hope I did that last patch right. I did a 'diff -u' instead of a 'diff -c'. If you need something different, let me know.

----------

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

From report at bugs.python.org  Sun Feb  6 05:31:45 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sun, 06 Feb 2011 04:31:45 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1296966705.33.0.861637152167.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

For trailers to work, I think the line:
  self.assertEqual(data, "abcde12345")
should be:
  self.assertEqual(data, b"abcde12345")

Also not that tests like this:
  if not sys.platform.startswith('linux'):

perhaps should also include solaris since it doesn't support headers/trailers either.

----------

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

From report at bugs.python.org  Sun Feb  6 06:17:09 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sun, 06 Feb 2011 05:17:09 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1296969429.91.0.897900404787.issue8691@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

It seems > is only the default for numbers. < is the default for strings, lists, sets, dicts, etc. I have made a patch, though Eric knows the exact semantics.

I wonder what the rationale for having numbers use < is.

----------
keywords: +patch
nosy: +anikom15
Added file: http://bugs.python.org/file20694/py3k-8691.diff

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

From report at bugs.python.org  Sun Feb  6 06:51:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2011 05:51:04 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1296971464.47.0.709567021782.issue11079@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patches looks like what I expected.  Thank you.

I don't know the installer process well enough to say that it is correct at a detailed level, but if you are getting it to run and the links work, then it's probably fine.

----------

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

From report at bugs.python.org  Sun Feb  6 07:16:45 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2011 06:16:45 +0000
Subject: [issue10891] Tweak sorting howto to eliminate redundancy
In-Reply-To: <1294828188.31.0.578827978132.issue10891@psf.upfronthosting.co.za>
Message-ID: <1296973005.81.0.113612574509.issue10891@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Made some tweaks r88358.  Sorry, I'm leaving the list.sort references as-is.  I consider them to be important in a document that needs to clearly differentiate list.sort from __builtin__.sorted().

----------
assignee: eric.araujo -> rhettinger
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Feb  6 07:18:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2011 06:18:13 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1296973093.94.0.452382936454.issue10042@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> low

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

From report at bugs.python.org  Sun Feb  6 07:25:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2011 06:25:30 +0000
Subject: [issue11003] os.system should be deprecated in favour of subprocess
	module
In-Reply-To: <1295952116.86.0.340970955055.issue11003@psf.upfronthosting.co.za>
Message-ID: <1296973530.7.0.86832759647.issue11003@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, I'm rejecting this.  No reasons were presented that would warrant such as disruptive change.

For good or ill, a number of languages implement the same call in much the same way.  It does its job of exposing an operating system service that many people have found to be useful.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  6 07:53:39 2011
From: report at bugs.python.org (Justin)
Date: Sun, 06 Feb 2011 06:53:39 +0000
Subject: [issue11109] socketserver.ForkingMixIn leaves zombies,
	also fails to reap all zombies in one pass
In-Reply-To: <1296770474.15.0.807802878959.issue11109@psf.upfronthosting.co.za>
Message-ID: <1296975219.24.0.479725319685.issue11109@psf.upfronthosting.co.za>


Justin <justin.warkentin at gmail.com> added the comment:

Sorry I keep plaguing this with comments and files, but I got to thinking, anyone should be able to override _loop_actions() and implement what they need in the loop. While it's probably a bad idea in most cases, there may be legitimate needs and it's always good to allow the flexibility. So, I'm adding one more patch that changes the name to loop_actions() and adds it to the list of methods that can be overridden in the BaseServer docstring. If you like it, keep it, if not, just use the last one.

----------
Added file: http://bugs.python.org/file20695/loop_actions.patch

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

From report at bugs.python.org  Sun Feb  6 10:40:06 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 06 Feb 2011 09:40:06 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1296985206.92.0.861703300759.issue11076@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yes, definitely `vars` deserves some description and an example in the documentation. This isn't the first time this question has come up. =)

----------

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

From report at bugs.python.org  Sun Feb  6 10:47:38 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 06 Feb 2011 09:47:38 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1296985658.53.0.0414344580765.issue9334@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, I agree it's not ideal, though note that basic unix commands have trouble with arguments staring with dashes:

$ cd -links-/
-bash: cd: -l: invalid option
cd: usage: cd [-L|-P] [dir]

If you're working with a file on a filesystem, the time honored workaround is to prefix with ./

$ cd ./-links-/
$

Anyway, it doesn't seem like anyone is offering to write up a patch to enable such an alternative parsing strategy, perhaps Eric's "=" workaround should be documented prominently somewhere?

----------

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

From report at bugs.python.org  Sun Feb  6 11:32:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Feb 2011 10:32:01 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1296988321.51.0.781099070849.issue10971@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Feb  6 12:03:22 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 06 Feb 2011 11:03:22 +0000
Subject: [issue11132] compileall.compile_dir loses 'optimize' parameter in
	recursion.
In-Reply-To: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>
Message-ID: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

july at julynote:~/test> ls -R
.:
c.py  subdir

./subdir:
a.py  b.py
july at julynote:~/test> python3
Python 3.2rc2+ (py3k, Feb  6 2011, 13:06:04) 
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from compileall import compile_dir
>>> compile_dir('.', optimize=1)
Listing . ...
Compiling ./c.py ...
Listing ./subdir ...
Compiling ./subdir/a.py ...
Compiling ./subdir/b.py ...
1
>>> 
july at julynote:~/test> ls -R
.:
c.py  __pycache__  subdir

./__pycache__:
c.cpython-32.pyo

./subdir:
a.py  b.py  __pycache__

./subdir/__pycache__:
a.cpython-32.pyc  b.cpython-32.pyc
july at julynote:~/test>

It seems that the bug was introduced in svn revision 87019 (Add an "optimize" parameter to compile() to control the optimization level, and provide an interface to it in py_compile, compileall and PyZipFile.).

In recursion, 'optimize' parameter is lost and replaced by default -1 (optimize level of the interpreter).

Test patch added.

----------
components: Library (Lib)
files: compileall.compile_dir.optimize.test.diff
keywords: patch
messages: 128048
nosy: july
priority: normal
severity: normal
status: open
title: compileall.compile_dir loses 'optimize' parameter in recursion.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20696/compileall.compile_dir.optimize.test.diff

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

From report at bugs.python.org  Sun Feb  6 12:06:30 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 06 Feb 2011 11:06:30 +0000
Subject: [issue11132] compileall.compile_dir loses 'optimize' parameter in
	recursion.
In-Reply-To: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>
Message-ID: <1296990390.68.0.036518556274.issue11132@psf.upfronthosting.co.za>


July Tikhonov <july.tikh at gmail.com> added the comment:

Patch added.

----------
Added file: http://bugs.python.org/file20697/compileall.compile_dir.optimize.diff

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

From report at bugs.python.org  Sun Feb  6 12:26:08 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Feb 2011 11:26:08 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296991568.34.0.457540189459.issue11071@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

In the abc.abstractclassmethod example(http://docs.python.org/dev/py3k/whatsnew/3.2.html#abc), the methods probably should use cls as the name of the first parameter, not self, because they are classmethods.

----------
nosy: +durban

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

From report at bugs.python.org  Sun Feb  6 12:31:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 06 Feb 2011 11:31:58 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1296991918.72.0.605092433353.issue969718@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

EXTRA_CFLAGS were removed in r38848. Is it necessary to configure
OPT, BASECFLAGS and EXTRA_CFLAGS via the environment? I think it
might be sufficient to take CFLAGS from the Makefile and append
the environment CFLAGS.


Chris, would the new minimal patch solve your problem, too?

----------
Added file: http://bugs.python.org/file20698/sysconfig-flags-minimal.patch

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

From report at bugs.python.org  Sun Feb  6 13:02:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:02:02 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296993722.21.0.614944242712.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for volunteering.  I will review and apply when the py3k branch is unfrozen.

> I'll write a docs and script patch for this next week...
Note that I proposed to patch the docs only.

----------
assignee: tarek -> eric.araujo

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

From report at bugs.python.org  Sun Feb  6 13:05:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:05:30 +0000
Subject: [issue11122] bdist_rpm fails
In-Reply-To: <1296854362.61.0.538085175842.issue11122@psf.upfronthosting.co.za>
Message-ID: <1296993930.39.0.237522818739.issue11122@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, it may be useful to point people to http://pypi.python.org/pypi/pypi2rpm, which contains an updated command, bdist_rpm2.

----------

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

From report at bugs.python.org  Sun Feb  6 13:09:52 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Feb 2011 12:09:52 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1296994192.31.0.27577204535.issue11071@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

In the shutil example (http://docs.python.org/dev/py3k/whatsnew/3.2.html#shutil) the function argument of shutil.register_archive_format is a string, but according to http://docs.python.org/dev/py3k/library/shutil.html#shutil.register_archive_format it should be a callable.

----------

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

From report at bugs.python.org  Sun Feb  6 13:18:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:18:06 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1296994686.27.0.684802388826.issue9334@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Documenting ?--extra-args=--foo? or ?--extra-args -- --foo? (untested, but should work) seems good.

----------
nosy: +eric.araujo
stage: unit test needed -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Feb  6 13:20:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:20:21 +0000
Subject: [issue11132] compileall.compile_dir loses 'optimize' parameter in
	recursion.
In-Reply-To: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>
Message-ID: <1296994821.37.0.373940337041.issue11132@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.

----------
keywords: +needs review
nosy: +eric.araujo, georg.brandl, r.david.murray
stage:  -> patch review
versions: +Python 3.3

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

From report at bugs.python.org  Sun Feb  6 13:28:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:28:51 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1296995331.74.0.474905150148.issue10042@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FWIW, I just tested svnmerging the revision, the patch applied with minor merge conflicts and the test suite passes.

----------

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

From report at bugs.python.org  Sun Feb  6 13:30:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 12:30:52 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1296995452.91.0.569303172916.issue9364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Welcome to Python 3.2!  This is the online help utility.
> which could be changed to 
> Welcome to Python help utility

Agreed.  I assume this dates back to a time where ?online help? meant available on this computer, not on some global network.  I?d keep the version in the string, though:  Welcome to Python 3.2's help utility!

----------

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

From report at bugs.python.org  Sun Feb  6 15:30:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Feb 2011 14:30:04 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1297002604.08.0.723793159947.issue8691@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Georg & Eric, I believe this simple patch is correct, and should go in 3.2.

Westley, thanks for the patch. Numbers are right-aligned because that is the traditional default.

The committer should add Westley Martinez to misc/ACKS

----------
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Feb  6 16:22:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Feb 2011 15:22:36 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297005756.8.0.513043051525.issue10971@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Sun Feb  6 16:32:49 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 06 Feb 2011 15:32:49 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1297006369.19.0.00697787596914.issue969718@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I am not convinced that the minimal patch would work for my original issue. I wanted to be able to override the -march option which shows up in OPT on Fedora. I was cross-compiling to a target architecture that does not support the -march option so I would not be able to provide a different one as override. 

The proposed minimal patch would leave the OPT value and make it unchangeable because CFLAGS would pull out a value for OPT from the Makefile which shows as in my current Ubuntu system:

OPT=        -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
BASECFLAGS=  -fno-strict-aliasing
CFLAGS=     $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)

The debian-sysconfig-flags looks the most correct because it allows override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) logic.

It still looks like it needs an override for EXTRA_CFLAGS and the logic for LD_SHARED looks wrong. In the Makefile LDSHARED is just:
LDSHARED=   $(CC) -shared -Wl,-O1 -Wl,-Bsymbolic-functions

Why does LDSHARED need CFLAGS and CPPFLAGS? When provided as an override but not in the Makefile? Do we need to allow for this override in the case of overriding OPT, BASEFLAGS or EXTRA_CFLAGS?

----------

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

From report at bugs.python.org  Sun Feb  6 16:36:22 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 06 Feb 2011 15:36:22 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297006582.45.0.614091944762.issue9364@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Removed file: http://bugs.python.org/file20686/pydoc.diff

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

From report at bugs.python.org  Sun Feb  6 16:38:45 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 06 Feb 2011 15:38:45 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297006725.69.0.856557123461.issue9364@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Added file: http://bugs.python.org/file20699/pydoc.diff

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

From report at bugs.python.org  Sun Feb  6 16:47:34 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 06 Feb 2011 15:47:34 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297007254.58.0.232337898613.issue9364@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

Completely agreed with you on having "Welcome to python 3.2 help!".. made the changes. Uploaded site.py as suggested by you . I will try to create the patch for the links , but i am not sure how to .Could use some help if you can provide me any website link.Thanks

----------
Added file: http://bugs.python.org/file20700/site.diff

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

From report at bugs.python.org  Sun Feb  6 16:56:11 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Feb 2011 15:56:11 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297007771.99.0.959456880057.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

"--" won't work. Traditionally, this has been used to separate optional arguments from positional arguments. Continuing the "cd" example, that's what would let you cd into a directory whose name starts with a hyphen:

$ cd -links-/
-bash: cd: -l: invalid option
cd: usage: cd [-L|-P] [dir]
$ cd -- -links-
$

This would also work with argparse:
import argparse
parser = argparse.ArgumentParser(prog='cd')
parser.add_argument('-L', help='follow symbolic links')
parser.add_argument('-P', help='do not follow symbolic links')
parser.add_argument('dir', help='directory name')
print(parser.parse_args(['--', '-Links-']))

prints:
Namespace(L=None, P=None, dir='-Links-')

Continuing the example from my earlier post shows it won't work for values for optional arguments:
>>> parser.parse_args(['--asciidoc-opts -- -one'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: unrecognized arguments: --asciidoc-opts -- -one

I believe it's only the '=' that will solve this problem. In fact, because of this issue, I suggest we document '=' as the preferred way to call argparse when optional arguments have values, and change all of the examples to use it. I also think it would cause less confusion (because of this issue) if the help output showed the equal sign. But I realize that's probably more controversial.

----------

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

From report at bugs.python.org  Sun Feb  6 16:57:09 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Feb 2011 15:57:09 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297007829.22.0.627747872469.issue10971@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My fix for the issues with reloading of the _ssl module meant that a couple of temporary modules weren't getting cleared out of sys.modules properly, thus confusing the second and later runs of affected tests.

Attached patch adds explicit removal calls for the affected modules.

----------
Added file: http://bugs.python.org/file20701/test_zipimport_support.py

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

From report at bugs.python.org  Sun Feb  6 16:57:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Feb 2011 15:57:58 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297007878.15.0.554286800269.issue10971@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Helps to add the patch rather than the whole file...

----------
Added file: http://bugs.python.org/file20702/issue10971_temp_module_cleanup

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

From report at bugs.python.org  Sun Feb  6 16:58:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 06 Feb 2011 15:58:04 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297007884.56.0.752204432502.issue10971@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file20701/test_zipimport_support.py

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

From report at bugs.python.org  Sun Feb  6 16:58:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Feb 2011 15:58:13 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
In-Reply-To: <1297006369.19.0.00697787596914.issue969718@psf.upfronthosting.co.za>
Message-ID: <1297007890.3765.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am not convinced that the minimal patch would work for my original
> issue. I wanted to be able to override the -march option which shows
> up in OPT on Fedora. I was cross-compiling to a target architecture
> that does not support the -march option so I would not be able to
> provide a different one as override. 

I don't understand how you can cross-compile using the host Python
Makefile. Could you explain?

> The proposed minimal patch would leave the OPT value and make it
> unchangeable because CFLAGS would pull out a value for OPT from the
> Makefile which shows as in my current Ubuntu system:
> 
> OPT=        -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
> BASECFLAGS=  -fno-strict-aliasing
> CFLAGS=     $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
> 
> The debian-sysconfig-flags looks the most correct because it allows
> override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT)
> $(EXTRA_CFLAGS) logic.
> 
> It still looks like it needs an override for EXTRA_CFLAGS

EXTRA_CFLAGS is not defined in the Makefile so it would probably be
taken from the environment anyway (if my understand of Makefiles is
right). That seems to explain the name "EXTRA_CFLAGS", but I'm no
specialist of the jungle that have building systems become under Unix.

----------

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

From report at bugs.python.org  Sun Feb  6 17:00:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 16:00:47 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297008047.75.0.835854769904.issue9364@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See http://docs.python.org/dev/documenting/ (see also 
http://docs.python.org/devguide/patch for process guidelines).

Note about site.diff:
-    """Define the builtin 'help'.
-    This is a wrapper around pydoc.help (with a twist).
+    """Class used to implement the built-in help function

I suggested to remove ?with a twist?, not the other part of the line.

The other patch is fine, thanks.

----------

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

From report at bugs.python.org  Sun Feb  6 17:01:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 16:01:02 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297008062.93.0.126479547953.issue9364@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> eric.araujo

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

From report at bugs.python.org  Sun Feb  6 17:13:51 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 06 Feb 2011 16:13:51 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297008831.61.0.0420504861709.issue9364@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Removed file: http://bugs.python.org/file20700/site.diff

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

From report at bugs.python.org  Sun Feb  6 17:14:11 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 06 Feb 2011 16:14:11 +0000
Subject: [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1297008851.26.0.22272983958.issue9364@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Added file: http://bugs.python.org/file20703/site.diff

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

From report at bugs.python.org  Sun Feb  6 17:30:22 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 06 Feb 2011 16:30:22 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The documentation of getattr_static says:
"The only known case that can cause getattr_static to trigger code execution, and cause it to return incorrect results (or even break), is where a class uses __slots__ and provides a __dict__ member using a property or descriptor. If you find other cases please report them so they can be fixed or documented."

I'd like to report another case: when an object's __dict__ is an instance of a dict subclass which overrides dict.get:

>>> _sentinel = object()
>>> 
>>> class MyDict(dict):
...     def get(self, key, default=_sentinel):
...             print('Hello World!') # This code will execute
...             if default is _sentinel:
...                     return super().get(key)
...             else:
...                     return super().get(key, default)
... 
>>> class X:
...     def __init__(self):
...             self.__dict__ = MyDict()
... 
>>> x = X()
>>> inspect.getattr_static(x, 'foo', 0)
Hello World!
0
>>> 

(In line 1072. _check_instance calls MyDict.get: instance_dict.get(attr, _sentinel).)

----------
components: Library (Lib)
messages: 128067
nosy: durban, michael.foord
priority: normal
severity: normal
status: open
title: inspect.getattr_static code execution
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  6 17:39:00 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sun, 06 Feb 2011 16:39:00 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297010340.53.0.963663321429.issue11116@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Thanks for spending your free time, almost alone in such a widespread area like this.

----------

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

From report at bugs.python.org  Sun Feb  6 18:40:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 17:40:30 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1297014030.54.0.884556228801.issue8691@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Or to Doc/ACKS.txt, which I?ve recently discovered.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sun Feb  6 18:58:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 06 Feb 2011 17:58:46 +0000
Subject: [issue11131] decimal.py: plus/minus with ROUND_FLOOR
In-Reply-To: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>
Message-ID: <1297015126.23.0.132757465752.issue11131@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice catch!  Please could you test the attached patch (against py3k)?

I'll apply it after 3.2 is out.  The fix should also go into the 2.7 maintenance branch, I think.

----------
assignee:  -> mark.dickinson
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file20704/issue11131.patch

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

From report at bugs.python.org  Sun Feb  6 19:48:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 18:48:23 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1297018103.05.0.83487770362.issue940286@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open

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

From report at bugs.python.org  Sun Feb  6 20:12:18 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Sun, 06 Feb 2011 19:12:18 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297019538.75.0.803498628689.issue9334@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

There are some problems that ?=? can?t solve, such as options with nargs ? 2.  optparse has no trouble with this:

>>> parser = optparse.OptionParser()
>>> parser.add_option('-a', nargs=2)
>>> parser.parse_args(['-a', '-first', '-second'])
(<Values at 0x7fc97a93a7e8: {'a': ('-first', '-second')}>, [])

But inputting those arguments is _not possible_ with argparse.

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-a', nargs=2)
>>> parser.parse_args(['-a', '-first', '-second'])
usage: [-h] [-a A A]
: error: argument -a: expected 2 argument(s)

----------

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

From report at bugs.python.org  Sun Feb  6 20:33:17 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Feb 2011 19:33:17 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297020797.66.0.505039487583.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Good point, I hadn't thought of that. Maybe ArgumentParser needs a "don't try to be so helpful, parse like optparse" option. Which is what Steven suggested earlier, I believe.

I'd take a crack at this if there's general consensus on that solution.

We can change the documentation to point out the issue now, but the feature request can only go in 3.3.

----------

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

From report at bugs.python.org  Sun Feb  6 20:34:21 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Feb 2011 19:34:21 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1297020861.83.0.487825642969.issue11133@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The fix is to use dict methods rather than accessing members through the instance. It will have to wait until 3.2 is out now though.

----------

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

From report at bugs.python.org  Sun Feb  6 20:34:38 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 06 Feb 2011 19:34:38 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1297020878.34.0.276506112339.issue11133@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

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

From report at bugs.python.org  Sun Feb  6 20:42:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 19:42:29 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1297021349.03.0.255235826299.issue11090@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, my patch removes too much.  The part that was mistakenly added by me is the command-line interface doc, but I also removed other parts for things noted with versionadded: 3.2.  Those indications are wrong: They were noted added in 2.7 before r79167 (Ezio).

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Feb  6 20:51:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 19:51:49 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Three slots in type objects are missing in PEP 384. This patch adds them to the ABI.

----------
files: typeslots.diff
keywords: patch
messages: 128075
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Add missing type slots
versions: Python 3.2
Added file: http://bugs.python.org/file20705/typeslots.diff

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

From report at bugs.python.org  Sun Feb  6 20:53:44 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Sun, 06 Feb 2011 19:53:44 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297022024.61.0.205609489102.issue9334@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

That would be a good first step.

I continue to advocate making that mode the default, because it?s consistent with how every other command line program works[1], and backwards compatible with the current argparse behavior.

As far as documentation for older versions, would it be reasonable to un-deprecate optparse until argparse becomes a suitable replacement?  There are still lots of programmers working in Python 2.7.

[1] bethard?s msg128047 is confusing positional arguments with option arguments.  All UNIX commands that accept option arguments have no trouble accepting option arguments that begin with -.  For example, ?grep -e -pattern file? is commonly used to search for patterns beginning with -.

----------

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

From report at bugs.python.org  Sun Feb  6 21:02:06 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 20:02:06 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

There are currently two ways to specify a type doc string in PyType_FromSpec; either through the doc field (which is not actually processed), or through Py_tp_doc (which works correctly).

The original concern for adding doc into the TypeSpec was that the slots may only refer to function pointers; as it turns out, putting character pointers in there works fine as well, so I recommend to drop the doc field in TypeSlot.

The patch also fixes some labelling in the xxlimited module.

----------
files: tp_doc.diff
keywords: patch
messages: 128077
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Redundant doc field in TypeSpec
versions: Python 3.2
Added file: http://bugs.python.org/file20706/tp_doc.diff

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

From report at bugs.python.org  Sun Feb  6 21:02:18 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Feb 2011 20:02:18 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297022538.34.0.774489373479.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'd also like to see this as the default. After all, presumably we'd like Python scripts to work like all other command line programs, and I too am unaware of any other option parsing library that works the way argparse does.

But changing released behavior in the stdlib is problematic, as everyone knows.

I'll look into producing a patch to add this as optional behavior, then we can separately think about changing the default.

----------

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

From report at bugs.python.org  Sun Feb  6 21:03:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Feb 2011 20:03:37 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297022617.82.0.385499422351.issue11134@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the recent multiple additions of "forgotten things" in the ABI, wouldn't it be better to mark the ABI experimental so that things can get ironed out in 3.2.1? (especially with user feedback after the release)

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Feb  6 21:06:07 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Feb 2011 20:06:07 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1297022767.07.0.890003934056.issue11113@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't see the need for a parameter to support different sets of entities. Just supporting the ones from HTML 5 seems like the right thing.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sun Feb  6 21:07:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 20:07:03 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1297022823.45.0.450525219339.issue11113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To make my intent explicit: an updated mapping could generate references invalid for 4.01.

----------

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

From report at bugs.python.org  Sun Feb  6 21:08:41 2011
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Feb 2011 20:08:41 +0000
Subject: [issue11113] html.entities mapping dicts need updating?
In-Reply-To: <1296791035.1.0.458454998569.issue11113@psf.upfronthosting.co.za>
Message-ID: <1297022921.88.0.993832013181.issue11113@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Ah. I hadn't thought of generating them, only parsing them. In that case, then yes, it's an issue for generation.

----------

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

From report at bugs.python.org  Sun Feb  6 21:26:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 20:26:50 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297022617.82.0.385499422351.issue11134@psf.upfronthosting.co.za>
Message-ID: <4D4F0409.5030201@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Given the recent multiple additions of "forgotten things" in the ABI,
> wouldn't it be better to mark the ABI experimental so that things can
> get ironed out in 3.2.1? (especially with user feedback after the
> release)

I don't know what would be gained in such a marking, or how the marking
could be carried out.

I assume that uptake of the ABI is slow either way (marked or not),
although you might manage to slow it down further by marking it
experimental. I can't see why that would be desirable.

----------

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

From report at bugs.python.org  Sun Feb  6 21:31:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Feb 2011 20:31:04 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <4D4F0409.5030201@v.loewis.de>
Message-ID: <1297024259.3765.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Given the recent multiple additions of "forgotten things" in the ABI,
> > wouldn't it be better to mark the ABI experimental so that things can
> > get ironed out in 3.2.1? (especially with user feedback after the
> > release)
> 
> I don't know what would be gained in such a marking, or how the marking
> could be carried out.

No, the point of the proposal is to allow you to make further changes in
response to user feedback. I assume you can't add things anymore once
the ABI is declared "stable". Can you?

----------

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

From report at bugs.python.org  Sun Feb  6 21:46:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Feb 2011 20:46:50 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297025210.61.0.736590698875.issue11134@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

My understanding is that Martin can add, but not subtract.  Martin, is that correct?  At this point, I'm not sure we know that the limited API is sufficient.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  6 22:09:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 21:09:17 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1297026557.92.0.598024818646.issue11090@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It looks like the doc snippets are actually new in 3.1, so we should not remove them but just fix the versionadded.

The change I wrongly added is the part about command-line use.  That can go.

----------

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

From report at bugs.python.org  Sun Feb  6 22:09:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 21:09:21 +0000
Subject: [issue11090] Doc errors for unittest in Python 3.1
In-Reply-To: <1296573823.39.0.448811226108.issue11090@psf.upfronthosting.co.za>
Message-ID: <1297026561.13.0.499623838981.issue11090@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20657/fix-11090.diff

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

From report at bugs.python.org  Sun Feb  6 22:26:51 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 21:26:51 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297024259.3765.6.camel@localhost.localdomain>
Message-ID: <4D4F1218.1030703@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> No, the point of the proposal is to allow you to make further changes in
> response to user feedback. I assume you can't add things anymore once
> the ABI is declared "stable". Can you?

Adding things would be possible, although undesirable. Extension modules
built against the initial release would continue to work
in the new release; extension modules built against the new release
would work with the old release as long as they don't use the additions.
So I'd be in favor of extending the ABI conservatively, as long as
developers explicitly need to opt-in to use such additions (e.g. by
defining a macro)

Most of the recent ABI changes would have fallen under such a policy;
the only incompatible change is the removal of a field (issue11135).
If that isn't carried out before 3.2 is released, then the field
would just remain unused.

----------

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

From report at bugs.python.org  Sun Feb  6 22:34:09 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 06 Feb 2011 21:34:09 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297025210.61.0.736590698875.issue11134@psf.upfronthosting.co.za>
Message-ID: <4D4F13CD.50706@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> My understanding is that Martin can add, but not subtract.  Martin,
> is that correct?

Correct (see the elaboration I just sent).

> At this point, I'm not sure we know that the
> limited API is sufficient.

It's certainly not possible to easily port /all/ existing extension
modules to this ABI - but that never was the plan, only "the majority"
should be supported. It can be demonstrated that the ABI supports
"small" extension modules (xxlimited). For anything else, I'd wait
until people report limitations that they run into. Then, we can either
a strategy to rewrite the module (as also would have been possible
with all the recent additions); if rewriting is not sensible, we
have to extend the ABI (which hopefully won't be necessary often).

So I wouldn't communicate that the ABI is experimental (because
that would suggest that it may go away or change - which I do
hope will not be necessary). Instead, announcing that we are open
to extend it if there is a demonstrated need would indeed be
useful.

----------

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

From report at bugs.python.org  Sun Feb  6 23:01:12 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 06 Feb 2011 22:01:12 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297029672.97.0.806389500739.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

You're right, that line is certainly wrong as it should compare for bytes but the trailer data still doesn't get appended.
Do you have a BSD box in order to figure out what's wrong?

----------

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

From report at bugs.python.org  Sun Feb  6 23:01:28 2011
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 06 Feb 2011 22:01:28 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297029688.34.0.0273217553219.issue9334@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I don't think there's any sense in "un-deprecating" optparse because:

(1) It's only deprecated in the documentation - there is absolutely nothing in the code to keep you from continuing to use it, and there are no plans to remove it from Python.

(2) One (mis?)feature doesn't make the rest of the module useless.

And yes Eric, it would be awesome if you could develop a patch that allows the alternate parsing to be enabled when someone wants it. We should think about deprecation strategy though. Maybe something like:

== Python 3.3 ==
# Python 3.2 behavior
parser = ArgumentParser(error_on_unknown_options=True)
# proposed behavior
parser = ArgumentParser(error_on_unknown_options=False)
# deprecation warning when not specified
parser = ArgumentParser()

== Python 2.4 ==
# error warning when not specified
parser = ArgumentParser()

== Python 2.5 ==
# defaults to error_on_unknown_options=False
parser = ArgumentParser()

I'm not sure that's the right way to do it, but if the plan is to change the default at some point, we should make sure that we have a deprecation plan before we add the feature.

----------

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

From report at bugs.python.org  Sun Feb  6 23:34:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Feb 2011 22:34:54 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297031694.65.0.15187856867.issue9334@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/2.4/3.4/
s/2.5/3.5/
obviously :)

----------

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

From report at bugs.python.org  Mon Feb  7 00:42:40 2011
From: report at bugs.python.org (John)
Date: Sun, 06 Feb 2011 23:42:40 +0000
Subject: [issue11136] imaplib IMAP4_SSL shutdown gets socket error in py 3.2
In-Reply-To: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>
Message-ID: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

windows vista
Python 3.2 rc2

situation: 
connected to gmail with IMAP4_SSL, did stuff, and finally IMAP4_SSL.close() 
IMAP4_SSL.logout()
IMAP4_SSL.shutdown() 

shutdown() gets this error:

socket.error: [Errno 10038] An operation was attempted on something that is not a socket

No problem in Python 3.1.2

For now I don't use shutdown(), and hope the socket is closed automatically when the interpreter exits (as open files are).

-- jh

----------
components: Library (Lib)
messages: 128092
nosy: jh45
priority: normal
severity: normal
status: open
title: imaplib IMAP4_SSL shutdown gets socket error in py 3.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb  7 01:05:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 00:05:06 +0000
Subject: [issue11136] imaplib IMAP4_SSL shutdown gets socket error in py 3.2
In-Reply-To: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>
Message-ID: <1297037106.58.0.64996984089.issue11136@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> IMAP4_SSL.close() 
> IMAP4_SSL.logout()
> IMAP4_SSL.shutdown() 

logout() already calls shutdown() for you and closes the socket, so you don't have to do it yourself.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Mon Feb  7 02:08:07 2011
From: report at bugs.python.org (David Benjamin)
Date: Mon, 07 Feb 2011 01:08:07 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297040887.02.0.712438263028.issue9334@psf.upfronthosting.co.za>


Changes by David Benjamin <davidben at mit.edu>:


----------
nosy: +davidben

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

From report at bugs.python.org  Mon Feb  7 03:08:37 2011
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 07 Feb 2011 02:08:37 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297044517.2.0.512764070547.issue9334@psf.upfronthosting.co.za>


Anders Kaseorg <andersk at mit.edu> added the comment:

> (1) It's only deprecated in the documentation

Which is why I suggested un-deprecating it in the documentation.  (I want to avoid encouraging programmers to switch away from optparse until this bug is fixed.)

> # proposed behavior
> parser = ArgumentParser(error_on_unknown_options=False)

Perhaps you weren?t literally proposing ?error_on_unknown_options=False? as the name of the new flag, but note that neither the current nor proposed behaviors have nothing to do with whether arguments look like known or unknown options.  Under the proposed behavior, anything in argument position (--asciidoc-opts ___) is parsed as an argument, no matter what it looks like.

So a more accurate name might be ?refuse_dashed_args=False?, or more generally (in case prefix_chars != '-'), ?refuse_prefixed_args=False??

----------

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

From report at bugs.python.org  Mon Feb  7 03:18:45 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Feb 2011 02:18:45 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297045125.95.0.693962683985.issue11071@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

In the paragraph on OS X builds, suggest changing "OS X" to "Mac OS X". 

Also, instead of the direct recommendation to install ActiveState Tcl, a recommendation that could very well change over the lifetime of the 3.2 release and the released copies of the What's New document, please substitute a reference to the web page, http://www.python.org/download/mac/tcltk/ which will contain the most up-to-date information.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Feb  7 03:18:52 2011
From: report at bugs.python.org (John)
Date: Mon, 07 Feb 2011 02:18:52 +0000
Subject: [issue11137] clarify use of imaplib IMAP4(_SSL) shutdown
In-Reply-To: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>
Message-ID: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

Attempting IMAP4_SSL.shutdown() after IMAP4_SSL.logout() throws an error because the socket is already closed. (I cannot test with plain IMAP4.)

Please add appropriate notice, perhaps under IMAP4.shutdown().

Perhaps something like "If you do not use open(), and do only login() and logout(), you do not need shutdown(), as logout() does it for you."

-- jh

----------
assignee: docs at python
components: Documentation
messages: 128096
nosy: docs at python, jh45
priority: normal
severity: normal
status: open
title: clarify use of imaplib IMAP4(_SSL) shutdown
versions: Python 3.2

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

From report at bugs.python.org  Mon Feb  7 04:43:45 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 07 Feb 2011 03:43:45 +0000
Subject: [issue11137] clarify use of imaplib IMAP4(_SSL) shutdown
In-Reply-To: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>
Message-ID: <1297050225.91.0.278669032569.issue11137@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

Perhaps we should say something regarding that shutdown, and similar methods, must be called after open.

----------
nosy: +anikom15

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

From report at bugs.python.org  Mon Feb  7 05:35:22 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 07 Feb 2011 04:35:22 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297053322.85.0.778705419449.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

With no changes, I get:
======================================================================
FAIL: test_trailers (test.test_os.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/ross/py3k_sftest/Lib/test/test_os.py", line 1531, in test_trailers
    self.assertEqual(data, "abcde12345")
AssertionError: b'abcde12345' != 'abcde12345'

After changing, the tests work perfectly. Perhaps its the FreeBSD version? Here's the output from uname:
FreeBSD fbds 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010     root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Maybe its a bug on that platform, you could try building a sendfile program in C with trailer data. Or try a simple test in the interpreter like the one in msg127326 but with added trailer data.

----------

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

From report at bugs.python.org  Mon Feb  7 05:41:27 2011
From: report at bugs.python.org (Urago Keisuke)
Date: Mon, 07 Feb 2011 04:41:27 +0000
Subject: [issue11138] Docs: incollect example: "fill" and "align"
In-Reply-To: <1297053687.75.0.437678029921.issue11138@psf.upfronthosting.co.za>
Message-ID: <1297053687.75.0.437678029921.issue11138@psf.upfronthosting.co.za>


New submission from Urago Keisuke <bravo at resourcez.org>:

"Nesting arguments and more complex examples"
at http://docs.python.org/library/string.html#format-examples

Below example code is no errors:
>>> for align, text in zip('<^>', ['left', 'center', 'right']):
...     '{0:{align}{fill}16}'.format(text, fill=align, align=align)

I think meaning is as follows:
...     '{0:{fill}{align}16}'.format(text, fill=align, align=align)

----------
assignee: docs at python
components: Documentation
messages: 128099
nosy: Urago.Keisuke, docs at python
priority: normal
severity: normal
status: open
title: Docs: incollect example: "fill" and "align"
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb  7 06:32:16 2011
From: report at bugs.python.org (Rob Lourens)
Date: Mon, 07 Feb 2011 05:32:16 +0000
Subject: [issue6294] Improve shutdown exception ignored message
In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za>
Message-ID: <1297056736.84.0.608507358047.issue6294@psf.upfronthosting.co.za>


Rob Lourens <roblourens at gmail.com> added the comment:

I agree with R. David Murray's suggestions, and have implemented it in the attached patch.

----------
keywords: +patch
nosy: +rob.lourens
Added file: http://bugs.python.org/file20707/errors.patch

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

From report at bugs.python.org  Mon Feb  7 08:07:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2011 07:07:54 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297062474.16.0.0348546693655.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Ned, thanks for the "Mac" correction. I prefer to leave the Tcl/Tk recommendation in place for several reasons:

* for right now, it is needed to get tkinter to work and if we're too indirect about the fix, no one will find it and their install won't work.

* if other options become available in the future or it stops being needed, I will update the whatsnew recommendation in a point release.

* the recommendation won't stop being correct.  it may become unnecessary, but it will still work.

The only bad outcome here would be if we fail to speak-up and tell users what they have to do to get their install to work.  There are no points for hiding the message behind another link and letting people get erratic crashes when they do an install and try to run IDLE.

----------

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

From report at bugs.python.org  Mon Feb  7 08:37:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2011 07:37:56 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297064276.41.0.44065721315.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Victor, I added more imports and fixed the ones that were mismatched with the sample code.  I've left a few out in a couple places where I thought the imports got in the way of the narrative.

----------

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

From report at bugs.python.org  Mon Feb  7 08:50:54 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Feb 2011 07:50:54 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297065054.49.0.96581756686.issue11071@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I understand your point and it is not a huge issue but let me make an attempt to expand on the rationale.

> * for right now, it is needed to get tkinter to work and if we're too indirect about the fix, no one will find it and their install won't work.

It may be indirect but the situation is complicated and dynamic.  There are references to the canonical webpage in the Installer welcome message (in bold), the Installer ReadMe, and in IDLE if the known-to-be-problematic Apple version is being used.  As it stands, the What's New document is the only place that doesn't refer to the webpage.

> * if other options become available in the future or it stops being needed, I will update the whatsnew recommendation in a point release.

That's fine but it doesn't necessarily help the users who will not be installing cutting edge versions of Python 3.2.x maintenance releases.

> * the recommendation won't stop being correct.  it may become unnecessary, but it will still work.

That's not necessarily true.  We have no control over what ActiveState does.  From their website:

>Looking for access to older versions of ActiveTcl?
>  Community Edition offers access to the newest versions of ActiveTcl.
>  Access to older versions is available only in Business Edition.

We could find that the current working version has been replaced by one that doesn't work.  Between the ActiveState 8.5.8.2 (released earlier in 2010) and 8.5.9, there was a huge change, going from supplying the Carbon-based Tk version (which was supported on Mac OS 10.4+ and on PPC and Intel 32-bit-only archs) to the Cocoa-based one (10.5+ and Intel-only and 32-/64-bit).  The Carbon one is no longer available to the community.  If you were using Tk 8.5 on a PPC machine or on 10.4, my understanding it that you are now out of luck unless you make arrangements with ActiveState to be covered under presumably a non-zero-cost license.  Something like that could happen again.

There is also the issue of the ActiveState community license; some users of the python.org distribution may not be able to use the ActiveState version because of its terms.  There are more details that need to be filled in on the download page prior to release to expand on that.

The whole point of creating the canonical webpage is to have one place to go for the current information in an inherently dynamic environment.  I think there is a strong case to change the wording in the What's New as suggested but, if you think it better to not do so, I will be OK with your decision.

----------

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

From report at bugs.python.org  Mon Feb  7 08:58:29 2011
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 07 Feb 2011 07:58:29 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297065509.08.0.740714994543.issue9334@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

@?ric: yes, thanks!

@Anders: The reason the current implementation gives you the behavior you don't want is that the first thing it does is scan the args list for things that look like flags (based on prefix_chars). It assumes that everything that looks like a flag is intended to be one, before it ever looks at how many arguments the flag before it takes or anything like that. This is the source of your problem - argparse assumes "-safe" is a flag, and as a result, there is no argument for "--asciidoc-opts'. So perhaps a better name would be something like dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one. ;-)

----------

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

From report at bugs.python.org  Mon Feb  7 10:10:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Feb 2011 09:10:10 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297069810.06.0.626344187865.issue11129@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There's no particularly good use case for this. Plus, going forwards, dictionary-based configuration should be used (as it supports more logging features).

----------
nosy: +vinay.sajip
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 10:10:28 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Feb 2011 09:10:28 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297069828.58.0.577271790995.issue11129@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip

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

From report at bugs.python.org  Mon Feb  7 12:02:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Feb 2011 11:02:17 +0000
Subject: [issue11128] decimal.py: to_integral() corner cases
In-Reply-To: <1296911209.51.0.925327858699.issue11128@psf.upfronthosting.co.za>
Message-ID: <1297076537.1.0.437549088113.issue11128@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

For the record, I prefer Python's behavior. The quantize() definition
does not work well for arbitrary precision input and leads to situations
like:


Precision: 1
Maxexponent: 1
Minexponent: -1

tointegral  101  ->  101
tointegral  101.0  ->  NaN  Invalid_operation


A comment in tointegral.decTest suggests that the to-integral definition 
was modeled after IEEE 854 and 754r:

-- This set of tests tests the extended specification 'round-to-integral
-- value' operation (from IEEE 854, later modified in 754r).
-- All non-zero results are defined as being those from either copy or
-- quantize, so those are assumed to have been tested.
-- Note that 754r requires that Inexact not be set, and we similarly
-- assume Rounded is not set.


This definition of course works fine as long as the input does not
have more than 'precision' digits and Emax is sufficiently large. I
think that for arbitrary precision input the definition should read:


"Otherwise (the operand has a negative exponent) the result is the
 same as using the quantize operation using the given operand as the
 left-hand-operand and 1E+0 as the right-hand-operand. For the purpose
 of quantizing a temporary context is used with the precision of the
 operand as the precision setting, Emax >= prec and Emin <= -Emax. The
 rounding mode is taken from the context, as usual."

----------

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

From report at bugs.python.org  Mon Feb  7 13:11:09 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:11:09 +0000
Subject: [issue11138] Docs: incollect example: "fill" and "align"
In-Reply-To: <1297053687.75.0.437678029921.issue11138@psf.upfronthosting.co.za>
Message-ID: <1297080669.96.0.820517980666.issue11138@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r88364.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 13:15:43 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:15:43 +0000
Subject: [issue8691] Doc: left alignment is not the default for numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1297080943.33.0.0785658053207.issue8691@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r88365.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 13:31:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:31:10 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1297081870.7.0.402200168681.issue11079@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same here: can't test it, but if you test it successfully and the installer runs, this is good for 3.2.

----------

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

From report at bugs.python.org  Mon Feb  7 13:37:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:37:40 +0000
Subject: [issue11132] compileall.compile_dir loses 'optimize' parameter in
	recursion.
In-Reply-To: <1296990202.6.0.306196036221.issue11132@psf.upfronthosting.co.za>
Message-ID: <1297082260.57.0.567184967428.issue11132@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r88366.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 13:37:45 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:37:45 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1297082265.71.0.516192788081.issue11079@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same here: can't test it, but if you test it successfully and the installer runs, this is good for 3.2.

----------

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

From report at bugs.python.org  Mon Feb  7 13:56:41 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:56:41 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297083401.69.0.649123232265.issue11116@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> The traceback from email.generator is unfortunate.  I should have
> message_from-string reject non-ASCII input with a clear error message
> like mailbox.add does now, but I didn't think of it.  I will see if
> the release manager will let me make that change.

Sounds like a good change.

----------

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

From report at bugs.python.org  Mon Feb  7 13:58:42 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 12:58:42 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297083522.79.0.006073963063.issue11134@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm sure Martin has now carefully checked all the remaining slots and these three are the last ones to be added :)

----------

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

From report at bugs.python.org  Mon Feb  7 14:00:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Feb 2011 13:00:10 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297083610.43.0.944377055203.issue11135@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good.

----------

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

From report at bugs.python.org  Mon Feb  7 14:40:21 2011
From: report at bugs.python.org (Michael Haubenwallner)
Date: Mon, 07 Feb 2011 13:40:21 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1297086021.21.0.989392863811.issue7719@psf.upfronthosting.co.za>


Changes by Michael Haubenwallner <michael.haubenwallner at salomon.at>:


----------
nosy: +haubi

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

From report at bugs.python.org  Mon Feb  7 15:15:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 07 Feb 2011 14:15:32 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297088132.88.0.623631206731.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I was testing against FreeBSD 7.0 RC1 and I confirm the problem doesn't occur on 8.1 version. Patch in attachment adds test for "flags" argument and skips headers/trailers tests on linux and solaris.
I'm ok for committing this as-is in 3.3.

----------
resolution:  -> accepted
status: open -> pending
Added file: http://bugs.python.org/file20708/sendfile_v7.patch

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

From report at bugs.python.org  Mon Feb  7 15:26:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Feb 2011 14:26:49 +0000
Subject: [issue11131] decimal.py: plus/minus with ROUND_FLOOR
In-Reply-To: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>
Message-ID: <1297088809.05.0.720095607833.issue11131@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The patch and the test cases look good, but the implicit context must
be looked up earlier now (see the altered patch).

I just realize that there aren't any regression tests for this sort
of situation, since for the main tests we are only testing the context
methods.

----------
Added file: http://bugs.python.org/file20709/issue11131-2.patch

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

From report at bugs.python.org  Mon Feb  7 15:29:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 14:29:16 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297088956.4.0.522844251176.issue10882@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please leave open until a patch is actually committed ;)

----------
status: pending -> open

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

From report at bugs.python.org  Mon Feb  7 15:43:37 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 14:43:37 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1297089817.89.0.259241286198.issue7719@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the applicable patch against py3k branch.

----------
nosy: +SilentGhost
Added file: http://bugs.python.org/file20710/dir_util.py.diff

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

From report at bugs.python.org  Mon Feb  7 15:49:37 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 14:49:37 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>


New submission from Arve Knudsen <arve.knudsen at gmail.com>:

As a regression from Python 2.6, when running .bat scripts on Windows with f.ex. subprocess.call under Python 2.7.1, arguments get interpreted by the shell. This bit me in the way that I could no longer pass arguments containing the character '|' to .bat scripts, something that works fine under Python 2.6.

To see the bug in action, run tst.py in the attached case.zip with Python 2.7.1. The case also demonstrates that the '|' character only gets interpreted when launching cmd scripts, not e.g. python.exe.

----------
components: Library (Lib)
files: case.zip
messages: 128119
nosy: Arve.Knudsen
priority: normal
severity: normal
status: open
title: subprocess: Arguments to .bat scripts get interpreted by shell
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20711/case.zip

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

From report at bugs.python.org  Mon Feb  7 15:54:38 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Feb 2011 14:54:38 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297090478.93.0.776998595787.issue10971@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Fixed for 3.2 in r88368 (no backport needed, since the older test suites didn't exhibit the original problem with the _ssl module reloading)

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 15:57:02 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Feb 2011 14:57:02 +0000
Subject: [issue10971] python Lib/test/regrtest.py -R 3:3:
	test_zipimport_support fails
In-Reply-To: <1295608490.51.0.226657873121.issue10971@psf.upfronthosting.co.za>
Message-ID: <1297090622.81.0.363793426077.issue10971@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

(Georg reviewed the patch after I mentioned it to him on IRC)

----------

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

From report at bugs.python.org  Mon Feb  7 16:07:33 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 15:07:33 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297091253.35.0.0871877100497.issue11139@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb  7 16:24:36 2011
From: report at bugs.python.org (Justin Bronder)
Date: Mon, 07 Feb 2011 15:24:36 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1297092276.5.0.673740809867.issue8637@psf.upfronthosting.co.za>


Justin Bronder <jsbronder at gentoo.org> added the comment:

On Thu, Feb 3, 2011 at 7:39 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Justin: what exactly is a pager that does not support man pages?

vimpager is the one I'm using.  For man pages there's vimmanpager.

----------

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

From report at bugs.python.org  Mon Feb  7 16:27:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Feb 2011 15:27:13 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1297092433.59.0.760098947114.issue8637@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Excuse me if I was unclear: I wasn?t asking for program names but for a definition of ?don?t support? or description of problematic behavior.

----------

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

From report at bugs.python.org  Mon Feb  7 16:31:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 15:31:53 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1273160026.83.0.741000260603.issue8637@psf.upfronthosting.co.za>
Message-ID: <1297092713.11.0.836534228123.issue8637@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reusing MANPAGER is practical. Yet another PY* environment variable doesn't seem warranted in this case.
Agreed with Alexander's simpler logic proposal in msg105153.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Feb  7 16:33:36 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 15:33:36 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297092816.99.0.952838431128.issue11139@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

This seem to have been discussed in issue8972: closing as a duplicate.

----------
nosy: +SilentGhost
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 16:34:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 15:34:11 +0000
Subject: [issue11136] imaplib IMAP4_SSL shutdown gets socket error in py 3.2
In-Reply-To: <1297035760.26.0.288823197275.issue11136@psf.upfronthosting.co.za>
Message-ID: <1297092851.43.0.837030915593.issue11136@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

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

From report at bugs.python.org  Mon Feb  7 16:35:08 2011
From: report at bugs.python.org (Justin Bronder)
Date: Mon, 07 Feb 2011 15:35:08 +0000
Subject: [issue8637] Add PYDOCPAGER envvar to specify pager for pydoc
In-Reply-To: <1297092433.59.0.760098947114.issue8637@psf.upfronthosting.co.za>
Message-ID: <20110207153501.GA18106@gmail.com>


Justin Bronder <jsbronder at gentoo.org> added the comment:

> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Excuse me if I was unclear: I wasn?t asking for program names but for a definition of ?don?t support? or description of problematic behavior.

In headers with vimpager ^H is not rendered(?) correctly.

For instance, 'pydoc os' shows:

---
Help on module os:

N^HNA^HAM^HME^HE

F^HFI^HIL^HLE^HE
    /usr/lib/python2.6/os.py

---

And so on.

----------

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

From report at bugs.python.org  Mon Feb  7 16:35:20 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 15:35:20 +0000
Subject: [issue8972] subprocess.list2cmdline doesn't quote the & character
In-Reply-To: <1276261868.23.0.953588591338.issue8972@psf.upfronthosting.co.za>
Message-ID: <1297092920.8.0.617987843273.issue8972@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

issue11139 was closed as a duplicate of this issue.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Mon Feb  7 16:35:27 2011
From: report at bugs.python.org (aaugustin)
Date: Mon, 07 Feb 2011 15:35:27 +0000
Subject: [issue11140] Error in the documentation of threading.Lock().release()
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>


New submission from aaugustin <aymeric.augustin at polyconseil.fr>:

The docs for the threading module state that:

> The release() method should only be called in the locked state; it changes the state to unlocked and returns immediately. If an attempt is made to release an unlocked lock, a RuntimeError will be raised.

However, I noticed that catching RuntimeError does not work. Actually release() raises thread.error, which inherits directly Exception.

I reproduced the behavior shown below in Python 2.6.6, 2.7.1 from MacPorts on Mac OS 10.6 and in Python 2.6.6 on Linux. The same happens in Python 3.2rc2 on Mac OS 10.6, except the thread module has been renamed to _thread so the exception becomes a _thread.error.

>>> import threading

>>> try:
...     threading.Lock().release()
... except RuntimeError:
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
thread.error: release unlocked lock

>>> try:
...     threading.Lock().release()
... except Exception, e:
...     print type(e)
...     print type(e).mro()
... 
<class 'thread.error'>
[<class 'thread.error'>, <type 'exceptions.Exception'>, <type 'exceptions.BaseException'>, <type 'object'>]

I do not know if this must be fixed in the docs or the code. Currently, the type of the exception is probably platform-dependant since the thread module is not provided on all platforms.

----------
components: Library (Lib)
messages: 128128
nosy: aaugustin
priority: normal
severity: normal
status: open
title: Error in the documentation of threading.Lock().release()
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  7 16:38:32 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 15:38:32 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297093112.73.0.593671868749.issue11139@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's not really a duplicate, but rather invalid, since the 2.7 behavior is more correct than the 2.6 behavior.  Not that it matters all that much what particular resolution is attached to a bug.

Arve: It is unfortunate that the bug fix in issue 8972 caused a regression for you, but at this point what is done is done.

Also, for future reference, when attaching files to an issue please attach text files only.  They are much easier to review.

----------
nosy: +r.david.murray
resolution: duplicate -> invalid
stage:  -> committed/rejected
superseder:  -> subprocess.list2cmdline doesn't quote the & character

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

From report at bugs.python.org  Mon Feb  7 16:41:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 15:41:15 +0000
Subject: [issue11140] threading.Lock().release() raises _thread.error,
	not RuntimeError
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1297093275.38.0.777240832339.issue11140@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would rather make _thread.error an alias of RuntimeError. That way, we can reconcile the docs and the code without breaking compatibility.
Also, importing _thread won't be necessary to catch errors raised in threading objects.

----------
nosy: +gregory.p.smith, pitrou
stage:  -> needs patch
title: Error in the documentation of threading.Lock().release() -> threading.Lock().release() raises _thread.error, not RuntimeError
type:  -> behavior
versions: +Python 3.3 -Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  7 16:55:47 2011
From: report at bugs.python.org (aaugustin)
Date: Mon, 07 Feb 2011 15:55:47 +0000
Subject: [issue11140] threading.Lock().release() raises _thread.error,
	not RuntimeError
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1297094147.88.0.0267877269744.issue11140@psf.upfronthosting.co.za>


aaugustin <aymeric.augustin at polyconseil.fr> added the comment:

I agree with your solution. Unfortunately, I do not know how you would redefine ThreadError to extend RuntimeError in a C extension.

_thread.error is created line 741 in trunk/Modules/threadmodule.c:
ThreadError = PyErr_NewException("thread.error", NULL, NULL);


dummy_thread.error is created lin 21 in trunk/Lib/dummy_thread.py:
class error(Exception):
    ...

Changing this to RuntimeException is trivial.


I don't think there are other implementations of threading in the Python source but I'd appreciate if someone more familiar with the interpreter could confirm.

----------

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

From report at bugs.python.org  Mon Feb  7 17:04:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 16:04:20 +0000
Subject: [issue11137] clarify use of imaplib IMAP4(_SSL) shutdown
In-Reply-To: <1297045132.5.0.369740718147.issue11137@psf.upfronthosting.co.za>
Message-ID: <1297094660.37.0.547228000423.issue11137@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, clarified in r88371. Thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Feb  7 17:11:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 16:11:21 +0000
Subject: [issue11140] threading.Lock().release() raises _thread.error,
	not RuntimeError
In-Reply-To: <1297094147.88.0.0267877269744.issue11140@psf.upfronthosting.co.za>
Message-ID: <1297095077.3754.26.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> aaugustin <aymeric.augustin at polyconseil.fr> added the comment:
> 
> I agree with your solution. Unfortunately, I do not know how you would
> redefine ThreadError to extend RuntimeError in a C extension.
> 
> _thread.error is created line 741 in trunk/Modules/threadmodule.c:
> ThreadError = PyErr_NewException("thread.error", NULL, NULL);

I was not proposing to extend it, just to alias it:

ThreadError = PyExc_RuntimeError;
Py_INCREF(ThreadError);

That said, extending is quite trivial if the behaviour is not changed:

ThreadError = PyErr_NewException("thread.error", PyExc_RuntimeError,
NULL);

(see
http://docs.python.org/dev/c-api/exceptions.html#PyErr_NewException)

----------

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

From report at bugs.python.org  Mon Feb  7 17:34:45 2011
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Feb 2011 16:34:45 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297096485.89.0.502446817376.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Steven: Yes, the current structure of the first pass scan makes any patch problematic. It really would be an implementation of a different algorithm.

I'm still interested in looking at it, though.

----------

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

From report at bugs.python.org  Mon Feb  7 17:39:25 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 16:39:25 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297093112.73.0.593671868749.issue11139@psf.upfronthosting.co.za>
Message-ID: <AANLkTimxWvRfFOTqXDbJ5YhDSHo4sQDYoCA-V5JxMJO9@mail.gmail.com>


Arve Knudsen <arve.knudsen at gmail.com> added the comment:

Would you mind defining why the 2.7 behaviour is correct in this particular
case? The list2cmdline behaviour discussed in issue 8972 has to do with
shell commandlines; in this case, in my eyes any shell invocation (in order
to run a .bat I guess) is only an implementation detail. Is the 2.7
behaviour correct since the Win32 function CreateProcess happens to start a
shell to run .bat files, which in turn interprets the arguments? I'm
guessing this is what happens...

There certainly can't be any universal definition in subprocess saying that
arguments to shell scripts shall be interpreted by the shell; when trying
now *on Linux* to launch a corresponding .sh script through subprocess,
arguments are passed through verbatim. I should like to see subprocess
maintain (or keep maintaining, rather) a uniform interface, so that
arguments are not interpreted so long as the 'shell' argument equals False.

I understand completely that list2cmdline should implement C library
behaviour, and not protect arguments from the shell, but that doesn't mean
it should automatically define the behaviour of other functions such as
Popen and call.

Arve

On Mon, Feb 7, 2011 at 4:38 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Well, it's not really a duplicate, but rather invalid, since the 2.7
> behavior is more correct than the 2.6 behavior.  Not that it matters all
> that much what particular resolution is attached to a bug.
>
> Arve: It is unfortunate that the bug fix in issue 8972 caused a regression
> for you, but at this point what is done is done.
>
> Also, for future reference, when attaching files to an issue please attach
> text files only.  They are much easier to review.
>
> ----------
> nosy: +r.david.murray
> resolution: duplicate -> invalid
> stage:  -> committed/rejected
> superseder:  -> subprocess.list2cmdline doesn't quote the & character
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20712/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
-------------- next part --------------
Would you mind defining why the 2.7 behaviour is correct in this particular case? The list2cmdline behaviour discussed in issue 8972 has to do with shell commandlines; in this case, in my eyes any shell invocation (in order to run a .bat I guess) is only an implementation detail. Is the 2.7 behaviour correct since the Win32 function CreateProcess happens to start a shell to run .bat files, which in turn interprets the arguments? I&#39;m guessing this is what happens...<div>
<br></div><div>There certainly can&#39;t be any universal definition in subprocess saying that arguments to shell scripts shall be interpreted by the shell; when trying now *on Linux* to launch a corresponding .sh script through subprocess, arguments are passed through verbatim. I should like to see subprocess maintain (or keep maintaining, rather) a uniform interface, so that arguments are not interpreted so long as the &#39;shell&#39; argument equals False.</div>
<div><br></div><div>I understand completely that list2cmdline should implement C library behaviour, and not protect arguments from the shell, but that doesn&#39;t mean it should automatically define the behaviour of other functions such as Popen and call.</div>
<div><br></div><div>Arve<br><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 4:38 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
Well, it&#39;s not really a duplicate, but rather invalid, since the 2.7 behavior is more correct than the 2.6 behavior. ??Not that it matters all that much what particular resolution is attached to a bug.<br>
<br>
Arve: It is unfortunate that the bug fix in issue 8972 caused a regression for you, but at this point what is done is done.<br>
<br>
Also, for future reference, when attaching files to an issue please attach text files only. ??They are much easier to review.<br>
<br>
----------<br>
nosy: +r.david.murray<br>
resolution: duplicate -&gt; invalid<br>
stage: ??-&gt; committed/rejected<br>
superseder: ??-&gt; subprocess.list2cmdline doesn&#39;t quote the &amp; character<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11139" target="_blank">http://bugs.python.org/issue11139</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Mon Feb  7 17:50:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Feb 2011 16:50:07 +0000
Subject: [issue11131] decimal.py: plus/minus with ROUND_FLOOR
In-Reply-To: <1296929089.89.0.497503076821.issue11131@psf.upfronthosting.co.za>
Message-ID: <1297097407.28.0.77325872458.issue11131@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, good point about the context;  thanks for the updated patch.

Yes, those missing regression tests are a problem;  this isn't the first time that the above problem has appeared.

----------

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

From report at bugs.python.org  Mon Feb  7 17:55:35 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Feb 2011 16:55:35 +0000
Subject: [issue11079] Make OS X entry in Applications like that in Windows
In-Reply-To: <1296490743.96.0.234780831636.issue11079@psf.upfronthosting.co.za>
Message-ID: <1297097735.5.0.374510486765.issue11079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Committed in r88374 and r88375 to py3k for 3.2 and the documentation links part only in r88376 to 27 for release in 2.7.2.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 17:59:39 2011
From: report at bugs.python.org (John Dennis)
Date: Mon, 07 Feb 2011 16:59:39 +0000
Subject: [issue11104] distutils sdist ignores MANIFEST
In-Reply-To: <1296691544.53.0.327829038157.issue11104@psf.upfronthosting.co.za>
Message-ID: <1297097979.3.0.964581830339.issue11104@psf.upfronthosting.co.za>


Changes by John Dennis <jdennis at redhat.com>:


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Mon Feb  7 18:03:03 2011
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 07 Feb 2011 17:03:03 +0000
Subject: [issue11141] 2.x range() in 3.x shelve documentation
In-Reply-To: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>
Message-ID: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The example in the shelve documentation (http://docs.python.org/dev/py3k/library/shelve.html#example) uses the old range() (which returned a list):

d['xx'] = range(4)  # this works as expected, but...
d['xx'].append(5)   # *this doesn't!* -- d['xx'] is STILL range(4)!

----------
assignee: docs at python
components: Documentation
messages: 128138
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: 2.x range() in 3.x shelve documentation
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Feb  7 18:06:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 17:06:09 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297098369.83.0.813949383447.issue11139@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The point is that subprocess (now!) is *not* interpreting the arguments when shell is false.  It is passing them through to Windows.  What windows does with them after that is out of the control of subprocess (and always has been).

----------

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

From report at bugs.python.org  Mon Feb  7 18:14:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 17:14:59 +0000
Subject: [issue11141] 2.x range() in 3.x shelve documentation
In-Reply-To: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>
Message-ID: <1297098899.66.0.444691416732.issue11141@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the patch.

----------
keywords: +needs review, patch
nosy: +SilentGhost
versions: +Python 3.3
Added file: http://bugs.python.org/file20713/shelve.rst.diff

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

From report at bugs.python.org  Mon Feb  7 18:33:39 2011
From: report at bugs.python.org (Erez Sh)
Date: Mon, 07 Feb 2011 17:33:39 +0000
Subject: [issue11142] xmlrpclib.ServerProxy with verbosity produces bad output
In-Reply-To: <1297100019.07.0.0200011843084.issue11142@psf.upfronthosting.co.za>
Message-ID: <1297100019.07.0.0200011843084.issue11142@psf.upfronthosting.co.za>


New submission from Erez Sh <erez27 at gmail.com>:

In xmlrpclib, a ServerProxy initialized with verbose=True produces an occasionally jumbled-up output, due to a multiple threads writing to stdout without synchronizing.

I noticed this happening only for incoming data (at line 1461:                 print "body:", repr(data) ).

I seem to have fixed it locally by accumulating all the data and printing it (within a lock) outside of the send/recv loop.

It is a useful feature for debugging and logging the 'raw' communication, but virtually useless if one can't rely on its output.

----------
components: Library (Lib)
messages: 128141
nosy: Erez.Sh
priority: normal
severity: normal
status: open
title: xmlrpclib.ServerProxy with verbosity produces bad output
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 18:38:59 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 17:38:59 +0000
Subject: [issue11143] Issue with the issue tracker
In-Reply-To: <1297100338.89.0.650994969187.issue11143@psf.upfronthosting.co.za>
Message-ID: <1297100338.89.0.650994969187.issue11143@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Should I report it here?  The issue is with this issue tracker itself.  If we search for "2147483647" using the "search" box on this site (look up to the right), then it works; but if we search for "2147483648" or a bigger number (without the quotes), then we get an internal error :-)

----------
messages: 128142
nosy: arigo
priority: normal
severity: normal
status: open
title: Issue with the issue tracker

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

From report at bugs.python.org  Mon Feb  7 18:45:55 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 17:45:55 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

On 32 bits, there is no reason to get a 'long' here:

>>> int(float(sys.maxint))
2147483647L
>>> int(int(float(sys.maxint)))
2147483647
>>> int(float(-sys.maxint-1))
-2147483648L
>>> int(int(float(-sys.maxint-1)))
-2147483648

On 64 bits, it's another story because floats cannot store 64 bits of precision.  However, -sys.maxint-1 can still be represented exactly in a float, and the same issue occurs:

>>> int(float(-sys.maxint-1))
-9223372036854775808L
>>> int(int(float(-sys.maxint-1)))
-9223372036854775808

----------
components: Interpreter Core
messages: 128143
nosy: arigo
priority: normal
severity: normal
status: open
title: int(float) may return a long for no reason
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 18:53:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Feb 2011 17:53:05 +0000
Subject: [issue11141] 2.x range() in 3.x shelve documentation
In-Reply-To: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>
Message-ID: <1297101185.89.0.218858322443.issue11141@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> 
resolution:  -> accepted

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

From report at bugs.python.org  Mon Feb  7 19:12:18 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 18:12:18 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297098369.83.0.813949383447.issue11139@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=pM3J+_qOqmg-6YmYmUMVA3jGpAddnNQXeVngH@mail.gmail.com>


Arve Knudsen <arve.knudsen at gmail.com> added the comment:

I wasn't saying that subprocess is interpreting the arguments, but that the
shell is. Which was highly unexpected to me when outside of shell mode
(i.e., shell == False). From some further testing, though, I see that the
transformation from sequence to command line on Windows plays a bigger role
than I was aware of even though I've used subprocess since it was introduced
in the standard library. That is, I see that also in Python 2.6, arguments
to .bat scripts get interpreted if command arguments are passed to
subprocess as a string rather in a list.

My current conclusion is that there has been a hole in the subprocess design
the whole time, so that my case (start a Windows shell script like an
executable) has just worked by chance, due to that I have passed arguments
as a list which then got implicitly protected (even outside of shell mode).
Maybe subprocess.Popen should take another option to implement the old
behaviour of protecting arguments supplied as a list, given that this should
be a common enough case?

Arve

On Mon, Feb 7, 2011 at 6:06 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> The point is that subprocess (now!) is *not* interpreting the arguments
> when shell is false.  It is passing them through to Windows.  What windows
> does with them after that is out of the control of subprocess (and always
> has been).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20714/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
-------------- next part --------------
I wasn&#39;t saying that subprocess is interpreting the arguments, but that the shell is. Which was highly unexpected to me when outside of shell mode (i.e., shell == False). From some further testing, though, I see that the transformation from sequence to command line on Windows plays a bigger role than I was aware of even though I&#39;ve used subprocess since it was introduced in the standard library. That is, I see that also in Python 2.6, arguments to .bat scripts get interpreted if command arguments are passed to subprocess as a string rather in a list.<div>
<br></div><div>My current conclusion is that there has been a hole in the subprocess design the whole time, so that my case (start a Windows shell script like an executable) has just worked by chance, due to that I have passed arguments as a list which then got implicitly protected (even outside of shell mode). Maybe subprocess.Popen should take another option to implement the old behaviour of protecting arguments supplied as a list, given that this should be a common enough case?</div>
<div><br></div><div>Arve<br><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 6:06 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
</div>The point is that subprocess (now!) is *not* interpreting the arguments when shell is false. ??It is passing them through to Windows. ??What windows does with them after that is out of the control of subprocess (and always has been).<br>

<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11139" target="_blank">http://bugs.python.org/issue11139</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Mon Feb  7 19:14:47 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 18:14:47 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297102487.65.0.795483691709.issue11139@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20712/unnamed

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

From report at bugs.python.org  Mon Feb  7 19:14:50 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 07 Feb 2011 18:14:50 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297102490.42.0.154956185491.issue11139@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20714/unnamed

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

From report at bugs.python.org  Mon Feb  7 19:19:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 18:19:56 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297102796.55.0.802393332021.issue11139@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

As noted in issue 8972, it's not clear what such a mode should actually do.  If you have a concrete proposal you could make it, probably on the python-ideas mailing list.  But I'm personally not in favor of it; I prefer maintaining as much API consistency between windows and linux as we reasonably can.

----------

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

From report at bugs.python.org  Mon Feb  7 19:26:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 18:26:14 +0000
Subject: [issue11143] Issue with the issue tracker
In-Reply-To: <1297100338.89.0.650994969187.issue11143@psf.upfronthosting.co.za>
Message-ID: <1297103174.68.0.246640331386.issue11143@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There is a link 'report tracker problem' at the bottom of the left hand column.  Unfortunately you have to create an account there to submit an issue :(

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 19:30:57 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 18:30:57 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297102796.55.0.802393332021.issue11139@psf.upfronthosting.co.za>
Message-ID: <AANLkTimTgmTnrsRQkTAVDt84CnSQ+-+gthpMnR=J1ko1@mail.gmail.com>


Arve Knudsen <arve.knudsen at gmail.com> added the comment:

The non-obvious thing with 8972 is what to do with an argument list when the
'shell' option is True, isn't it? I can't see how it overlaps with my case.
My suggestion is a flag to enable argument protection in Popen, either just
for arguments passed as a list (i.e., like how it's done in 2.6) or maybe
also for the case where you pass the command as a string (I haven't
considered that case yet, since it's not directly interesting to me).

I can actually see that exarkun suggests something along the same lines in
8972: 'implement the cmd.exe quoting rules in a different function from the
MS C runtime rules'.

Arve

On Mon, Feb 7, 2011 at 7:19 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> As noted in issue 8972, it's not clear what such a mode should actually do.
>  If you have a concrete proposal you could make it, probably on the
> python-ideas mailing list.  But I'm personally not in favor of it; I prefer
> maintaining as much API consistency between windows and linux as we
> reasonably can.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20715/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
-------------- next part --------------
The non-obvious thing with??8972 is what to do with an argument list when the &#39;shell&#39; option is True, isn&#39;t it? I can&#39;t see how it overlaps with my case. My suggestion is a flag to enable argument protection in Popen, either just for arguments passed as a list (i.e., like how it&#39;s done in 2.6) or maybe also for the case where you pass the command as a string (I haven&#39;t considered that case yet, since it&#39;s not directly interesting to me).<div>
<br></div><div>I can actually see that exarkun suggests something along the same lines in 8972: &#39;implement the cmd.exe quoting rules in a different function from the MS C runtime rules&#39;.<div><br></div><div>Arve<br>
<br><div class="gmail_quote">On Mon, Feb 7, 2011 at 7:19 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
</div>As noted in issue 8972, it&#39;s not clear what such a mode should actually do. ??If you have a concrete proposal you could make it, probably on the python-ideas mailing list. ??But I&#39;m personally not in favor of it; I prefer maintaining as much API consistency between windows and linux as we reasonably can.<br>

<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11139" target="_blank">http://bugs.python.org/issue11139</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div>

From report at bugs.python.org  Mon Feb  7 19:46:34 2011
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 07 Feb 2011 18:46:34 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

The expression  '%o' % x,  where x is a user-defined instance, usually ignores a user-defined __oct__() method.  I suppose that's fine; assuming this is the expected behavior, then the present issue is about the "usually" in my previous sentence.

If 'x' is an instance of a subclass of 'long', then the __oct__() is called.  It must be specifically a 'long' -- not, say, 'int' or 'str' or 'object'.  Moreover, there is a test in test_format.py (class Foobar) that checks that if this __oct__() returns a non-string, then we get a nice TypeError.  That's already strange -- why is __oct__() called in the first place?  But trying out more I get (CPython 2.7.1):

>>> class X(long):
...   def __oct__(self):
...     return 'abc'
... 
>>> '%o' % X()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: ../trunk/Objects/stringobject.c:4035: bad argument to internal function

----------
components: Interpreter Core
messages: 128148
nosy: arigo
priority: normal
severity: normal
status: open
title: '%o' % user-defined instance
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  7 19:55:19 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Feb 2011 18:55:19 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297104919.1.0.500825133204.issue11129@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Where is this configuration?

----------

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

From report at bugs.python.org  Mon Feb  7 20:00:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 19:00:12 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297090177.54.0.621260802543.issue11139@psf.upfronthosting.co.za>
Message-ID: <1297105212.69.0.11653938823.issue11139@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, having a cmd.exe 'quote' function, parallel to the shutil 'quote' function, would be an excellent addition to the stdlib.  You could open a feature request for that.

----------

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

From report at bugs.python.org  Mon Feb  7 20:02:14 2011
From: report at bugs.python.org (Arve Knudsen)
Date: Mon, 07 Feb 2011 19:02:14 +0000
Subject: [issue11139] subprocess: Arguments to .bat scripts get interpreted by
	shell
In-Reply-To: <1297105212.69.0.11653938823.issue11139@psf.upfronthosting.co.za>
Message-ID: <AANLkTikSk0d_Tk_gdhPdnGNY9Ed+tzYemLztT_nTk1cQ@mail.gmail.com>


Arve Knudsen <arve.knudsen at gmail.com> added the comment:

I'll keep it in mind.

On Mon, Feb 7, 2011 at 8:00 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Yes, having a cmd.exe 'quote' function, parallel to the shutil 'quote'
> function, would be an excellent addition to the stdlib.  You could open a
> feature request for that.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20716/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
-------------- next part --------------
I&#39;ll keep it in mind.<div><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 8:00 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
</div>Yes, having a cmd.exe &#39;quote&#39; function, parallel to the shutil &#39;quote&#39; function, would be an excellent addition to the stdlib. ??You could open a feature request for that.<br>
<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11139" target="_blank">http://bugs.python.org/issue11139</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Mon Feb  7 20:09:13 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Feb 2011 19:09:13 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297105753.52.0.146014757313.issue11145@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

And this code will crash a debug build:

>>> class X(long):
...     def __oct__(self):
...         return 'foo'.upper()
...
>>> '%o' % X()
Assertion failed: buf[sign] == '0', file ..\..\Objects\stringobject.c, line 4059

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Feb  7 20:25:06 2011
From: report at bugs.python.org (=?utf-8?q?Manuel_B=C3=A4renz?=)
Date: Mon, 07 Feb 2011 19:25:06 +0000
Subject: [issue11146] Add a feature similar to C++ "using some_namespace"
In-Reply-To: <1297106706.4.0.712510956651.issue11146@psf.upfronthosting.co.za>
Message-ID: <1297106706.4.0.712510956651.issue11146@psf.upfronthosting.co.za>


New submission from Manuel B?renz <manuel at enigmage.de>:

In C++, the the approach to the namespace problem is having different namespaces that should not contain different definitions of the same name.
Members of a namespace can be accessed explicitly by e.g. calling "std::cout << etc." or "using namespace std; cout << etc."

I understand Pythons approach to be "objects can be used as namespaces and their attributes are the names they contain". I find this a very beautiful way of solving the issue, but it has a downside, in my opinion, because it lacks the "using" directive from C++.

If the object is a module, we can of course do "from mymodule import spam, eggs". But if it is not a module, this does not work.

Consider for example:

class Spam(object):
    def frobnicate(self):
        self.eggs = self.buy_eggs()
        self.scrambled = self.scramble(self.eggs)
        return self.scrambled > 42

This could be easier to implement and read if we had something like:

class Spam(object):
    def frobnicate(self):
        using self:
            eggs = buy_eggs()
            scrambled = scramble(eggs)
            return scrambled > 42

Of course this opens a lot of conceptual questions like how should this using block behave if self doesn't have an attribute called "eggs", but I think it is worth considering.

----------
messages: 128153
nosy: turion
priority: normal
severity: normal
status: open
title: Add a feature similar to C++ "using some_namespace"
type: feature request

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

From report at bugs.python.org  Mon Feb  7 20:33:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 07 Feb 2011 19:33:47 +0000
Subject: [issue11146] Add a feature similar to C++ "using some_namespace"
In-Reply-To: <1297106706.4.0.712510956651.issue11146@psf.upfronthosting.co.za>
Message-ID: <1297107227.15.0.592525559765.issue11146@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a topic more suited to python-ideas.  It isn't likely to get much traction there, but you can try :)

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  7 21:33:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 07 Feb 2011 20:33:11 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
In-Reply-To: <1297006369.19.0.00697787596914.issue969718@psf.upfronthosting.co.za>
Message-ID: <20110207203245.GA26829@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Chris Lambacher <report at bugs.python.org> wrote:
> I was cross-compiling to a target architecture that does not support
> the -march option so I would not be able to provide a different one
> as override. 

Just out of curiosity: You are cross-compiling a C-extension? How can
you be sure that all values in pyconfig.h are correct?

> The debian-sysconfig-flags looks the most correct because it allows
> override at any point by emulating the CFLAGS = $(BASECFLAGS) $(OPT)
> $(EXTRA_CFLAGS) logic.
> 
> It still looks like it needs an override for EXTRA_CFLAGS and the
> logic for LD_SHARED looks wrong. In the Makefile LDSHARED is just:
> LDSHARED=   $(CC) -shared -Wl,-O1 -Wl,-Bsymbolic-functions

I think Antoine is correct: EXTRA_CFLAGS show up as an empty string in
sysconfig (even if passed to configure and make), so there is no need
to override them.

As an aside, why do EXTRA_CFLAGS still exist in py3k when CFLAGS
can already be passed to configure and make?

I agree that the ldshared logic looks wrong. It is possible to specify
LDFLAGS via the environment, so why append CFLAGS. Changing this could
break existing build scripts though.

However, I don't see how the Debian patch could break anything, unless
someone relies on the fact that BASECFLAGS are suppressed in case CFLAGS
are given. I think the odds of this are virtually zero.

Any interest in a cleaned up version of the Debian patch (remove
double opt, line length, add documentation for overriding BASECFLAGS
and OPT)?

I'm asking, since I'm unsure about the degree of frozenness of distutils.

----------

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

From report at bugs.python.org  Mon Feb  7 21:44:50 2011
From: report at bugs.python.org (Eric Smith)
Date: Mon, 07 Feb 2011 20:44:50 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297111490.9.0.181384005924.issue11145@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Feb  7 22:15:56 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 07 Feb 2011 21:15:56 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297113356.03.0.709799038446.issue11144@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm not sure whether this is a bug, though. So I'd be skeptical that it should be changed in 2.x, even if the cause was identified.

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Feb  7 23:09:20 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 07 Feb 2011 22:09:20 +0000
Subject: [issue4142] smtplib doesn't clear helo/ehlo flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1297116560.49.0.669007471138.issue4142@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello Felix/Don,
are you still interested in seeing this fixed in smtplib? If so, what about incorporating Martin's suggestions and propose a new patch for review?

----------
nosy: +sandro.tosi -Felix Schwarz
stage:  -> test needed

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

From report at bugs.python.org  Mon Feb  7 23:25:29 2011
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 07 Feb 2011 22:25:29 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1297117529.15.0.087707557401.issue969718@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Antoine said:
> I don't understand how you can cross-compile using the host Python
> Makefile. Could you explain?

The get_config_vars() function parses the host Makefile to get the values that we are discussing overriding.

> EXTRA_CFLAGS is not defined in the Makefile so it would probably be
> taken from the environment anyway (if my understand of Makefiles is
> right). That seems to explain the name "EXTRA_CFLAGS", but I'm no
> specialist of the jungle that have building systems become under Unix.

You are correct, EXTRA_CFLAGS is not in the Makefile, but does provide us with an expected order of evaluation. i.e. Distutils is generating the equivalent command lines from the pieces and we should be respecting the Makefile order for consistency. Also, I don't know if there is a way to insert EXTRA_CFLAGS as an option to the ./configure script when Python is built such that it shows up in the resulting Makefile. If there is no way to get EXTRA_CFLAGS into the Makefile, then we should take it entirely out of the equation in the construction of the cflags var. 

Stephan Said:
> Just out of curiosity: You are cross-compiling a C-extension? How can
> you be sure that all values in pyconfig.h are correct?
That is the whole point of this discussion, if you can sub out the build parameters, you can insert the path to the .h files for the embedded target before any host specific .h files.

In order to build a C extension, you pretty much have to do it through Distutils and therefore the host python interpreter or else do a lot of extra work to get the right settings for each individual extension.
See the following for some basic how-to info: 
http://whatschrisdoing.com/blog/2006/10/06/howto-cross-compile-python-25/
http://whatschrisdoing.com/blog/2009/10/16/cross-compiling-python-extensions/

----------

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

From report at bugs.python.org  Mon Feb  7 23:33:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 22:33:29 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1297118009.67.0.820588208037.issue969718@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Any interest in a cleaned up version of the Debian patch (remove
> double opt, line length, add documentation for overriding BASECFLAGS
> and OPT)?

I think it would be nice, but it should have a test if possible.
Otherwise there'll keep being regressions.

----------

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

From report at bugs.python.org  Tue Feb  8 00:09:27 2011
From: report at bugs.python.org (Darren)
Date: Mon, 07 Feb 2011 23:09:27 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1297120167.28.0.174512987841.issue11103@psf.upfronthosting.co.za>


Darren <darrenb at sybase.com> added the comment:

I originally installed rc1 for all users.  Then today I uninstalled and re-installed rc2 for just me and that didn't help anything.

----------

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

From report at bugs.python.org  Tue Feb  8 00:11:07 2011
From: report at bugs.python.org (Darren)
Date: Mon, 07 Feb 2011 23:11:07 +0000
Subject: [issue11103] Python 3.2 installer doesn't register file extensions on
	Windows 7
In-Reply-To: <1296682766.55.0.843230930362.issue11103@psf.upfronthosting.co.za>
Message-ID: <1297120267.55.0.770921214973.issue11103@psf.upfronthosting.co.za>


Darren <darrenb at sybase.com> added the comment:

FWIW I'm using the 64 bit installer on Windows 7

----------

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

From report at bugs.python.org  Tue Feb  8 00:19:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 07 Feb 2011 23:19:28 +0000
Subject: [issue11141] 2.x range() in 3.x shelve documentation
In-Reply-To: <1297098183.14.0.0535108956136.issue11141@psf.upfronthosting.co.za>
Message-ID: <1297120768.91.0.521221229609.issue11141@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88377, thank you!

----------
nosy: +pitrou
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.3

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

From report at bugs.python.org  Tue Feb  8 01:15:50 2011
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 08 Feb 2011 00:15:50 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1294394503.75.0.518735272621.issue9990@psf.upfronthosting.co.za>
Message-ID: <4D508B32.3050008@telus.net>


Lenard Lindstrom <len-l at telus.net> added the comment:

I think only a simple solution is needed. From my experience adding the 
new buffer protocol to pygame.mixer.Sound it would be easy enough for 
bf_releasebuffer to use the "internal" field to free memory allocated by 
bf_getbuffer. As long as this pointer is preserved it would not matter 
if Py_buffer is copied or the "shape" and "strides" pointers change. 
Just ensure Py_buffer is clearly documented.

----------

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

From report at bugs.python.org  Tue Feb  8 01:53:01 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 08 Feb 2011 00:53:01 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297126381.26.0.216639259791.issue11129@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

See PEP 391. Documentation is at

http://docs.python.org/library/logging.html#configuration

as you might expect.

----------

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

From report at bugs.python.org  Tue Feb  8 04:16:06 2011
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 08 Feb 2011 03:16:06 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>


New submission from Campbell Barton <ideasman42 at gmail.com>:

Hi, Im buildiong blender3d with  -Werror and python 3.2 gives an error which doesnt happen in 3.1.

Tested with SVN r88378. on linux.
---
cc1: warnings being treated as errors
In file included from /opt/py32/include/python3.2d/Python.h:52:0,
                 from /data/src/blender/blender/source/blender/python/intern/bpy_app.h:27,
                 from /data/src/blender/blender/source/blender/python/intern/bpy_app.c:25:
/opt/py32/include/python3.2d/pyatomic.h: In function '_Py_ANNOTATE_MEMORY_ORDER':
/opt/py32/include/python3.2d/pyatomic.h:59:48: error: unused parameter 'address'


There are 2 ways to solve this:
pyatomic.h could include the line:
    (void)address;

Or the macro's which do nothing could be changed from...
#define _Py_ANNOTATE_HAPPENS_BEFORE(blah) /* empty */
to...
#define _Py_ANNOTATE_HAPPENS_BEFORE(blah) (void)blah

----------
messages: 128165
nosy: ideasman42
priority: normal
severity: normal
status: open
title: _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code which includes Python.h
type: compile error
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb  8 08:51:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Feb 2011 07:51:22 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297151482.63.0.85314864007.issue11144@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Feb  8 09:08:02 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Feb 2011 08:08:02 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297152482.94.0.998735108276.issue11129@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

And how do you intend to parse the dictionary stored in external file? Evaluating this script is unsafe.

----------

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

From report at bugs.python.org  Tue Feb  8 09:08:21 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Feb 2011 08:08:21 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297152501.69.0.114939042602.issue11129@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
type:  -> security

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

From report at bugs.python.org  Tue Feb  8 09:23:44 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Feb 2011 08:23:44 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297153424.55.0.889099946745.issue11144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd call this a bug, albeit a minor one.  The documentation for 'int' says: 

"If the argument is outside the integer range a long object will be returned instead."

... which certainly suggests (without actually formally implying) that an int object should be returned if the argument is within the integer range.

----------

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

From report at bugs.python.org  Tue Feb  8 11:19:29 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Tue, 08 Feb 2011 10:19:29 +0000
Subject: [issue11148] Crash and error message from Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>


New submission from Pham Cong Dinh <pcdinh at gmail.com>:

Quite often, I got the following message printed out the console while I run my Python script

pthread_cond_signal: Undefined error: 0

Or it crashed

https://gist.github.com/799841

Tested with Python 2.6.1 and 2.6.6 (Mac)

What I am trying to do is to set up a logging component that collects all messages sent from child processes to a pipe created by the parent process. The logging component is controlled by a thread created by parent process

----------
components: Interpreter Core
messages: 128168
nosy: pcdinh
priority: normal
severity: normal
status: open
title: Crash and error message from Python VM
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Feb  8 11:38:13 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 08 Feb 2011 10:38:13 +0000
Subject: [issue11129] logging: allow multiple entries in qualname config
In-Reply-To: <1296917082.92.0.764608919678.issue11129@psf.upfronthosting.co.za>
Message-ID: <1297161493.38.0.449205794355.issue11129@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The logging package will not parse any external file to get a dictionary. It's up to the application developer to provide a dictionary which will be used for configuration, so there's no security issue in the stdlib.

----------
type: security -> 

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

From report at bugs.python.org  Tue Feb  8 11:46:47 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 08 Feb 2011 10:46:47 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>


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

clang (as with gcc 4.x) assumes signed integer overflow is undefined. But Python depends on the fact that signed integer overflow wraps. 

Currently configure script adds -fwrapv flag for GCC (added by me back in the day), same should be done with clang.

Patch attached.

----------
components: Build
files: clang-fwrapv.diff
keywords: patch
messages: 128170
nosy: cartman
priority: normal
severity: normal
status: open
title: [PATCH] Configure should enable -fwrapv for clang
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file20717/clang-fwrapv.diff

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

From report at bugs.python.org  Tue Feb  8 11:48:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2011 10:48:31 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297162111.51.0.222680254646.issue11149@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

You should maybe add a test into _testcapi for this issue.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Feb  8 11:49:55 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 08 Feb 2011 10:49:55 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297162195.76.0.495940973629.issue11149@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Currently test_overflow inside test_list fails without this patch. Is that good enough or should we create a specific test?

----------

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

From report at bugs.python.org  Tue Feb  8 12:46:46 2011
From: report at bugs.python.org (Yegor Bugayenko)
Date: Tue, 08 Feb 2011 11:46:46 +0000
Subject: [issue11150] SVN credentials can't be provided to easy_install
In-Reply-To: <1297165606.66.0.401299802091.issue11150@psf.upfronthosting.co.za>
Message-ID: <1297165606.66.0.401299802091.issue11150@psf.upfronthosting.co.za>


New submission from Yegor Bugayenko <team at fazend.com>:

I'm trying to install Python EGG with `easy_install`, providing a URL of Subversion repository, where sources are hosted:

    $ easy_install svn://user:secret at svn.example.com/repo/trunk/my-egg
    Authentication realm: <svn://svn.example.com:3690> repo
    Password for 'me':
    
The problem is that the repository is password protected. How can I provide the desired username/password to `easy_install`?

Everything works fine when I'm using `http://` protocol instead of `svn://`

----------
components: Installation
messages: 128173
nosy: yegor256
priority: normal
severity: normal
status: open
title: SVN credentials can't be provided to easy_install
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  8 13:11:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Feb 2011 12:11:25 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297167085.11.0.825262357602.issue11149@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah, there is already a test for that: ok, it's fine and enough.

----------

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

From report at bugs.python.org  Tue Feb  8 14:03:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 13:03:48 +0000
Subject: [issue8978] "tarfile.ReadError: file could not be opened
	successfully" if compiled without zlib
In-Reply-To: <1276292933.37.0.137444086026.issue8978@psf.upfronthosting.co.za>
Message-ID: <1297170228.67.0.206599198918.issue8978@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Tue Feb  8 14:09:55 2011
From: report at bugs.python.org (Noufal)
Date: Tue, 08 Feb 2011 13:09:55 +0000
Subject: [issue11151] Arguments to various types not specified in types module
In-Reply-To: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>
Message-ID: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>


New submission from Noufal <noufal at nibrahim.net.in>:

The documentation for the types module seems to have an obvious bug. The arguments to create the various types are not mentioned in the docs page on http://docs.python.org/library/types.html

This came to my attention from a stack overflow question here
http://stackoverflow.com/questions/4933325/where-can-i-find-documentation-for-calling-the-various-types-in-pythons-types-mo

----------
assignee: docs at python
components: Documentation
messages: 128175
nosy: docs at python, noufal
priority: normal
severity: normal
status: open
title: Arguments to various types not specified in types module
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Feb  8 14:16:53 2011
From: report at bugs.python.org (Michael Foord)
Date: Tue, 08 Feb 2011 13:16:53 +0000
Subject: [issue11151] Arguments to various types not specified in types module
In-Reply-To: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>
Message-ID: <1297171013.33.0.463608852643.issue11151@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Care to provide a patch Noufal?

----------
nosy: +michael.foord

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

From report at bugs.python.org  Tue Feb  8 14:22:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Feb 2011 13:22:02 +0000
Subject: [issue11148] Crash and error message from Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297171322.8.0.593211997509.issue11148@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Tue Feb  8 14:23:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Feb 2011 13:23:33 +0000
Subject: [issue11147] _Py_ANNOTATE_MEMORY_ORDER has unused argument,
	effects code which includes Python.h
In-Reply-To: <1297134966.47.0.813239114372.issue11147@psf.upfronthosting.co.za>
Message-ID: <1297171413.63.0.479919714626.issue11147@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
nosy: +jyasskin
versions: +Python 3.3

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

From report at bugs.python.org  Tue Feb  8 14:25:52 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Feb 2011 13:25:52 +0000
Subject: [issue11148] Crash and error message from Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297171552.89.0.309430789783.issue11148@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Can you provide a script that shows the problem? Without such a script it will be hard to reproduce, and fix, this problem.

----------

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

From report at bugs.python.org  Tue Feb  8 14:29:36 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Feb 2011 13:29:36 +0000
Subject: [issue11150] SVN credentials can't be provided to easy_install
In-Reply-To: <1297165606.66.0.401299802091.issue11150@psf.upfronthosting.co.za>
Message-ID: <1297171776.99.0.936347154186.issue11150@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

easy_install is not part of python.  Please report this to the easy_install bug tracker instead.

----------
nosy: +r.david.murray, tarek
resolution:  -> later
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  8 15:01:22 2011
From: report at bugs.python.org (Eric Smith)
Date: Tue, 08 Feb 2011 14:01:22 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297173682.39.0.267609751818.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Without guessing which args are options, I don't see how it's possible to implement parse_known_args().

I'd propose raising an exception if it's called and dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one (or whatever it ends up being called) is True.

----------

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

From report at bugs.python.org  Tue Feb  8 16:22:16 2011
From: report at bugs.python.org (labem)
Date: Tue, 08 Feb 2011 15:22:16 +0000
Subject: [issue11152] pb in zipfile module
In-Reply-To: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>
Message-ID: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>


New submission from labem <labem at E-i.com>:

Detected in Python version:
Python 2.6.3 (r263rc1:75186, Oct  2 2009, 20:40:30) [MSC v.1500 32 bit (Intel)] on win32

Error in zipfile module: Zip files with no compressed files may contain only 
   [end of central directory record] bloc
without anything else. In that case, when _EndRecData(fpin) function tries to call:
         return _EndRecData64(fpin, -sizeEndCentDir, endrec)
it makes _EndRecData64() trying to seek data in the file before the beginning of the file and generates IOError "Invalid Argument" which is :
* either badly (in is_zipfile()), 
* or not catched (in __init()__._GetContents()._RealGetContents().EndRecData()).

Correction seems easy (not tested) and just need to replace:
        # Try to read the "Zip64 end of central directory" structure
        return _EndRecData64(fpin, -sizeEndCentDir, endrec)
by:
        # check if other block are present
        if filesize > sizeEndCentDir:
            # Try to read the "Zip64 end of central directory" structure
            return _EndRecData64(fpin, -sizeEndCentDir, endrec)
        else:
        		# no other block present
            return endrec

----------
components: Library (Lib)
messages: 128180
nosy: Emmanuel LAB
priority: normal
severity: normal
status: open
title: pb in zipfile module
type: crash
versions: Python 2.6

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

From johnckint at gmail.com  Tue Feb  8 17:38:15 2011
From: johnckint at gmail.com (johnckint)
Date: Tue, 8 Feb 2011 08:38:15 -0800 (PST)
Subject: Win 7 64 bit Idle editing errors
Message-ID: <30873801.post@talk.nabble.com>


I have 2 new work pc's, one desktop and one laptop and both have Win7 64 bit.

I get very frequent editing errors in Idle editor on these systems. The most
frequent error is 
pasting text into two locations, the one targeted and the other one randomly
somewhere else in the file.

This happens on both Python 32 bit and 64 bit versions. 

>From recent experience, these errors do not happen on XP, Vista, or Win 7-32
bit systems.

Is there a cure or am I forced to change to other pc's?

Thanks for any suggestions.
-- 
View this message in context: http://old.nabble.com/Win-7-64-bit-Idle-editing-errors-tp30873801p30873801.html
Sent from the Python - python-bugs-list mailing list archive at Nabble.com.


From report at bugs.python.org  Tue Feb  8 19:13:31 2011
From: report at bugs.python.org (Don Dwiggins)
Date: Tue, 08 Feb 2011 18:13:31 +0000
Subject: [issue4142] smtplib doesn't clear helo/ehlo flags on quit
In-Reply-To: <1224273762.79.0.0391835714009.issue4142@psf.upfronthosting.co.za>
Message-ID: <1297188811.1.0.0636087649466.issue4142@psf.upfronthosting.co.za>


Don Dwiggins <ddwiggins at advpubtech.com> added the comment:

I have no pressing need for it.  I'm happy enough with Martin's idea of single-use instances, as long as they're clearly documented as such, and don't "pretend" to work for a subsequent connect.  I'd also be happy with instances that could be used for multiple connections, as long as that didn't increase the complexity of the code too much.

Martin's also right that the similar clients for http and ftp, as well as smtp, should all work the same.

----------

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

From report at bugs.python.org  Tue Feb  8 19:48:07 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2011 18:48:07 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1297190887.39.0.34017366759.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Updated patch that applies cleanly.

----------
Added file: http://bugs.python.org/file20718/issue10990.diff

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

From report at bugs.python.org  Tue Feb  8 19:48:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2011 18:48:16 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1297190896.28.0.172508432165.issue10990@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20620/issue_10990.diff

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

From report at bugs.python.org  Tue Feb  8 19:52:17 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2011 18:52:17 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297191137.33.0.277981467636.issue11149@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I am using LLVM/Clang 2.8 and test_list passes fine for me as-is. Does it only fail under 32 or 64-bit conditions? Configure compiles under 32-bits for me even though I have -arch x86_64 set.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Feb  8 19:55:09 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 08 Feb 2011 18:55:09 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297191309.94.0.125623920495.issue11149@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

This is only reproducable with clang 2.9 trunk builds due to new optimizations. Also note that clang commits confirm that -fwrapv must be provided if you assume signed integer overflow wraps. This was also the case with a spec test.

I tested this on OSX 10.6.6 with x86-64 build.

----------

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

From report at bugs.python.org  Tue Feb  8 20:09:54 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Feb 2011 19:09:54 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1297192194.99.0.775226779751.issue10951@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I can see how a comment like /* spam = eggs + ham */ could be useful, but and isolated /* foo = 0 */ where 'foo' appears nowhere else in the file seems more like confusing noise.

----------

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

From report at bugs.python.org  Tue Feb  8 20:14:05 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Feb 2011 19:14:05 +0000
Subject: [issue10951] gcc 4.6 warnings
In-Reply-To: <1295474318.57.0.129834114348.issue10951@psf.upfronthosting.co.za>
Message-ID: <1297192445.46.0.082620486084.issue10951@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You're right, Terry. It's a judgment call as to what should be simply deleted compared to commented out.

----------

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

From report at bugs.python.org  Tue Feb  8 21:01:47 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 08 Feb 2011 20:01:47 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1297195307.84.0.272272298794.issue6378@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

There is a bug with the patch. The first argument to the `start` command, if a quoted string, becomes the Window title, not the command to execute. Hence, idle.pyw is directly executed by Windows. Here's the correct command line:

start "IDLELAUNCH" "%CURRDIR%..\..\pythonw.exe" "%CURRDIR%idle.pyw" %1 %2 %3 %4 %5 %6 %7 %8 %9

Could you make this fix part of the upcoming 3.2?

----------
status: closed -> pending

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

From report at bugs.python.org  Tue Feb  8 21:15:40 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Feb 2011 20:15:40 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1297196140.8.0.0131357411415.issue6378@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

We're only a few days away from 3.2 final so it's too late. Once it goes out I'll make the adjustment and it'll be in 3.2.1.

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: pending -> open

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

From report at bugs.python.org  Tue Feb  8 21:16:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 08 Feb 2011 20:16:28 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297153424.55.0.889099946745.issue11144@psf.upfronthosting.co.za>
Message-ID: <4D51A49A.7040208@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'd call this a bug, albeit a minor one.  The documentation for 'int' says: 
> 
> "If the argument is outside the integer range a long object will be returned instead."

Ah ok. I agree it's a bug, then.

----------

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

From report at bugs.python.org  Tue Feb  8 21:41:20 2011
From: report at bugs.python.org (Matthew M. Boedicker)
Date: Tue, 08 Feb 2011 20:41:20 +0000
Subject: [issue11153] urllib2 basic auth parser handle unquoted realm in
	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>


New submission from Matthew M. Boedicker <matthewm at boedicker.org>:

I am working with a web server that does not quote the realm in the WWW-Authenticate header.

This patch will make the realm parsing handle unquoted realm as well as some other invalid variations.

I tried doing it by modifying the regex only but could not get it to handle all cases.

----------
components: Library (Lib)
files: urllib2_unquoted_realm.diff
keywords: patch
messages: 128190
nosy: mmb
priority: normal
severity: normal
status: open
title: urllib2 basic auth parser handle unquoted realm in WWW-Authenticate header
Added file: http://bugs.python.org/file20719/urllib2_unquoted_realm.diff

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

From report at bugs.python.org  Tue Feb  8 21:42:45 2011
From: report at bugs.python.org (Matthew M. Boedicker)
Date: Tue, 08 Feb 2011 20:42:45 +0000
Subject: [issue11153] urllib2 basic auth parser handle unquoted realm in
	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1297197765.11.0.0567898687775.issue11153@psf.upfronthosting.co.za>


Changes by Matthew M. Boedicker <matthewm at boedicker.org>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Feb  8 22:47:33 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 08 Feb 2011 21:47:33 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1297201653.3.0.223750360481.issue2889@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Curses binaries for Python 2.5, 2.6, 2.7, 3.1 and 3.2, win32 and win-amd64, are available at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses>.

----------

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

From report at bugs.python.org  Tue Feb  8 23:13:04 2011
From: report at bugs.python.org (Oren Held)
Date: Tue, 08 Feb 2011 22:13:04 +0000
Subject: [issue10800] libffi build failure on HP-UX 11/PA
In-Reply-To: <1293780948.24.0.107395792812.issue10800@psf.upfronthosting.co.za>
Message-ID: <1297203184.89.0.0346143730944.issue10800@psf.upfronthosting.co.za>


Oren Held <oren at held.org.il> added the comment:

quick update: libffi (upstream) has this fixed now in git commit dc411e8f991 .

----------

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

From report at bugs.python.org  Tue Feb  8 23:40:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 22:40:57 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1263669405.52.0.706975841329.issue7719@psf.upfronthosting.co.za>
Message-ID: <1297204857.1.0.636614880416.issue7719@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch (I think SilentGhost?s version is better).  Do you have any pointer about those .nfs* files?  Are there other (build) tools that ignore them?  Is it always safe to skip .nfs* files, or only .nfs????? (i.e. six characters)?

Aside from those questions, a patch requires a test and doc update.  See guidelines at http://wiki.python.org/moin/Distutils/FixingBugs

----------
components: +Distutils2
nosy: +eric.araujo
versions: +3rd party

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

From report at bugs.python.org  Tue Feb  8 23:43:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Feb 2011 22:43:56 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>


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

It would be great if the "__pycache__" name could be set by an environment variable.  I would like to rename it to ".pycache" so that it doesn't pollute my directory listings.

----------
assignee: barry
messages: 128194
nosy: barry, rhettinger
priority: normal
severity: normal
status: open
title: Alternate name for __pycache__
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  8 23:45:52 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 08 Feb 2011 22:45:52 +0000
Subject: [issue7719] distutils: ignore .nfsXXXX files
In-Reply-To: <1297204857.1.0.636614880416.issue7719@psf.upfronthosting.co.za>
Message-ID: <AANLkTikWgKR8dnWh+vHOPmp9Q1UD_mY_74FqKDuxBL+E@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Tue, Feb 8, 2011 at 23:40, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Do you have any pointer about those .nfs* files? ?Are there other (build) tools that ignore them? ?Is it always safe to skip .nfs* files, or only .nfs????? (i.e. six characters)?

Just replying for this part: .nfs* files are created by the nfs server
when on of its client removes a file while another client has the very
same file opened. the nfs server keeps the .nfs* file around until the
last client closes the file, after that it removes the .nfs* file.

About the number of digits after '.nfs' I'm not sure there's a
standard for it, but I saw files with more that 6 chars after that.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Tue Feb  8 23:46:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 22:46:55 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297205215.54.0.147711562443.issue11145@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The doc for %o only says it returns the ?signed octal value?; __oct__ is not a magic method (i.e. it?s not a name with special meaning), converting with oct() actually uses __index__.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Feb  8 23:52:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 22:52:34 +0000
Subject: [issue11151] Arguments to various types not specified in types module
In-Reply-To: <1297170595.74.0.556473568639.issue11151@psf.upfronthosting.co.za>
Message-ID: <1297205554.49.0.643066152981.issue11151@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Remember that the types module is mostly obsolete now: a type like IntType is described as alias for the builtin int, with a link to the comprehensive document of said int.

(On an unrelated note, the types module may encourage type-checking, which is not common or generally useful in Python.  Too bad it couldn?t be removed wholesale in 3.x.)

That said, adding documentation for other cases like ModuleType and CodeType that aren?t defined anywhere else in the stdlib is indeed a good idea.

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Feb  8 23:55:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 22:55:36 +0000
Subject: [issue11152] pb in zipfile module
In-Reply-To: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>
Message-ID: <1297205736.69.0.484390630356.issue11152@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +alanmcintyre

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

From report at bugs.python.org  Tue Feb  8 23:56:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Feb 2011 22:56:12 +0000
Subject: [issue11152] pb in zipfile module
In-Reply-To: <1297178536.07.0.390050074188.issue11152@psf.upfronthosting.co.za>
Message-ID: <1297205772.34.0.948689900664.issue11152@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> test needed
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Wed Feb  9 00:06:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 08 Feb 2011 23:06:21 +0000
Subject: [issue6005] Bug in socket example
In-Reply-To: <1242137945.24.0.461546436751.issue6005@psf.upfronthosting.co.za>
Message-ID: <1297206381.02.0.368961721978.issue6005@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi all,
I was looking at this issue and thought: ok the module documentation uses send() not correctly, so we should fix that; the fastest solution is using sendall().

But then searching fro some examples in the code on internet, I found that the python docs contain a "Socket Programming HOWTO" that uses send() the way it should be.

So, should we:

- replace send() with sendall() in socket module documentation (explaining it was done to not clutter examples) and
- add a reference to the socket programming howto to show a way to use send() correctly?

Cheers,
Sandro

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Wed Feb  9 00:24:47 2011
From: report at bugs.python.org (Kevin Le)
Date: Tue, 08 Feb 2011 23:24:47 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1297207487.88.0.00939513616252.issue940286@psf.upfronthosting.co.za>


Kevin Le <solnovus at gmail.com> added the comment:

confirmed, I'll take a closer look

----------

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

From report at bugs.python.org  Wed Feb  9 01:35:47 2011
From: report at bugs.python.org (Erik Cederstrand)
Date: Wed, 09 Feb 2011 00:35:47 +0000
Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs
In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>
Message-ID: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>


New submission from Erik Cederstrand <ec at 1calendar.dk>:

In Python 2.6.6 on OSX:

>>> import inspect
>>> from multiprocessing import Queue
>>> q = Queue()
>>> print(inspect.getargspec(q.put))
ArgSpec(args=['self', 'obj', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None))
>>> from Queue import Queue
>>> q = Queue()
>>> print(inspect.getargspec(q.put))
ArgSpec(args=['self', 'item', 'block', 'timeout'], varargs=None, keywords=None, defaults=(True, None))

Notice the 'obj' argument in the multiprocessing version and the 'item' argument in the Queue version. I think 'obj' should be renamed to 'item' to be in line with the other implementation and to agree with the docs: (http://docs.python.org/library/multiprocessing.html?highlight=multiprocessing#multiprocessing.Queue.put):

    put(item[, block[, timeout]])

----------
assignee: docs at python
components: Documentation
messages: 128200
nosy: Erik.Cederstrand, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.Queue's put() signature differs from docs
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 01:56:07 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 09 Feb 2011 00:56:07 +0000
Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs
In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za>
Message-ID: <1297212967.67.0.860677116212.issue11155@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

I've gone through Lib/multiproccing/queues.py and have replaced obj with item. Here's the patch.

----------
keywords: +patch
nosy: +anikom15
Added file: http://bugs.python.org/file20720/multiprocessing-11155.diff

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

From report at bugs.python.org  Wed Feb  9 02:24:19 2011
From: report at bugs.python.org (Jonathan Beezley)
Date: Wed, 09 Feb 2011 01:24:19 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297214659.08.0.476585570962.issue4681@psf.upfronthosting.co.za>


Changes by Jonathan Beezley <jon.beezley at gmail.com>:


----------
nosy: +jbeezley

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

From report at bugs.python.org  Wed Feb  9 03:10:00 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Wed, 09 Feb 2011 02:10:00 +0000
Subject: [issue11156] email.encoders.encode_base64 create a single long line
In-Reply-To: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>
Message-ID: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>


New submission from Yves Dorfsman <yves at zioup.com>:

email.encoders.encode_base64 returns a str of a single long line instead of breaking it up into 76 chars line as per RFC 2045, and as implemented by email.base64mime.

Solution:
In /usr/lib/python3.1/email/encoders.py, use encodebytes instead of b64encode:

--- encoders.py 2011-02-08 09:37:21.025030051 -0700
+++ encoders.py.yves    2011-02-08 09:38:04.945608365 -0700
@@ -12,7 +12,7 @@
     ]
 
 
-from base64 import b64encode as _bencode
+from base64 import encodebytes as _bencode
 from quopri import encodestring as _encode

----------
components: Library (Lib)
messages: 128202
nosy: yves at zioup.com
priority: normal
severity: normal
status: open
title: email.encoders.encode_base64 create a single long line
versions: Python 3.1

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

From report at bugs.python.org  Wed Feb  9 05:55:43 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 09 Feb 2011 04:55:43 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1297227343.53.0.61704741434.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Here's a revised version of bz2-v3.diff, with docstrings that are more consistent with the updated documentation.

----------

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

From report at bugs.python.org  Wed Feb  9 05:57:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 09 Feb 2011 04:57:20 +0000
Subject: [issue5863] bz2.BZ2File should accept other file-like objects.
In-Reply-To: <1240898269.47.0.592056792771.issue5863@psf.upfronthosting.co.za>
Message-ID: <1297227440.11.0.242811754301.issue5863@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Weird, the patch didn't upload...

----------
Added file: http://bugs.python.org/file20721/bz2-v3b.diff

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

From report at bugs.python.org  Wed Feb  9 06:37:30 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 09 Feb 2011 05:37:30 +0000
Subject: [issue11157] Use socket.accept4 syscall under linux
In-Reply-To: <1297229850.72.0.00775605650951.issue11157@psf.upfronthosting.co.za>
Message-ID: <1297229850.72.0.00775605650951.issue11157@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

socket.accept() should have optional argument flags. see 'man accept4'
It should use fcntl() if accept4() not supported.

This is performance issue.

----------
components: IO, Library (Lib)
messages: 128205
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Use socket.accept4 syscall under linux
type: feature request

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

From report at bugs.python.org  Wed Feb  9 09:25:51 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Wed, 09 Feb 2011 08:25:51 +0000
Subject: [issue11158] Parent process did not quit after sys.exit()
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>


New submission from Pham Cong Dinh <pcdinh at gmail.com>:

Hi,

I was implementing a multiple process compatible logging which child processes are expected to send all messages to the parent process via a queue and then the parent process serializes and flushes them into a log file. The idea is built around multiprocessing.Queue()

The problem is the first child process is always blocked while subsequent ones can run smoothly. It seems to be blocked on semaphore_wait_signal_trap

Environment
===========
Mac OS X 10.6.5 
Python 2.6.6

Reproduction script:
====================
https://gist.github.com/818114

Command to run
====================

python log.py

Console message
===============
Dinh-Phams-MacBook-Pro:task dinhpham$ python log.py
Parent PID 90401
90403
Parent PID 90401
Parent PID 90401
90404
Parent PID 90401
90405
No child process exits
90406
Child process ID 90406
Child process ID 90404
Child process ID 90405
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
Child process PID 90404 will exits now
Child process PID 90406 will exits now
Child process PID 90405 will exits now
The child process 90406 exits
The child process 90405 exits
The child process 90404 exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
No child process exits
^C[90403]
Parent process exits
Dinh-Phams-MacBook-Pro:task dinhpham$ 
 


=========> All the process exits except the first child process one (90403)

----------
components: Interpreter Core
messages: 128206
nosy: pcdinh
priority: normal
severity: normal
status: open
title: Parent process did not quit after sys.exit()
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 09:41:26 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Wed, 09 Feb 2011 08:41:26 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297240886.82.0.174781737218.issue11158@psf.upfronthosting.co.za>


Changes by Pham Cong Dinh <pcdinh at gmail.com>:


----------
title: Parent process did not quit after sys.exit() -> Python VM deadlock

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

From report at bugs.python.org  Wed Feb  9 10:11:33 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 09 Feb 2011 09:11:33 +0000
Subject: [issue11153] urllib2 basic auth parser handle unquoted realm in
	WWW-Authenticate header
In-Reply-To: <1297197679.85.0.254643170537.issue11153@psf.upfronthosting.co.za>
Message-ID: <1297242693.23.0.413485484682.issue11153@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Wed Feb  9 11:49:56 2011
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 09 Feb 2011 10:49:56 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297248596.82.0.624108238206.issue11145@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Eric: that's wrong, it is a magic method.  See for example "__oct__" in Objects/typeobject.c.  I'm not sure I understand why you would point this out, though.  A "SystemError: bad argument to internal function" or an "Assertion failed" are both bugs anyway.

----------

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

From report at bugs.python.org  Wed Feb  9 11:58:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 10:58:40 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297249120.07.0.547226757626.issue11145@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Wed Feb  9 13:42:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 12:42:01 +0000
Subject: [issue11157] Use socket.accept4 syscall under linux
In-Reply-To: <1297229850.72.0.00775605650951.issue11157@psf.upfronthosting.co.za>
Message-ID: <1297255321.22.0.401964512382.issue11157@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a duplicate of issue10115.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Support accept4() for atomic setting of flags at socket creation

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

From report at bugs.python.org  Wed Feb  9 13:42:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 12:42:25 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1297255345.67.0.440821338606.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicated in issue11157.

----------
nosy: +mmarkk

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

From report at bugs.python.org  Wed Feb  9 13:44:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 12:44:09 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297255449.68.0.226706277435.issue11158@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Wed Feb  9 13:54:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 12:54:18 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297256058.48.0.0878097918617.issue4681@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for doing this. Looking at the patch: Modules/_io/_iomodule.h has macros for dealing with off_t (it also defines Py_off_t for Windows), perhaps you want to use them.

Also, support.unlink() takes care of ignoring ENOENT for you.

Regardling the sizes used in the test: I think using hexadecimal literals (e.g. 0x180000000 instead of 6442450944) would make things a bit more readable :)

Part of the patch doesn't apply cleanly to latest py3k. Could you regenerate it, please?

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Feb  9 15:03:05 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Feb 2011 14:03:05 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1297260185.89.0.715555448917.issue11145@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's a magic method in 2.7 but not 3.x.

----------

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

From report at bugs.python.org  Wed Feb  9 15:20:03 2011
From: report at bugs.python.org (Rickard Lindberg)
Date: Wed, 09 Feb 2011 14:20:03 +0000
Subject: [issue11159] Sax parser crashes if given unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>


New submission from Rickard Lindberg <ricli85 at gmail.com>:

The error is the following:

    Traceback (most recent call last):
      File "<stdin>", line 4, in <module>
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/__init__.py", line 31, in parse
        parser.parse(filename_or_stream)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
        xmlreader.IncrementalParser.parse(self, source)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/xmlreader.py", line 119, in parse
        self.prepareParser(source)
      File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 121, in prepareParser
        self._parser.SetBase(source.getSystemId())
    UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in position 0: ordinal not in range(128)

The following bash script can be used to reproduce the error:

    #!/bin/sh

    cat > ?.timeline <<EOF
    <?xml version="1.0" encoding="utf-8"?>
    <timeline>
      <version>0.13.0devb38ace0a572b+</version>
      <categories>
      </categories>
      <events>
        <event>
          <start>2011-02-01 00:00:00</start>
          <end>2011-02-03 08:46:00</end>
          <text>asdsd</text>
        </event>
      </events>
      <view>
        <displayed_period>
          <start>2011-01-24 16:38:11</start>
          <end>2011-02-23 16:38:11</end>
        </displayed_period>
        <hidden_categories>
        </hidden_categories>
      </view>
    </timeline>
    EOF

    python <<EOF
    # encoding: utf-8
    from xml.sax import parse
    from xml.sax.handler import ContentHandler
    parse(open(u"?.timeline", 'r'), ContentHandler())
    EOF

If I instead do this, it works fine:

    parse(u"?.timeline".encode("utf-8"), ContentHandler())

Also:

    >>> sys.getfilesystemencoding()
    'UTF-8'

I heard from another user that this was not a problem with Python 3.1.2.

----------
components: XML
messages: 128212
nosy: ricli85
priority: normal
severity: normal
status: open
title: Sax parser crashes if given unicode file name
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  9 15:37:17 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Wed, 09 Feb 2011 14:37:17 +0000
Subject: [issue11156] email.encoders.encode_base64 create a single long line
In-Reply-To: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>
Message-ID: <1297262237.56.0.414373883632.issue11156@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

In case this does not get fixed for a long time, here is a work around (re-implement the encoder yourself):


.
.
.
def myencoder(msg):
  from base64 import encodebytes as _bencode

  orig = msg.get_payload()
  encdata = str(_bencode(orig), 'ascii')
  msg.set_payload(encdata)
  msg['Content-Transfer-Encoding'] = 'base64'
.
.
.
# here is an example of how to use it
fp = open('/usr/share/openclipart/png/animals/mammals/happy_monkey_benji_park_01.png', 'rb')

bindata = fp.read()

x = email.mime.image.MIMEImage(bindata, _subtype='png', _encoder=myencoder)

y = x.get_payload()
print (y)
.
.
.

----------

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

From report at bugs.python.org  Wed Feb  9 15:49:41 2011
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 09 Feb 2011 14:49:41 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297262981.67.0.197753117819.issue941346@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

S?bastien, why did you need to add '-L$(srcdir)' to BLDSHARED in these patches?

As LDLIBRARY points to the immediate file 'libpython$(VERSION).so' instead of '-lpython$(VERSION)', I don't see the need for '-L$(srcdir)' at all.

The problem is that '-L$(srcdir)' adds '$(srcdir)' to the runpath too (as there is no '-blibpath' argument), opening a security hole for libpythonX.Y.so as well as the modules.so.

----------
nosy: +haubi

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

From report at bugs.python.org  Wed Feb  9 15:52:42 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Feb 2011 14:52:42 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297263162.92.0.000101101723945.issue4681@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

OK, this new patch applies cleanly, uses support.unlink and hexadecimal constants.

I left the off_t handling as is (it seems to work on *nix testing). Perhaps someone can handle the Windows side?

----------
Added file: http://bugs.python.org/file20722/mmap_revised.patch

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

From report at bugs.python.org  Wed Feb  9 15:55:21 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 09 Feb 2011 14:55:21 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1297263321.56.0.705631321233.issue10694@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

I've attached a patch copying rep's patch from issue 10298, as i think it is cleaner (but it seems to do the same thing as kevin's patch) together with 2 test cases. 

David Murray: I'm not really sure what you mean by "test comments with trailing data"; as I understand, the way to fix the problem is simply to remove the excessively strict check that the length the zip file claims to have is equal to the actual amount of comments found by truncating comments to the claimed size; if that's the case my (new) test should be enough to exercise that logic. Please correct me if I misunderstand.

----------
Added file: http://bugs.python.org/file20723/reps_patch_and_two_tests.diff

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

From report at bugs.python.org  Wed Feb  9 16:09:01 2011
From: report at bugs.python.org (Xuanji Li)
Date: Wed, 09 Feb 2011 15:09:01 +0000
Subject: [issue11160] ZipFile.comment expects bytes
In-Reply-To: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>
Message-ID: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>


New submission from Xuanji Li <xuanji at gmail.com>:

The documentation for zipfile describes ZipFile.comment as "The comment text associated with the ZIP file." From reading this I expect that setting it to a string is ok; however ZipFile.comment must actually be set to bytes (or a bytes-like object, I am not very sure).

This may also unexpectedly affect old code because I saw one patch on the bug tracker that was written just last year that set ZipFile.comment to a string. 

IMO there are 2 ways to fix:

1) Change docs to mention that ZipFile.comment only accepts bytes
2) Patch zipfile.py to accept string and try to convert, throwing an error if the conversion fails

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 128217
nosy: docs at python, haypo, xuanji
priority: normal
severity: normal
status: open
title: ZipFile.comment expects bytes
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  9 17:11:42 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 16:11:42 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1297267902.47.0.203707891867.issue10694@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Xuanji: yes, your test_ignores_stuff_appended_past_comments is exactly what I was asking for.  I've put this patch on my review list, but I may not get to it until after 3.2 final.

----------

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

From report at bugs.python.org  Wed Feb  9 17:19:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 16:19:04 +0000
Subject: [issue11156] email.encoders.encode_base64 create a single long line
In-Reply-To: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>
Message-ID: <1297268344.0.0.00866210230877.issue11156@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This appears to be a duplicate of issue 9298.  Yves, if you disagree let me know what's different.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  9 17:19:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 16:19:49 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297268389.01.0.986576040304.issue9298@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also duplicate issue 11156.

----------
nosy: +yves at zioup.com

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

From report at bugs.python.org  Wed Feb  9 17:19:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 16:19:59 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297268399.55.0.597643423386.issue9298@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Wed Feb  9 17:20:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 16:20:38 +0000
Subject: [issue11156] email.encoders.encode_base64 create a single long line
In-Reply-To: <1297217400.48.0.931931004137.issue11156@psf.upfronthosting.co.za>
Message-ID: <1297268438.58.0.616008764346.issue11156@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
superseder:  -> binary email attachment issue with base64 encoding

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

From report at bugs.python.org  Wed Feb  9 17:33:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 16:33:27 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297269207.23.0.745333013428.issue11154@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Wed Feb  9 17:41:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 09 Feb 2011 16:41:11 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297269671.2.0.101001209929.issue11154@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hmm. That's problematic.  How would that interact with a system Python that is already looking in __pycache__ for its pyc files?  Would it suddenly start ignoring those and wanting to write them to .pycache?

IIRC we thought about something like this during the PEP discussions and Guido nixed it.

-1

----------

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

From report at bugs.python.org  Wed Feb  9 17:53:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Feb 2011 16:53:21 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297270401.53.0.252693270998.issue11154@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Wed Feb  9 17:55:15 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 09 Feb 2011 16:55:15 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297269671.2.0.101001209929.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297270510.1353.6.camel@radiator.bos.redhat.com>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

On Wed, 2011-02-09 at 16:41 +0000, Barry A. Warsaw wrote:

> IIRC we thought about something like this during the PEP discussions and Guido nixed it.

FWIW, the closest I could find was this mail:
  http://www.mail-archive.com/python-dev at python.org/msg45203.html
(doesn't seem to be in the mail.python.org archives)
where GvR said:
> Because we don't want to completely hide the pyc files. Also the dot
> naming convention is somewhat platform-specific.

(FWIW, I wish we'd gone for .pycache too, but I guess it's too late to change now)

----------
nosy: +dmalcolm

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

From report at bugs.python.org  Wed Feb  9 18:18:27 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 09 Feb 2011 17:18:27 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297271907.43.0.202663185562.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

On a second thought I have two complaints.

There is no reason to return the file offset, also because this is only supported on Linux. On all other platforms we are calculating the file offset by making a sum of offset + number of bytes sent. Despite this would normally work it no longer makes sense when headers/trailers arguments are specified.

>>> sendfile(in, out, offset, 4096, headers=[b"xxxx"])
(5000, 5000)

In this case the right offset is supposed to be 4096.
We might adjust this in the code but in my opinion knowing the file offset is not really necessary as what the user really needs is the number of bytes sent, as when using socket.send().

My second complaint is about headers/trailers data type.
Currently we are passing a sequence of buffers (tipically a list) but I think we should pass plain bytes instead.

----------

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

From report at bugs.python.org  Wed Feb  9 18:23:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 17:23:36 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297272216.72.0.949501023248.issue11154@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with barry's argument and also with Marc-Andr?'s argument on python-ideas. Your directories are far cleaner than before with pyc files all around, so what is the problem exactly?

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Feb  9 18:36:35 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Feb 2011 17:36:35 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297272995.21.0.8930740719.issue11154@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That makes sense.  Making it configurable would lose some of the benefits.

What we could do though, before 3.2 goes out, is change the name to ".pycache" to follow the dot-file naming convention and avoid cluttering directory listings.

----------
priority: normal -> high
versions: +Python 3.2 -Python 3.3

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

From report at bugs.python.org  Wed Feb  9 18:37:01 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Wed, 09 Feb 2011 17:37:01 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297273021.27.0.90102323403.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

OK, I'm happy to not return the file offset. However, I still think that headers and trailers should remain as is since this matches the native interface very closely.

----------

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

From report at bugs.python.org  Wed Feb  9 18:54:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Feb 2011 17:54:53 +0000
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297205036.4.0.222366032946.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297274093.46.0.673655696379.issue11154@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I just saw a post from Guido saying that he doesn't want the directory to be invisible.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  9 19:03:19 2011
From: report at bugs.python.org (paul clinch)
Date: Wed, 09 Feb 2011 18:03:19 +0000
Subject: [issue11161] futures.ProcessPoolExecutor hangs
In-Reply-To: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>
Message-ID: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>


New submission from paul clinch <pclinch at internet-glue.co.uk>:

The example ``16.4.3.1. ProcessPoolExecutor Example`` hangs in IDLE silently,  and hangs the interactive python shell with ``AttributeError: 'module' object has no attribute 'is_prime'``.

is_prime(9) was tested before running.

Platform is windows XP.

``c:\Python32\python.exe -m test.test_concurrent_futures``

passes all tests.

----------
components: IDLE
messages: 128228
nosy: pclinch
priority: normal
severity: normal
status: open
title: futures.ProcessPoolExecutor hangs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Feb  9 19:25:20 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 18:25:20 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1297275920.23.0.543408161056.issue5833@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

How should we move forward with this issue?
J Evens: are you willing to split the patch in smaller ones that can be more easily managed/reviewed/applied?
Antoine: do you think it's worth the effort?

I can also try to split the patch, but what branch should I target: py3k?

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Wed Feb  9 19:33:18 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 18:33:18 +0000
Subject: [issue4696] email module does not unfold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1297276398.16.0.598258248464.issue4696@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi David, AFAIUI in py3k branch I see email module has version 5.1.0 so I guess the new email module will be targetting 3.3 - am I correct? what should we do with this issue?

----------
nosy: +sandro.tosi
stage:  -> patch review

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

From report at bugs.python.org  Wed Feb  9 19:40:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 18:40:36 +0000
Subject: [issue6544] Fix refleak in kqueue implementation
In-Reply-To: <1248249167.8.0.187501055293.issue6544@psf.upfronthosting.co.za>
Message-ID: <1297276836.09.0.850228284947.issue6544@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Georg, are you planning to backport this patch also to 3.1 or else can we close this issue? Cheers!

----------
nosy: +sandro.tosi
stage:  -> committed/rejected

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

From report at bugs.python.org  Wed Feb  9 20:16:40 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Feb 2011 19:16:40 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297279000.63.0.261792391115.issue11158@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't believe this is an interpreter or stdlib problem. See this post from September last year:

http://plumberjack.blogspot.com/2010/09/using-logging-with-multiprocessing.html

which shows how to use multiprocessing and logging together with rotating logs. The post includes the code for a complete working script which runs fine with Python 2.6 on Windows and Linux, but which I can't test on Mac OS X/Python 2.6 as I have no access to a Snow Leopard system.

You're welcome to run that script on your system and update this issue with your results - so I'm marking as "invalid" for now (as I don't believe there's a valid Python issue) and "pending" awaiting your feedback. If I don't hear from you in the next week or so, I'll close this issue.

----------
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Wed Feb  9 20:17:05 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Feb 2011 19:17:05 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297279025.53.0.551238123466.issue11158@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
assignee:  -> vinay.sajip
status: pending -> open

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

From report at bugs.python.org  Wed Feb  9 20:22:13 2011
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Feb 2011 19:22:13 +0000
Subject: [issue11161] futures.ProcessPoolExecutor hangs
In-Reply-To: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>
Message-ID: <1297279333.34.0.910967957212.issue11161@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> bquinlan
nosy: +bquinlan

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

From report at bugs.python.org  Wed Feb  9 20:33:43 2011
From: report at bugs.python.org (Arty)
Date: Wed, 09 Feb 2011 19:33:43 +0000
Subject: [issue4216] subprocess.Popen hangs at communicate() when child exits
In-Reply-To: <1225151867.64.0.844146967045.issue4216@psf.upfronthosting.co.za>
Message-ID: <1297280023.96.0.0316881971141.issue4216@psf.upfronthosting.co.za>


Arty <elmy at promosales.ru> added the comment:

You can try subprocess.call() with close_fds=True.
It helped me, at least.

----------
nosy: +elmysnail

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

From report at bugs.python.org  Wed Feb  9 20:44:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 09 Feb 2011 19:44:06 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297280646.77.0.353120570792.issue11158@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: open -> pending

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

From report at bugs.python.org  Wed Feb  9 20:46:23 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 09 Feb 2011 19:46:23 +0000
Subject: [issue11162] Add tuple/list sep to string split method
In-Reply-To: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>
Message-ID: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I was hoping that I could use a list/tuple of separators for the split method:

    "abcde".split(["b", "d"])

vs.

    import re
    re.split("b|d", "abcde")

That's one extra LOC, and (worse still) forces me to learn regexp.

Does this suggested 'improvement' make sense?

----------
components: Library (Lib)
messages: 128234
nosy: tshepang
priority: normal
severity: normal
status: open
title: Add tuple/list sep to string split method

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

From dmalcolm at redhat.com  Wed Feb  9 17:55:10 2011
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 09 Feb 2011 11:55:10 -0500
Subject: [issue11154] Alternate name for __pycache__
In-Reply-To: <1297269671.2.0.101001209929.issue11154@psf.upfronthosting.co.za>
References: <1297269671.2.0.101001209929.issue11154@psf.upfronthosting.co.za>
Message-ID: <1297270510.1353.6.camel@radiator.bos.redhat.com>

On Wed, 2011-02-09 at 16:41 +0000, Barry A. Warsaw wrote:

> IIRC we thought about something like this during the PEP discussions and Guido nixed it.

FWIW, the closest I could find was this mail:
  http://www.mail-archive.com/python-dev at python.org/msg45203.html
(doesn't seem to be in the mail.python.org archives)
where GvR said:
> Because we don't want to completely hide the pyc files. Also the dot
> naming convention is somewhat platform-specific.

(FWIW, I wish we'd gone for .pycache too, but I guess it's too late to change now)


From report at bugs.python.org  Wed Feb  9 21:02:24 2011
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 09 Feb 2011 20:02:24 +0000
Subject: [issue11162] Add tuple/list sep to string split method
In-Reply-To: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>
Message-ID: <1297281744.27.0.200512446382.issue11162@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
components: +Interpreter Core -Library (Lib)

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

From report at bugs.python.org  Wed Feb  9 21:08:30 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Feb 2011 20:08:30 +0000
Subject: [issue11162] Add tuple/list sep to string split method
In-Reply-To: <1297280783.19.0.370230386976.issue11162@psf.upfronthosting.co.za>
Message-ID: <1297282110.12.0.0449089115539.issue11162@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Does this suggested 'improvement' make sense?

Sorry, it doesn't make sense for a number of reasons.

* First the str.split() is already too complex.  It took years to get the docs for it to be correct and informative (two different algorithms, etc).

* Second, it would overly complicate the implementation and preclude various kinds of string search optimizations (i.e. that is why fgrep, grep, and egrep are still separate).

* Third, at some point, when you need a regex, you just need to use a regex.  It would be a mistake to reinvent regex capabilities in string objects.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  9 21:18:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 20:18:23 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297282703.4.0.375507110708.issue4681@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I left the off_t handling as is (it seems to work on *nix testing).
> Perhaps someone can handle the Windows side?

Ok, after looking at the code, it appears Windows already should have proper handling of 64-bit sizes under 32-bit builds.

----------

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

From report at bugs.python.org  Wed Feb  9 21:40:09 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Feb 2011 20:40:09 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297284009.08.0.894852336514.issue11144@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This turns out to be a one-line fix (modulo comments and tests); see attached patch.  The new code depends on the assumption that C longs are represented using two's complement, but note that this assumption is (a) already present elsewhere in the Python core (e.g., in the definition of bitwise operations for ints), and (b) universally true in practice (as far as I'm aware).  For theoretical completeness, it would be easy to write a different test for ones' complement and sign-magnitude machines, but in practice that seems pointless, and given the near-impossibility of testing that code, I left it out.

----------
keywords: +patch
Added file: http://bugs.python.org/file20724/issue11144.patch

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

From report at bugs.python.org  Wed Feb  9 21:40:45 2011
From: report at bugs.python.org (Michael Grazebrook)
Date: Wed, 09 Feb 2011 20:40:45 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>


New submission from Michael Grazebrook <michael at grazebrook.com>:

This code fragment from the documentation of iter() doesn't work as intended. Change "STOP" to "STOP\n". Maybe also check for EOF as it hangs.

with open("mydata.txt") as fp:
    for line in iter(fp.readline, "STOP"):
        process_line(line)

Or maybe this makes a better example because it's clearer wha'ts going on:

square_generator = (i * i for i in range(100000))
for n in iter( square_generator.next, 144):
    print n

----------
assignee: docs at python
components: Documentation
messages: 128238
nosy: docs at python, mgrazebrook
priority: normal
severity: normal
status: open
title: iter() documentation code doesn't work
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Feb  9 21:50:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Feb 2011 20:50:09 +0000
Subject: [issue4696] email module does not unfold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1297284609.28.0.0531121894618.issue4696@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, when I said "new version", I meant "new major version", as in email6.  I have plans for this, but I'm waiting until after the release of 3.2 to make a presentation about it to the email-sig.

----------
versions: +Python 3.3 -Python 3.2

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

From report at bugs.python.org  Wed Feb  9 21:52:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 09 Feb 2011 20:52:25 +0000
Subject: [issue11144] int(float) may return a long for no reason
In-Reply-To: <1297100755.38.0.104149239471.issue11144@psf.upfronthosting.co.za>
Message-ID: <1297284745.0.0.323355168491.issue11144@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Very smart!

----------

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

From report at bugs.python.org  Wed Feb  9 22:08:21 2011
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 09 Feb 2011 21:08:21 +0000
Subject: [issue11161] futures.ProcessPoolExecutor hangs
In-Reply-To: <1297274599.08.0.127340661733.issue11161@psf.upfronthosting.co.za>
Message-ID: <1297285701.26.0.383399378025.issue11161@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

ProcessPoolExecutor is not expected to work with any interactive shell on Windows because it uses the multiprocessing module behind the scenes, which has that limitation.

I'm reclassifying this as a documentation bug since either a reference to http://docs.python.org/dev/library/multiprocessing.html#programming-guidelines should appear in the futures docs or (better) the content should be rewritten specifically for ProcessPoolExecutor.

----------
components: +Documentation -IDLE

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

From report at bugs.python.org  Wed Feb  9 23:10:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 09 Feb 2011 22:10:28 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>


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

Lib/xml/__init__.py since r16544 tries to replace xml package with _xmlplus package from PyXML. PyXML is no longer maintained and doesn't support Python 3, so it should be safe to remove PyXML-related code in Lib/xml/__init__.py in Python 3.1 / 3.2.

----------
components: Library (Lib), XML
messages: 128242
nosy: Arfrever, akuchling, fdrake, jkloth, loewis
priority: normal
severity: normal
status: open
title: xml shouldn't use _xmlplus
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb  9 23:15:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 09 Feb 2011 22:15:24 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1297289724.15.0.401276335274.issue10517@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
title: test_concurrent_futures crashes with "Fatal Python error: Invalid thread state for this thread" -> test_concurrent_futures crashes with "--with-pydebug" on RHEL5 with "Fatal Python error: Invalid thread state for this thread"

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

From report at bugs.python.org  Wed Feb  9 23:21:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:21:43 +0000
Subject: [issue8652] Minor improvements to the "Handling Exceptions" part of
	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1297290103.75.0.0503800363153.issue8652@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Removes the two instances I noticed of treating exception instances as sequences.
Looks good.

> Adds a warning explaining ``except FooException, BarException:`` does not do what you might think.
Ditto.

> There are two things I'm not entirely happy about:

> I initially wrote ``print "I/O error({0.errno}): {0.strerror}".format(e)``,
> but then noticed this string formatting trick is not mentioned in the previous chapter
> of the tutorial. Dict access (``"{0[foo]}".format(d)``) is, but attribute access
> is not. Is this worth adding to that chapter, so it can be used here?
It?s not at all a trick :)  Given that item access is already covered, I don?t think your use of attribute access would make the example harder for beginners, but I may not be the best judge.

> Binding an exception instance to a variable (using "as") is explained near the bottom
> of the section on catching exceptions, well before it is used.
> Perhaps this could do with a bit of reordering?
+1.

A note about workflow: patches should usually apply to the py3k branch, the person who commits takes care of backporting to 3.1 and 2.7.  In this case, some of your editions are not relevant for 3.x, so I suggest you use one of those workflows:
1) Make one patch for py3k and one for 2.7
2) Make one for 2.7, with comments indicating parts that apply to py3k too
3) Make one patch with edits relevant for py3k and 2.7, and another one for 2.7-only edits

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  9 23:33:33 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 22:33:33 +0000
Subject: [issue2228] Imaplib speedup patch
In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
Message-ID: <1297290813.79.0.971191312128.issue2228@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sean, could you please explain a bit more what are your concerns about this patch?

Anyhow, the code has slightly changed and currently John is not maintaining offlineimap anymore, but what seems the most recent version can be found at: https://github.com/nicolas33/offlineimap/

----------
nosy: +sandro.tosi
stage:  -> patch review

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

From report at bugs.python.org  Wed Feb  9 23:37:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:37:17 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <90e6ba4fbf2e4c1fe5049be11b48@google.com>


?ric Araujo <merwok at netwok.org> added the comment:

self.distribution.username:
>>>> I?d prefer a clearer comparison, please use ?is [not] None? and
parens.
>>> Are you sure you want an empty username in config file to override
name set from
>>> 'register' command?
>> This is a crazy case.  PyPI won?t allow it to pass, so I?m okay with
it.
> That's why I don't want to make distinction between "None" username
and empty
> username. They are both the same in this context.

That?s not what I meant.  IMO, None means not provided and an empty
string (i.e. an empty value in the config file) is a bug introduced by
the user.

not
>> ?password?.
> That's magically patched in setUp method.

I don?t understand.  The RawInput monkey-patch will give '1', 'tarek'
and 'n', which are anwsers to ?choice?, ?username? and ?save password?,
but the code should ask for ?choice?, ?username?, ?password?, ?save
password?.

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

http://codereview.appspot.com/2874041/diff/13001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
A bugfix should not change the API like this.  Either make it a private
name like _username, or (better) use
dist.get_command_obj('register').username

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

----------

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

From report at bugs.python.org  Wed Feb  9 23:37:25 2011
From: report at bugs.python.org (Ole Martin Handeland)
Date: Wed, 09 Feb 2011 22:37:25 +0000
Subject: [issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum
	recursion depth exceeded in cmp
In-Reply-To: <1274665334.09.0.561782804312.issue8797@psf.upfronthosting.co.za>
Message-ID: <1297291045.63.0.450262032555.issue8797@psf.upfronthosting.co.za>


Ole Martin Handeland <pythonbugs at olemartin.org> added the comment:

Thanks Sam! I can confirm that your patch is working well with basic auth. I have not tried other authentication methods, though. I'm not sure about the unredirected headers, but your fix looks like the cleanest.

----------
nosy: +olemartinorg

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

From report at bugs.python.org  Wed Feb  9 23:42:27 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 22:42:27 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1297291347.81.0.259308600372.issue6626@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Wed Feb  9 23:46:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:46:49 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <1297291609.13.0.657099456919.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -eric.araujo, tarek, techtonik

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

From report at bugs.python.org  Wed Feb  9 23:46:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:46:54 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297291614.62.0.274593136805.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120776

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

From report at bugs.python.org  Wed Feb  9 23:46:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:46:57 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297291617.77.0.325478438132.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120788

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

From report at bugs.python.org  Wed Feb  9 23:47:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:47:00 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297291620.55.0.357765490074.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120791

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

From report at bugs.python.org  Wed Feb  9 23:47:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:47:03 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297291623.09.0.945318993497.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120847

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

From report at bugs.python.org  Wed Feb  9 23:47:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:47:12 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297291632.05.0.342273218293.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg128245

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

From report at bugs.python.org  Wed Feb  9 23:49:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:49:22 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1297291762.74.0.925219638991.issue9995@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the editions.  Further comments on rietveld.

Miscellaneous things:

1) Storing passwords in an hashed form is false security.  An attacker that can read a config file with plain text passwords can also just run commands that use hashed passwords from the config file, so the security focus should be in forbidding access to your files, not worrying about passwords in plain text.

2) http://wiki.python.org/moin/Distutils/FixingBugs has the guidelines you?re asking for.

3) I do not need a CVE to evaluate if an issue is a security risk, because http://www.python.org/dev/workflow/ tells me that it?s when ?somehow someone is able to gain escalated privileges when they shouldn't be able to.?

4) Could you remove report at bugs.python.org from the issue Cc?  It goes to the wrong bug report.


Comment from Tarek (which does not address my specific question about None vs. empty string):

Looks good to me:

the upload command will get the credentials from the session instead of using the existing config at all.

I remember that we changed the behavior to you'd had to set ONLY the user in the rc file, but allowing to pass the user is better since it make the config file optional

----------
stage:  -> patch review
versions: +Python 3.3

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

From report at bugs.python.org  Wed Feb  9 23:56:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Feb 2011 22:56:11 +0000
Subject: [issue11165] Document PyEval_Call* functions
In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>
Message-ID: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>


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

There are currently undocumented PyEval_Call* equivalents to a number of the PyObject_Call* functions.

Since there are resources out there on the web that direct people to use the currently undocumented PyEval functions, it would be good to document those properly, and recommend people typically use the PyObject_Call* variants instead (as the latter include all the stack and interpreter state integrity protection code, while the PyEval variants assume that has all already been handled).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 128248
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PyEval_Call* functions
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Feb  9 23:57:51 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Feb 2011 22:57:51 +0000
Subject: [issue11165] Document PyEval_Call* functions
In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>
Message-ID: <1297292271.88.0.28701233186.issue11165@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Removed the easy tag, since this may involve some python-dev discussion as to where to put them in C API docs (they don't really fit in any of the current sections).

Perhaps an "advanced APIs" section, for things that most C extensions or embedding applications really shouldn't be using.

----------

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

From report at bugs.python.org  Wed Feb  9 23:58:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 09 Feb 2011 22:58:47 +0000
Subject: [issue8853] getaddrinfo should accept port of type long
In-Reply-To: <1275155293.8.0.373298822378.issue8853@psf.upfronthosting.co.za>
Message-ID: <1297292327.8.0.0356796531829.issue8853@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Mark, would you like to write some tests about the proposed change? Antoine gave a fast look at the issue and believe it's acceptable for 2.7.

----------
nosy: +sandro.tosi
stage:  -> test needed
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Wed Feb  9 23:59:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 22:59:38 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>
Message-ID: <1297292378.23.0.815147507341.issue10361@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120860

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

From report at bugs.python.org  Thu Feb 10 00:06:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Feb 2011 23:06:09 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1297292769.67.0.0511491381947.issue11163@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Feb 10 00:18:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Feb 2011 23:18:10 +0000
Subject: [issue6626] show Python mimetypes module some love
In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za>
Message-ID: <1297293490.38.0.724885250194.issue6626@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for working on cleaning up that module.  I have to agree with Nick though (see also minor comments on Rietveld): code in the stdlib just can?t move as freely as outside of it.

I?m updating the version to 3.3, given that this patch adds new features and refactors things (stable branches only get bug fixes).

----------
versions: +Python 3.3 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Feb 10 00:18:38 2011
From: report at bugs.python.org (gdub)
Date: Wed, 09 Feb 2011 23:18:38 +0000
Subject: [issue1208304] urllib2's urlopen() method causes a memory leak
Message-ID: <1297293518.39.0.647136987698.issue1208304@psf.upfronthosting.co.za>


Changes by gdub <gary.wilson at gmail.com>:


----------
nosy: +gdub

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

From report at bugs.python.org  Thu Feb 10 01:26:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Feb 2011 00:26:03 +0000
Subject: [issue4676] python3 closes + home keys
In-Reply-To: <1229456623.89.0.997761344417.issue4676@psf.upfronthosting.co.za>
Message-ID: <1297297563.58.0.962978932853.issue4676@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can this bug be closed?

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Thu Feb 10 02:15:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Feb 2011 01:15:44 +0000
Subject: [issue11038] Some commands should stop if Name and Version are missing
In-Reply-To: <1296211155.96.0.0798615868084.issue11038@psf.upfronthosting.co.za>
Message-ID: <1297300544.12.0.220307223111.issue11038@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

gawel confirmed on IRC that this was an oversight.  On second thought, I decided to remove the constant, which I deemed unneeded: it doesn?t save time for programmers (there is code checking various subsets of the fields everywhere, just one constant does not reduce code significantly), and I don?t think it saves computer time either (local literals vs. global lookup?unprofiled though).  Alexis pulled my change (7e1118583e5f).

----------

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

From report at bugs.python.org  Thu Feb 10 02:29:36 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Thu, 10 Feb 2011 01:29:36 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297301376.33.0.998901696729.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

Solution:
In /usr/lib/python3.1/email/encoders.py, use encodebytes instead of b64encode:

--- encoders.py 2011-02-08 09:37:21.025030051 -0700
+++ encoders.py.yves    2011-02-08 09:38:04.945608365 -0700
@@ -12,7 +12,7 @@
     ]
 
 
-from base64 import b64encode as _bencode
+from base64 import encodebytes as _bencode
 from quopri import encodestring as _encode

----------

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

From report at bugs.python.org  Thu Feb 10 02:30:05 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Thu, 10 Feb 2011 01:30:05 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297301405.11.0.495679800542.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

#!/usr/bin/python3.1

import unittest
import email.mime.image


class emailEncoderTestCase(unittest.TestCase):
  def setUp(self):

    # point to an image
    binaryfile = '/usr/share/openclipart/png/animals/mammals/happy_monkey_benji_park_01.png'

    while len(binaryfile) == 0:
      print('Enter the name of an image: ')
      binaryfile = raw_input()

    fp = open('/usr/share/openclipart/png/animals/mammals/happy_monkey_benji_park_01.png', 'rb')
    self.bindata = fp.read()


  def test_convert(self):

    mimed = email.mime.image.MIMEImage(self.bindata, _subtype='png')

    base64ed = mimed.get_payload()
    # print (base64ed)

    # work out if any line within the string is > 76 chars
    chopped = base64ed.split('\n')
    lengths = [ len(x) for x in chopped ]
    toolong = [ x for x in lengths if x > 76 ]

    msg = 'There is at least one line of ' + str(max(lengths)) + ' chars.'
    self.assertEqual(0, len(toolong), msg)



if __name__ == '__main__':
  unittest.main()

----------

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

From report at bugs.python.org  Thu Feb 10 02:36:33 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Thu, 10 Feb 2011 01:36:33 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297301793.13.0.883263389374.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

Here's a better version (sorry I don't know how to remove msg128255:

----------

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

From report at bugs.python.org  Thu Feb 10 02:37:01 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Thu, 10 Feb 2011 01:37:01 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297301821.42.0.483400048749.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

#!/usr/bin/python3.1

import unittest
import email.mime.image


class emailEncoderTestCase(unittest.TestCase):
  def setUp(self):

    # point to an image
    binaryfile = ''
    #binaryfile = '/usr/share/openclipart/png/animals/mammals/happy_monkey_benji_park_01.png'

    while len(binaryfile) == 0:
      print('Enter the name of an image: ')
      binaryfile = input()

    fp = open(binaryfile, 'rb')
    self.bindata = fp.read()


  def test_convert(self):

    mimed = email.mime.image.MIMEImage(self.bindata, _subtype='png')

    base64ed = mimed.get_payload()
    # print (base64ed)

    # work out if any line within the string is > 76 chars
    chopped = base64ed.split('\n')
    lengths = [ len(x) for x in chopped ]
    toolong = [ x for x in lengths if x > 76 ]

    msg = 'There is at least one line of ' + str(max(lengths)) + ' chars.'
    self.assertEqual(0, len(toolong), msg)



if __name__ == '__main__':
  unittest.main()

----------

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

From report at bugs.python.org  Thu Feb 10 03:06:17 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 02:06:17 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	TestSkipped
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297303577.56.0.43752819414.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is a patch which has added the necessary changes to test.support.import_module() and placed the necessary changes in the test suites themselves. I still need to rip out the (un)expected test stuff from regrtest before I consider the patch complete.

----------
assignee:  -> brett.cannon
keywords: +patch
Added file: http://bugs.python.org/file20725/issue10966.diff

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

From report at bugs.python.org  Thu Feb 10 03:06:37 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 10 Feb 2011 02:06:37 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297303597.02.0.594537507509.issue4681@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

will this patch support off_t for "mmap.resize" as well? ftruncate uses off_t for the length of a file as well.

----------
nosy: +wrobell

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

From report at bugs.python.org  Thu Feb 10 03:37:38 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 02:37:38 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297305458.16.0.670825210166.issue10966@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
title: eliminate use of ImportError implicitly representing TestSkipped -> eliminate use of ImportError implicitly representing SkipTest

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

From report at bugs.python.org  Thu Feb 10 04:40:03 2011
From: report at bugs.python.org (Dan Mahn)
Date: Thu, 10 Feb 2011 03:40:03 +0000
Subject: [issue11166] No exit when daemon thread is running.
In-Reply-To: <1297309203.91.0.996465848565.issue11166@psf.upfronthosting.co.za>
Message-ID: <1297309203.91.0.996465848565.issue11166@psf.upfronthosting.co.za>


New submission from Dan Mahn <dan.mahn at digidescorp.com>:

I have a python-based test script that creates a daemon thread.  The foreground basically runs a loop of commands, while the daemon thread sends some UDP data on the network.  To stop the script, I use Control-C.  This is running under 64-bit Windows (Vista) with 64-bit Python.

This script was developed under Python version 3.0, and has been running fine with 3.1.  I downloaded 3.2RC1 and noticed that the script does not exit with the typical Ctrl-C.  I also tried 3.2RC2, which had the same effect.  If I do not start the background thread, the test exits normally.

If I use Python 3.1, but I don't set the daemon attribute on the background thread, the operation duplicates the problem.  Therefore, I believe there is a problem with 3.2 handling of daemon threads.

----------
components: None
messages: 128260
nosy: dmahn
priority: normal
severity: normal
status: open
title: No exit when daemon thread is running.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 05:38:01 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 10 Feb 2011 04:38:01 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297312681.72.0.903234650241.issue4681@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> will this patch support off_t for "mmap.resize" as well?
> ftruncate uses off_t for the length of a file as well.

No, it doesn't because resize() resizes the amount mmapped in memory which can't be more than ssize_t anyway. However, resizing does work on a 12GiB file with a large offset, e.g. 6GiB.

----------

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

From report at bugs.python.org  Thu Feb 10 06:03:02 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Thu, 10 Feb 2011 05:03:02 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297314182.51.0.261460526758.issue11158@psf.upfronthosting.co.za>


Pham Cong Dinh <pcdinh at gmail.com> added the comment:

I just simplified my script into a smaller one that can be easier to understand and find out what happens

https://gist.github.com/819979

Thanks

----------
resolution: invalid -> 
status: pending -> open

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

From report at bugs.python.org  Thu Feb 10 06:05:14 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Thu, 10 Feb 2011 05:05:14 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297314314.95.0.35110310327.issue11158@psf.upfronthosting.co.za>


Pham Cong Dinh <pcdinh at gmail.com> added the comment:

Sorry, just ignore my latest comment. It is for another issue

----------

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

From report at bugs.python.org  Thu Feb 10 06:05:34 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Thu, 10 Feb 2011 05:05:34 +0000
Subject: [issue11148] Crash and error message from Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297314334.02.0.124275634307.issue11148@psf.upfronthosting.co.za>


Pham Cong Dinh <pcdinh at gmail.com> added the comment:

I just simplified my script into a smaller one that can be easier to understand and find out what happens

https://gist.github.com/819979

Thanks

----------

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

From report at bugs.python.org  Thu Feb 10 06:10:56 2011
From: report at bugs.python.org (Pham Cong Dinh)
Date: Thu, 10 Feb 2011 05:10:56 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297314656.26.0.1920792279.issue11158@psf.upfronthosting.co.za>


Pham Cong Dinh <pcdinh at gmail.com> added the comment:

Hi Vinay,

Your example use a child process to receive log messages. I am implementing a thread-based solution. Do you think that multiprocessing.Queue() has major issues with threads or this problem happens only on Mac OSX implementations?

I still reproduce it quite easily on my system: Mac OS 10.6 and Python 2.6.6

----------

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

From report at bugs.python.org  Thu Feb 10 08:11:35 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 07:11:35 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297321895.93.0.333088340258.issue9334@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Maybe dont_assume_everything_that_looks_like_a_flag_is_intended_to_be_one should actually be a new class, e.g.

    parser = AllowFlagsAsPositionalArgumentsArgumentParser()

Then you just wouldn't provide parse_known_args on that parser.

----------

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

From report at bugs.python.org  Thu Feb 10 08:20:04 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 07:20:04 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1297322404.28.0.924833473186.issue9399@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Argparse's wrapping behavior is determined by the formatter_class:

http://docs.python.org/library/argparse.html#formatter-class

Is it reasonable to assume that if you're wrapping your own messages you're already specifying formatter_class=argparse.RawTextHelpFormatter? If so, then perhaps the message should be printed via something like:

    formatter = parser._get_formatter()
    formatter.add_text(self.message)
    file.write(formatter.format_help())

This is what we do in _VersionAction, so I guess it's probably what we should do here.

----------

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

From report at bugs.python.org  Thu Feb 10 09:37:34 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 10 Feb 2011 08:37:34 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297327054.39.0.996442890756.issue11158@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't believe that the problem is about threads vs. processes. In the following gist:

https://gist.github.com/820132

I modified the script so that the main process uses a listener thread, rather than a listener process, to collect the logs. (Basically, I changed multiprocessing.Process to threading.Thread, changed the name of the function to listener_thread from listener_process, added an import for threading and updated the comments. No other changes were made.)

The script in the above gist runs fine on Linux Mint Debian and Windows 7 (Python 2.6 in both cases). Please run it on Snow Leopard and report your findings.

----------
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Thu Feb 10 10:07:08 2011
From: report at bugs.python.org (Marcin Bachry)
Date: Thu, 10 Feb 2011 09:07:08 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297328828.04.0.292279930809.issue11158@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I think it may be related to this bug: http://bugs.python.org/issue6721

----------
nosy: +marcin.bachry
status: pending -> open

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

From report at bugs.python.org  Thu Feb 10 10:14:18 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Feb 2011 09:14:18 +0000
Subject: [issue11167] Overflow in unicode_hash
In-Reply-To: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>
Message-ID: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>


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

Due to an integer overflow in unicode_hash, the python interpreter
crashes if built with -ftrapv:

./configure --with-pydebug CFLAGS="-ftrapv"



Starting program: /home/stefan/svn/py3k/python 
[Thread debugging using libthread_db enabled]

Program received signal SIGABRT, Aborted.
0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff71ea5c0 in *__GI_abort () at abort.c:92
#2  0x00000000005e30a0 in __mulvdi3 ()
#3  0x000000000046304b in unicode_hash (self=0x7ffff7fab110) at Objects/unicodeobject.c:7600
#4  0x000000000041a313 in PyObject_Hash (v=0x7ffff7fab110) at Objects/object.c:762
#5  0x00000000005a9093 in PyDict_GetItem (op=0x8be030, key=0x7ffff7fab110) at Objects/dictobject.c:715
#6  0x000000000046d88c in PyUnicode_InternInPlace (p=0x7fffffffdf38) at Objects/unicodeobject.c:10026
#7  0x000000000046da8b in PyUnicode_InternFromString (cp=0x5e7c99 "__len__") at Objects/unicodeobject.c:10065
#8  0x0000000000445eba in init_slotdefs () at Objects/typeobject.c:5801
#9  0x000000000044633b in add_operators (type=0x846400) at Objects/typeobject.c:5955
#10 0x000000000043e950 in PyType_Ready (type=0x846400) at Objects/typeobject.c:3860
#11 0x000000000043e87e in PyType_Ready (type=0x846000) at Objects/typeobject.c:3824
#12 0x000000000041c786 in _Py_ReadyTypes () at Objects/object.c:1513
#13 0x00000000004c99a6 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:229
#14 0x00000000004c9d78 in Py_Initialize () at Python/pythonrun.c:321
#15 0x00000000004ead8c in Py_Main (argc=1, argv=0x7ffff7fa9040) at Modules/main.c:597
#16 0x00000000004187cf in main (argc=1, argv=0x7fffffffe3c8) at ./Modules/python.c:59



Breakpoint 1, unicode_hash (self=0x7ffff7fab110) at Objects/unicodeobject.c:7594
7594        if (self->hash != -1)
(gdb) n
7596        len = Py_SIZE(self);
(gdb) n
7597        p = self->str;
(gdb) n
7598        x = *p << 7;
(gdb) n
7599        while (--len >= 0)
(gdb) p x
$1 = 12160
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n
7599        while (--len >= 0)
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n
7599        while (--len >= 0)
(gdb) n
7600            x = (1000003*x) ^ *p++;
(gdb) n

Program received signal SIGABRT, Aborted.
0x00007ffff71e6a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) quit



This might be related to issue #10156 (unicode initialization is
not clearly defined).

----------
components: Interpreter Core
messages: 128270
nosy: georg.brandl, skrah
priority: critical
severity: normal
stage: needs patch
status: open
title: Overflow in unicode_hash
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 10:18:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 10 Feb 2011 09:18:52 +0000
Subject: [issue11167] Overflow in unicode_hash
In-Reply-To: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>
Message-ID: <1297329532.09.0.128418613816.issue11167@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Thu Feb 10 10:19:57 2011
From: report at bugs.python.org (Scott Tsai)
Date: Thu, 10 Feb 2011 09:19:57 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1297329597.79.0.10847806954.issue3871@psf.upfronthosting.co.za>


Changes by Scott Tsai <scottt.tw at gmail.com>:


----------
nosy: +scott.tsai
versions:  -3rd party, Python 3.3

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

From report at bugs.python.org  Thu Feb 10 10:21:14 2011
From: report at bugs.python.org (Scott Tsai)
Date: Thu, 10 Feb 2011 09:21:14 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1297329674.77.0.7360336573.issue3871@psf.upfronthosting.co.za>


Scott Tsai <scottt.tw at gmail.com> added the comment:

I touched the version field by mistake while trying to add myself to the nosy list. My sincere apologies for the SPAM to all involved.

----------
versions: +3rd party, Python 3.3

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

From report at bugs.python.org  Thu Feb 10 10:28:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Feb 2011 09:28:36 +0000
Subject: [issue11167] Overflow in unicode_hash
In-Reply-To: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>
Message-ID: <1297330116.17.0.629030101535.issue11167@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ok, this is known, see #1621. Closing.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Do not assume signed integer overflow behavior

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

From report at bugs.python.org  Thu Feb 10 10:29:33 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Feb 2011 09:29:33 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1297330173.58.0.803132505004.issue1621@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

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

From report at bugs.python.org  Thu Feb 10 10:40:31 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Feb 2011 09:40:31 +0000
Subject: [issue11167] Overflow in unicode_hash
In-Reply-To: <1297329257.96.0.465524186944.issue11167@psf.upfronthosting.co.za>
Message-ID: <1297330831.08.0.0747559116298.issue11167@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Could you try the same in Python 2.7 ?

The overflow is intended (after all, it's a hash function), but we should probably add a cast to Py_hash_t to the hash building line in order to make the compiler aware of this.

----------
nosy: +lemburg

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

From report at bugs.python.org  Thu Feb 10 10:43:32 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 10 Feb 2011 09:43:32 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297331012.21.0.825033495967.issue4681@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

> > will this patch support off_t for "mmap.resize" as well?
> > ftruncate uses off_t for the length of a file as well.

> No, it doesn't because resize() resizes the amount mmapped in memory
> which can't be more than ssize_t anyway. However, resizing does work on
> a 12GiB file with a large offset, e.g. 6GiB.

i am bit lost. ftruncate is used to enlarge the file, isn't it?

please consider the script:

-- rr.py ---
import mmap

f = open('test.x', 'w+b')
f.write(b'\x00' * 10)
f.flush()

fm = mmap.mmap(f.fileno(), 0)
fm.resize(5 * 1024 ** 3)
fm.close()

f.close()
------------

the script above resizes file from 10 bytes
to 5 * 1024 ** 3 bytes with mmap.resize (but
not 5 * 1024 ** 3 + 10!)

now, on 32-bit linux (with off_t):

$ python3 rr.py
Traceback (most recent call last):
  File "rr.py", line 8, in <module>
    fm.resize(5 * 1024 ** 3)
OverflowError: Python int too large to convert to C ssize_t

above script works perfectly on 64-bit version of linux
with just 4GB of RAM.

maybe i do not understand some magic here, but clearly one
can mmap.resize to a file size much beyond the amount of memory.

----------

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

From report at bugs.python.org  Thu Feb 10 10:51:27 2011
From: report at bugs.python.org (Scott Tsai)
Date: Thu, 10 Feb 2011 09:51:27 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1297331487.22.0.110274686005.issue4709@psf.upfronthosting.co.za>


Changes by Scott Tsai <scottt.tw at gmail.com>:


----------
nosy: +scott.tsai

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

From report at bugs.python.org  Thu Feb 10 11:15:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 10:15:21 +0000
Subject: [issue10656] "Out of tree" build fails on AIX 5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1297332921.34.0.269054788195.issue10656@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

There are some unit tests concerning distutils which are currently failing on AIX and may be an illustration of the same problem:

======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/ccompiler.py", line 911, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command './Modules/ld_so_aix' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/tests/test_build_ext.py", line 85, in test_build_ext
    cmd.run()
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command './Modules/ld_so_aix' failed with exit status 1

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/ccompiler.py", line 911, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command './Modules/ld_so_aix' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/tests/test_build_ext.py", line 343, in test_get_outputs
    cmd.run()
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command './Modules/ld_so_aix' failed with exit status 1

I will take a look.

----------

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

From report at bugs.python.org  Thu Feb 10 11:24:39 2011
From: report at bugs.python.org (rep)
Date: Thu, 10 Feb 2011 10:24:39 +0000
Subject: [issue10694] zipfile.py end of central directory detection not robust
In-Reply-To: <1292266671.15.0.914079935044.issue10694@psf.upfronthosting.co.za>
Message-ID: <1297333479.32.0.512937203205.issue10694@psf.upfronthosting.co.za>


rep <ms at mwcollect.org> added the comment:

Xuanji: Patch looks good now with the test cases.

Regarding the other fix suggested by Kevin I think that we should not introduce custom behaviour here like appending the eofdata to the comment even though the comment size in the record does not say so. In the end we want to make sure that correct zip files end up being processed correctly with the specified comment size and incorrect zip files with eofdata should not be rejected / throw exceptions.

So I agree with Xuanji that his patch (or mine) is the way to go.

You probably agree that we can mark issue 10298 to be superseded by this one here.

----------

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

From report at bugs.python.org  Thu Feb 10 11:26:28 2011
From: report at bugs.python.org (rep)
Date: Thu, 10 Feb 2011 10:26:28 +0000
Subject: [issue10298] zipfile: incorrect comment size will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1297333588.53.0.102719962892.issue10298@psf.upfronthosting.co.za>


Changes by rep <ms at mwcollect.org>:


----------
status: open -> languishing

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

From report at bugs.python.org  Thu Feb 10 11:26:34 2011
From: report at bugs.python.org (rep)
Date: Thu, 10 Feb 2011 10:26:34 +0000
Subject: [issue10298] zipfile: incorrect comment size will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1297333594.05.0.810716373408.issue10298@psf.upfronthosting.co.za>


Changes by rep <ms at mwcollect.org>:


----------
status: languishing -> pending

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

From report at bugs.python.org  Thu Feb 10 11:27:06 2011
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 10 Feb 2011 10:27:06 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297333626.36.0.473320329177.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks eric for reviewing my patch! And thanks for you suggestions. I'm  following them.

> I don?t know if you should use a plain set or a collections.ItemsView here.  In dict objects, KeysView and ValuesView are set-like objects with added behavior, for example they yield their elements in the same order.

Yes you are right. I think returning a view object is better than returning a set.

Here is the updated patch. It updates:
1. Make keys(), values(), items() methods return view object for ndbm, gdbm and dumb objects. I following the codes in dictobject.c. The keysview object support len(), "in" operator, and iteratable, while valuesview and itemsview object only support len() and iteratable.
2. Removing doc changes: 
  The object returned by :func:`.open` supports the same basic functionality as
  -dictionaries
  +:mod:`collection`.MutableMapping
    which is mentioned in eric's comment.
3. Remove dumb's keys() method which calls self._index.keys() since it is unnecessary.
4. Using more specialized assertXxx methods in test cases.
5. Remove "the values() and items() method are not supported" in Doc/library/dbm.rst.


> See #5736 for a patch adding iteration support.  If the patch attached to his report supersedes the other one, I?ll close the other bug as duplicate.

#5736 's patch for adding iteration to ndbm and gdbm modules simple calling PyObject_GetIter(dbm_keys(dbm, NULL)) for both gdbm and ndbm, but I feel it's better to create a seperate iterator object for gdbm objects.

----------
Added file: http://bugs.python.org/file20726/issue_9523.diff

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

From report at bugs.python.org  Thu Feb 10 11:27:15 2011
From: report at bugs.python.org (rep)
Date: Thu, 10 Feb 2011 10:27:15 +0000
Subject: [issue10298] zipfile: incorrect comment size will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1297333635.15.0.792379732814.issue10298@psf.upfronthosting.co.za>


rep <ms at mwcollect.org> added the comment:

superseded by issue 10694

----------
resolution:  -> accepted
status: pending -> closed

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

From report at bugs.python.org  Thu Feb 10 11:54:14 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 10:54:14 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297335254.26.0.215653949732.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes I will do that.
I am currently reinstalling some buildbot environments for Python on AIX 5.3 and AIX 6.1 and once that is done, I will rewrite the note.

----------

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

From report at bugs.python.org  Thu Feb 10 12:03:48 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 10 Feb 2011 11:03:48 +0000
Subject: [issue11148] Crash and error message from Python VM
In-Reply-To: <1297160369.82.0.352972553571.issue11148@psf.upfronthosting.co.za>
Message-ID: <1297335828.15.0.939415875618.issue11148@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I think this issue is related to http://bugs.python.org/issue11158, which is in turn related to http://bugs.python.org/issue6721 (Locks in python standard library should be sanitized on fork).

When  a mutex created by a parent process is used from within a child process, this can lead not only to a deadlock, but also to SIGSEGV.

To understand the purpose of pthread_atfork, recall that fork duplicates the whole memory space, including mutexes in their current locking state, but only the calling thread: other threads are not running in the child process. The mutexes are not usable after the fork and must be initialized with pthread_mutex_init in the child process. This is a limitation of the current implementation and might or might not be present in future versions.

They must be initialized.

Suggesting to close both #11148 and #11158 as dupe of #6721.

----------
nosy: +neologix

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

From report at bugs.python.org  Thu Feb 10 12:03:55 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 10 Feb 2011 11:03:55 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1297335835.46.0.671450084137.issue7511@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

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

From report at bugs.python.org  Thu Feb 10 12:11:58 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 11:11:58 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297336318.74.0.254604065663.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hi Micheal,

I don't remember why "-L\$(srcdir)" was added since it has been quite a long time.

I tried to recompile everything after removing it and everything compiled just fine, so I guess it can be removed.

regards

----------

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

From report at bugs.python.org  Thu Feb 10 12:12:41 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Thu, 10 Feb 2011 11:12:41 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1297336361.0.0.0693036181768.issue6721@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I'm not sure that releasing the mutex is enough, it can still lead to a segfault, as is probably the case in this issue :
http://bugs.python.org/issue11148

Quoting pthread_atfork man page :

To understand the purpose of pthread_atfork, recall that fork duplicates the whole memory space, including mutexes in their current locking state, but only the calling thread: other threads are not running in the child process. The mutexes are not usable after the fork and must be initialized with pthread_mutex_init in the child process. This is a limitation of the current implementation and might or might not be present in future versions.

To avoid this, install handlers with pthread_atfork as follows: have the prepare handler lock the mutexes (in locking order), and the parent handler unlock the mutexes. The child handler should reset the mutexes using pthread_mutex_init, as well as any other synchronization objects such as condition variables.

Locking the global mutexes before the fork ensures that all other threads are locked out of the critical regions of code protected by those mutexes. Thus when fork takes a snapshot of the parent's address space, that snapshot will copy valid, stable data. Resetting the synchronization objects in the child process will ensure they are properly cleansed of any artifacts from the threading subsystem of the parent process. For example, a mutex may inherit a wait queue of threads waiting for the lock; this wait queue makes no sense in the child process. Initializing the mutex takes care of this.

pthread_atfork might be worth looking into

----------
nosy: +neologix

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

From report at bugs.python.org  Thu Feb 10 12:17:39 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 11:17:39 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1297336659.95.0.282305829779.issue730467@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a patch that combines the corrections in configure.in and dynload_aix.c.

All recent versions of AIX would benefit from this correction I think (recent meaning a version of AIX released in the last 10 years or something).

Could someone apply it?
Thanks in advance

----------
keywords: +patch
Added file: http://bugs.python.org/file20727/patch_aix_cxx.diff

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

From report at bugs.python.org  Thu Feb 10 13:14:41 2011
From: report at bugs.python.org (Aaron Kaplan)
Date: Thu, 10 Feb 2011 12:14:41 +0000
Subject: [issue2228] Imaplib speedup patch
In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
Message-ID: <1297340081.26.0.445244862206.issue2228@psf.upfronthosting.co.za>


Aaron Kaplan <x348vqzl at aaronkaplan.info> added the comment:

Let me clarify. Offlineimap used to ship a modified version of imaplib in its distribution, but eventually the author decided he no longer wanted to maintain his imaplib fork, so he dropped it and went with stock imaplib (at a significant performance penalty). The patch I submitted here is the difference between the forked imaplib circa 2007 and the upstream version it was forked from.  The current version of offlineimap is not relevant to this issue, because it no longer contains any imaplib code.

----------

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

From report at bugs.python.org  Thu Feb 10 13:21:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 12:21:42 +0000
Subject: [issue11168] UnicodeEncodeError on recusion limit if the script
	filename is undecodable
In-Reply-To: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>
Message-ID: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>


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

If the script filename is not decodable from the filesystem encoding, Python fails with a UnicodeEncodeError when we reach the recursion limit. The problem doesn't come from the user script, but from Python internals. It is difficult to understand and the user expects a 


A longer explanation:

test_runpy fails with a pydebug build if the script filename is not encodable to UTF-8. In pydebug build only, PyEval_EvalFrameEx() encodes the frame filename to UTF-8. If the filename contains a surrogate character (which only occurs on UNIX with undecodable filename),the encoding function fails. PyEval_EvalFrameEx() ignores the error except if we hit the recusion limit (if the overflowed attribute of the thread state if set): in this case, the error is not ignored.

To reproduce the problem, change the Python directory (your local repository) to an undecodable filename (eg. b'py3k\xe9\xff' with UTF-8 locale encoding) and run: ./python Lib/test/regrtest.py test_py.


Solutions :

I propose to remove the filename variable from PyEval_EvalFrameEx() because it is only used by the old gdb macros: python-gdb.py doesn't need it anymore.

=> see attached patch

Or if you really want to keep it, tstate->overflowed should be reinitialized. But on overflow, other variables are changed, like _Py_CheckRecursionLimit. I don't know this code enough to write a correct patch, but the minimal patch is:

--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -1234,7 +1234,7 @@ PyEval_EvalFrameEx(PyFrameObject *f, int throwflag)
         filename = _PyUnicode_AsString(co->co_filename);
         if (filename == NULL && tstate->overflowed) {
             /* maximum recursion depth exceeded */
-            goto exit_eval_frame;
+            tstate->overflowed = 0;
         }
         PyErr_Restore(error_type, error_value, error_traceback);
     }

----------
components: Unicode
files: ceval_filename.patch
keywords: patch
messages: 128285
nosy: haypo
priority: normal
severity: normal
status: open
title: UnicodeEncodeError on recusion limit if the script filename is undecodable
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20728/ceval_filename.patch

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

From report at bugs.python.org  Thu Feb 10 13:34:58 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 10 Feb 2011 12:34:58 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1297341298.86.0.347842024503.issue11158@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Issue 6721 may well be valid - if this is a symptom of the same issue, then this issue should be closed. I'd like to know if the gist script I referred to works (or not) on Pham Cong Dinh's Snow Leopard machine.

----------
status: open -> pending

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

From report at bugs.python.org  Thu Feb 10 13:37:55 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 12:37:55 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1297341475.78.0.665522482245.issue9920@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Mark,

sorry for the late reply; I stopped focusing on AIX for some time.

I ran test_cmath on trunk this morning and got a different error this time:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 382, in test_specific_values
    msg=error_message)
  File "/san_cis/home/cis/.buildbot/python-aix6/py3k-aix6-xlc/build/Lib/test/test_cmath.py", line 128, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------
Ran 16 tests in 0.086s

FAILED (failures=1, skipped=2)

----------

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

From report at bugs.python.org  Thu Feb 10 13:38:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 12:38:46 +0000
Subject: [issue11169] compileall doesn't support the PEP 383 (undecodable
	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>


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

The compileall uses print("bla", filename, "bla") to write messages to the console. But the print fails if the filename cannot be encoded to the console encoding. It occurs if the filename is an undecodable filename encoded by the PEP 383 using surrogates. For example, UTF-8 cannot encode surrogates.

Attached patch uses repr() to escape surrogates: it adds also quotes to the filename. I don't know if it is a problem to add quotes. I prefer quotes, but it is more readable if the path or the filename contain spaces.

----------
components: Unicode
files: compileall_surrogates.patch
keywords: patch
messages: 128288
nosy: haypo
priority: normal
severity: normal
status: open
title: compileall doesn't support the PEP 383 (undecodable paths/filenames)
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20729/compileall_surrogates.patch

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

From report at bugs.python.org  Thu Feb 10 13:58:22 2011
From: report at bugs.python.org (didzis)
Date: Thu, 10 Feb 2011 12:58:22 +0000
Subject: [issue11170] (MacOS X) Crash on non-english language keyboard input
	in Text widget
In-Reply-To: <1297342702.16.0.660188082743.issue11170@psf.upfronthosting.co.za>
Message-ID: <1297342702.16.0.660188082743.issue11170@psf.upfronthosting.co.za>


New submission from didzis <g_didzis at inbox.lv>:

In simple text edit trying to input non-english characters with keyboard ends with a crash on MacOS X (10.6).

For example, to input Latvian language characters, apostrophe should be pressed followed by some letter (a, e, i, u, k, l, ...)

Tkinter crashes immediately after apostrophe was pressed on keyboard.

Terminal output:

2011-02-10 14:52:29.444 Python[10633:613] An uncaught exception was raised
2011-02-10 14:52:29.448 Python[10633:613] *** -[NSCFString characterAtIndex:]: Range or index out of bounds
2011-02-10 14:52:29.450 Python[10633:613] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSCFString characterAtIndex:]: Range or index out of bounds'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff88d407b4 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff86f480f3 objc_exception_throw + 45
	2   CoreFoundation                      0x00007fff88d405d7 +[NSException raise:format:arguments:] + 103
	3   CoreFoundation                      0x00007fff88d40564 +[NSException raise:format:] + 148
	4   Foundation                          0x00007fff8384e5e1 -[NSCFString characterAtIndex:] + 97
	5   Tk                                  0x00000001010b5bcf Tk_SetCaretPos + 663
	6   Tk                                  0x00000001010bbd94 Tk_MacOSXSetupTkNotifier + 699
	7   Tcl                                 0x00000001007542ae Tcl_DoOneEvent + 297
	8   _tkinter.so                         0x00000001006d262d Tkapp_MainLoop + 413
	9   Python                              0x00000001000c124d PyEval_EvalFrameEx + 22397
	10  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	11  Python                              0x00000001000c0d8a PyEval_EvalFrameEx + 21178
	12  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	13  Python                              0x000000010003dd80 function_call + 176
	14  Python                              0x000000010000c9f2 PyObject_Call + 98
	15  Python                              0x000000010001eebb instancemethod_call + 363
	16  Python                              0x000000010000c9f2 PyObject_Call + 98
	17  Python                              0x00000001000ba817 PyEval_CallObjectWithKeywords + 87
	18  Python                              0x000000010002214e PyInstance_New + 126
	19  Python                              0x000000010000c9f2 PyObject_Call + 98
	20  Python                              0x00000001000be813 PyEval_EvalFrameEx + 11587
	21  Python                              0x00000001000c2f49 PyEval_EvalCodeEx + 2137
	22  Python                              0x00000001000c3066 PyEval_EvalCode + 54
	23  Python                              0x00000001000e7b2e PyRun_FileExFlags + 174
	24  Python                              0x00000001000e7de9 PyRun_SimpleFileExFlags + 489
	25  Python                              0x00000001000fe75c Py_Main + 2940
	26  Python                              0x0000000100000f14 0x0 + 4294971156
)
terminate called after throwing an instance of 'NSException'
Abort trap

----------
components: Tkinter
messages: 128289
nosy: didzis
priority: normal
severity: normal
status: open
title: (MacOS X) Crash on non-english language keyboard input in Text widget
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 10 14:01:37 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Feb 2011 13:01:37 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1297342897.94.0.670229184351.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ha, yes.  I commented out the first four tests for zeros of atan in the cmath_testcases.txt file, but failed to notice that they're tested again, later on.  And the same goes for atanh.

I need to look at this, but I don't have write-access to the Python svn repo at the moment (my home machine is ill).  If someone else wants to go through and just comment out all the tests of zeros for atan and atanh in cmath_testcases.txt, please go ahead.  The zeros are tested independently within test_cmath (but skipped on systems like AIX where there are known problems with log1p).

----------
status: closed -> open

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

From report at bugs.python.org  Thu Feb 10 14:36:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Feb 2011 13:36:52 +0000
Subject: [issue11170] (MacOS X) Crash on non-english language keyboard input
	in Text widget
In-Reply-To: <1297342702.16.0.660188082743.issue11170@psf.upfronthosting.co.za>
Message-ID: <1297345012.33.0.842473887768.issue11170@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This looks like a duplicate of issue 10973.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> OS X 10.6 IDLE, tkinter: Cocoa Tk 8.5 crash when composite character typed in	text	field

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

From report at bugs.python.org  Thu Feb 10 14:40:19 2011
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 10 Feb 2011 13:40:19 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297345219.3.0.146724183046.issue7330@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file19131/issue_7330.diff

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

From report at bugs.python.org  Thu Feb 10 14:47:46 2011
From: report at bugs.python.org (=?utf-8?q?Berthold_H=C3=B6llmann?=)
Date: Thu, 10 Feb 2011 13:47:46 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>


New submission from Berthold H?llmann <hoel at users.sourceforge.net>:

I do get (with 2.7.1):

> python
Traceback (most recent call last):
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py", line 287, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/gltools/python/Python-2.7/lib/python2.7/config/Makefile (No such file or directory)

The Makefile is platform dependendent und is located at

/usr/local/gltools/python/Python-2.7/linux_x86_64/lib/python2.7/config/Makefile

This problem is fixed for me by a simple pach:

> diff -c /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py~
*** /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py     2011-02-10 14:33:34.000015000 +0100
--- /usr/local/gltools/python/Python-2.7/lib/python2.7/sysconfig.py~    2011-02-10 14:28:17.001245000 +0100
***************
*** 271,277 ****
  def _get_makefile_filename():
      if _PYTHON_BUILD:
          return os.path.join(_PROJECT_BASE, "Makefile")
!     return os.path.join(get_path('platstdlib'), "config", "Makefile")
  
  
  def _init_posix(vars):
--- 271,277 ----
  def _get_makefile_filename():
      if _PYTHON_BUILD:
          return os.path.join(_PROJECT_BASE, "Makefile")
!     return os.path.join(get_path('stdlib'), "config", "Makefile")
  
  
  def _init_posix(vars):

----------
components: Installation
messages: 128292
nosy: hoel
priority: normal
severity: normal
status: open
title: Python 2.7.1 does not start when "./configure" is used with  "--prefix" != "--exec-prefix"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb 10 15:03:01 2011
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 10 Feb 2011 14:03:01 +0000
Subject: [issue11172] Avoid '.' as runpath on AIX
In-Reply-To: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>
Message-ID: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner <michael.haubenwallner at salomon.at>:

Spotted in issue#941346 msg#128214, the "-L$(srcdir)" should be removed from BLDSHARED on AIX:

The problem is that '-L$(srcdir)' adds '$(srcdir)' to the runpath too (as there is no '-blibpath' argument), opening a security hole for libpythonX.Y.so as well as the modules.so.

As LDLIBRARY points to the immediate file 'libpython$(VERSION).so' instead of '-lpython$(VERSION)', I don't see the need for '-L$(srcdir)' at all.

----------
components: Build
files: python-2.7.1-aix-safe-runpath.patch
keywords: patch
messages: 128293
nosy: haubi
priority: normal
severity: normal
status: open
title: Avoid '.' as runpath on AIX
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20730/python-2.7.1-aix-safe-runpath.patch

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

From report at bugs.python.org  Thu Feb 10 16:19:16 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 10 Feb 2011 15:19:16 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

Mark Shannon on python-dev:

The following API functions were removed from 3.1.3:

PyAST_Compile
PyCObject_AsVoidPtr
PyCObject_FromVoidPtr
PyCObject_FromVoidPtrAndDesc
PyCObject_GetDesc
PyCObject_Import
PyCObject_SetVoidPtr
PyCode_CheckLineNumber
Py_CompileStringFlags
PyEval_CallObject
PyOS_ascii_atof
PyOS_ascii_formatd
PyOS_ascii_strtod
PyThread_exit_prog
PyThread__PyThread_exit_prog
PyThread__PyThread_exit_thread
PyUnicode_SetDefaultEncoding

And the following were added to 3.2,
of which only 2 are documented:

PyArg_ValidateKeywordArguments
PyAST_CompileEx
Py_CompileString
Py_CompileStringExFlags
PyErr_NewExceptionWithDoc    (documented)
PyErr_SyntaxLocationEx
PyErr_WarnFormat
PyFrame_GetLineNumber
PyImport_ExecCodeModuleWithPathnames
PyImport_GetMagicTag
PyLong_AsLongLongAndOverflow    (documented)
PyModule_GetFilenameObject
Py_SetPath
PyStructSequence_GetItem
PyStructSequence_NewType
PyStructSequence_SetItem
PySys_AddWarnOptionUnicode
PySys_AddXOption
PySys_FormatStderr
PySys_FormatStdout
PySys_GetXOptions
PyThread_acquire_lock_timed
PyType_FromSpec
PyUnicode_AsUnicodeCopy
PyUnicode_AsWideCharString
PyUnicode_EncodeFSDefault
PyUnicode_FSDecoder
Py_UNICODE_strcat
Py_UNICODE_strncmp
Py_UNICODE_strrchr
PyUnicode_TransformDecimalToASCII

For added confusion PySys_SetArgvEx is documented as
new in 3.2, but exists in 3.1.3

Note that this only include functions.
The API also includes a number of macros such as
Py_False and Py_RETURN_FALSE, types ,
and data like PyBool_Type.

----------
assignee: docs at python
components: Documentation
messages: 128294
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Undocumented public APIs in Python 3.2
versions: Python 3.2

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

From report at bugs.python.org  Thu Feb 10 16:23:41 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Feb 2011 15:23:41 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296837184.1.0.588454218465.issue11082@psf.upfronthosting.co.za>
Message-ID: <AANLkTinPjjO9WpoQmkrSfRbXheZLt5fGsuyXiy_5SLOb@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Feb 5, 2011 at 12:33 AM, Georg Brandl <report at bugs.python.org> wrote:
>
> Then let us do that.
>
> Senthil, what about urlencode of bytes values returning a str?
>

Sorry, the late response. I needed some time to look at this one and I
could only do it today.
We have been having str return value from urlencode, due to quote,
quote_plus methods which can take bytes/str but return str. (urlencode
is nothing but quote_plus which acts on two-element sequences like
name,value pairs.

The resultant str is certainly useful when we want to construct a URL
query string. But, when we want to do a POST via urlopen, we need
bytes data. So, I think best to advice through the documentation that,
urlencoded value must be converted to bytes if it is to be used for
POST'ing using urlopen.

(Well, I also think that urllencode could be modified to the effect
that if the key,value pairs are bytes, return the bytes output.
Technically, this would involve overriding some behavior of
quote/quote_plus and the return value will suitable only for POST data
and not for url query construction. I would rather choose to discuss
this before settling on the behavior and I remember that quote's
behavior did take a significant amount discussion).

So, for this issue. A patch would a prevent str data from being posted
with ValueError explaining the reason that bytes and required and a
documentation update in the urlencode method which would inform the
users that the output be converted to bytes before it is POSTed,

Shall we go ahead with this, Georg?  I shall post a patch immediately.

----------

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

From report at bugs.python.org  Thu Feb 10 16:34:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 10 Feb 2011 15:34:07 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297352047.01.0.149323536176.issue11173@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Thu Feb 10 16:37:33 2011
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 10 Feb 2011 15:37:33 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297352253.48.0.640484593798.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks haypo!

Here is the updated patch, it add the tests about width modifiers and precision modifiers of %S, %R, %A. Besides I don't know how to add tests of %s, since when calling through ctypes, I could not get correct result value as python object from PyUnicode_FromFormat() with '%s' in format string as argument.

----------
Added file: http://bugs.python.org/file20731/issue_7330.diff

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

From report at bugs.python.org  Thu Feb 10 16:40:10 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:40:10 +0000
Subject: [issue10523] argparse has problem parsing option files containing
	empty rows
In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>
Message-ID: <1297352410.57.0.407094402805.issue10523@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Crashing on an empty line is definitely a bug.

Each line being a single option is documented behavior:

http://docs.python.org/dev/library/argparse.html#fromfile-prefix-chars

----------
nosy: +bethard

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

From report at bugs.python.org  Thu Feb 10 16:42:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 15:42:47 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297352567.33.0.838202322016.issue11173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PyErr_WarnFormat

is already documented in Doc/c-api/exceptions.rst

> PyImport_ExecCodeModuleWithPathnames

is already documented in Doc/c-api/import.rst

> PyModule_GetFilenameObject

is already documented in Doc/c-api/module.rst

> PySys_AddWarnOptionUnicode, PySys_FormatStderr and PySys_FormatStdout

are already documented in Doc/c-api/sys.rst

> PyUnicode_AsUnicodeCopy, PyUnicode_AsWideCharString, PyUnicode_EncodeFSDefault and PyUnicode_FSDecoder

are already documented in Doc/c-api/unicode.rst

Mark Shannon should read the documentation more carefuly.

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Feb 10 16:44:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 15:44:54 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297352694.16.0.229937350305.issue11173@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Py_UNICODE_strcat, Py_UNICODE_strncmp, Py_UNICODE_strrchr

See issue #10435 (with a patch) for these functions.

----------

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

From report at bugs.python.org  Thu Feb 10 16:45:53 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:45:53 +0000
Subject: [issue11174] add argparse formatting option to display type names for
	metavar
In-Reply-To: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>
Message-ID: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

I generally like my command line arguments that take a
value to specify the type, e.g.,

   --runs int      how many runs to do

Naturally I can do this using the metavars argument in every
add_argument() call, but that can become tedious. So I suggest adding a
metavars argument to the ArgumentParser constructor; default
metavars=None (current behaviour); metavars=type (show type names). And
of course, allow metavars specified in add_argument() calls to override
on a case by case basis.

----------
components: Library (Lib)
messages: 128300
nosy: bethard
priority: low
severity: normal
stage: needs patch
status: open
title: add argparse formatting option to display type names for metavar
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 16:47:13 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:47:13 +0000
Subject: [issue11175] allow argparse FileType to accept encoding and errors
	arguments
In-Reply-To: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>
Message-ID: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

Allow FileType to accept encoding and errors arguments
and pass these as keyword arguments to codecs.open() instead of open().

----------
components: Library (Lib)
messages: 128301
nosy: bethard
priority: low
severity: normal
stage: needs patch
status: open
title: allow argparse FileType to accept encoding and errors arguments
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 16:48:57 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 15:48:57 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Suggestion from a personal email:

I personally am not keen on the foo/bar/baz examples. I
know that you're trying to be generic but IMO it would be much easier to
understand if you used meaningful names. Also, I think that the very
first example you give (which does use meaningful names:-) is too
clever. I'd suggest using something simpler: in fact I'd use exactly the
same example that optparse uses (--file && --quiet) since that is easy
to understand and relate to straight away, and maybe add a --line option
that takes a list of ints (ostensibly line numbers of lines to extract
from the file) if you want to show that argparse leaves optparse in the
dust. And you can always show how to get actual file objects later on.

----------
assignee: docs at python
components: Documentation
messages: 128302
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: give more meaningful argument names in argparse documentation
type: feature request
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 10 17:00:46 2011
From: report at bugs.python.org (Raymond Penners)
Date: Thu, 10 Feb 2011 16:00:46 +0000
Subject: [issue8098] PyImport_ImportModuleNoBlock() may solve problems but
	causes others.
In-Reply-To: <1268131645.26.0.730387379265.issue8098@psf.upfronthosting.co.za>
Message-ID: <1297353646.9.0.0557175994013.issue8098@psf.upfronthosting.co.za>


Changes by Raymond Penners <raymond.penners at gmail.com>:


----------
nosy: +pennersr

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

From report at bugs.python.org  Thu Feb 10 17:04:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 16:04:04 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297353844.54.0.647538403676.issue11173@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> PyThread_acquire_lock_timed

It's on purpose that I didn't document this one. I'm not sure the PyThread_ APIs should be used by third-party extensions; so I'd prefer to hear about potential users before starting documenting it (and being tied by compatibility issues).

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb 10 17:11:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Feb 2011 16:11:50 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297354310.19.0.0758890959706.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is a patch to resolve this issue. Let me know if it okay to commit.(Or feel free to commit too).

----------
stage:  -> patch review
Added file: http://bugs.python.org/file20732/issue11082.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:41:47 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 10 Feb 2011 16:41:47 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297356107.57.0.130274937134.issue4681@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

32-bit computers can address up to 4GiB of memory and 64-bit computers can address much more than this. mmap() allows a file to be mapped to a location in memory - the actual amount of memory that exists doesn't matter. This is the reason why a 5GiB file can be mmaped on 64-bit but not 32-bit.

Also, python uses the ssize_t type for sequences which allows about 2GiB to be mapped on a 32-bit platform. The mmap.resize() operation as well as changing the size of the underlying file size with ftruncate(), also changes the size of the map in memory. Thus in your sample script, this resizing would need to ftruncate the file to 5GiB and then map all of it into memory which is not possible on 32-bit.

I think the following might be a possible way of doing it:
import mmap

f = open('test.x', 'w+b')
f.write(b'\x00' * 10)
f.flush()

fm = mmap.mmap(f.fileno(), 0)
fm.close()
f.truncate(5 * 1024 ** 3)

# mmap only 1GiB of the 5GiB file
fm = mmap.mmap(f.fileno(), 1024**3)
fm.close()

f.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:53:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 16:53:14 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1297356794.64.0.552405674085.issue5833@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine: do you think it's worth the effort?

As mentioned above, the readline 6 compatibility code was checked in.
The ClassType expansion is 2.x-only, so probably can't go in since it's a feature request.
What remains is the filename expansion. However, the problem is that it seems to rely on removing '~$-/' from the word break characters, which is IMO wrong (at least '-', '/' and '~' are all Python operators which should be considered word break characters).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:56:34 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 10 Feb 2011 16:56:34 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1297356994.09.0.639401119445.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fwiw http://bugs.python.org/issue6643 recently fixed on issue where a mutex was being closed instead of reinitialized after a fork.  more are likely needed.

Are you suggesting to use pthread_atfork to call pthread_mutex_init on all mutexes created by Python in the child after a fork?  I'll have to ponder that some more.  Given the mutexes are all useless post fork it does not strike me as a bad idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Feb 10 17:59:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 16:59:25 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297357165.28.0.217914369755.issue11082@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Georg Brandl: can this fix go into Python 3.2? It changes the API.

I like any patch rejecting unicode where unicode is irrevelant (where we don't know how to choose the right encoding).

About the patch: you should maybe add a test to ensure that str is rejected with a TypeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:00:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 10 Feb 2011 17:00:06 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1297357206.6.0.283166498022.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment removes offset and return just the number of bytes sent as an integer.
Tests and documentation are updated accordingly.

----------
Added file: http://bugs.python.org/file20733/sendfile_v8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:02:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 10 Feb 2011 17:02:17 +0000
Subject: [issue11175] allow argparse FileType to accept encoding and errors
	arguments
In-Reply-To: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>
Message-ID: <1297357337.77.0.43064936166.issue11175@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The encoding and errors arguments are probably useful, but why would you use the codecs module?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11175>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:02:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 17:02:53 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1297357373.87.0.75525961369.issue6721@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are you suggesting to use pthread_atfork to call pthread_mutex_init on > all mutexes created by Python in the child after a fork?  I'll have to > ponder that some more.  Given the mutexes are all useless post fork it > does not strike me as a bad idea.

I don't really understand. It's quite similar to the idea you shot down in msg94135. Or am I missing something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:03:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 17:03:49 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1297356107.57.0.130274937134.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297357423.5203.7.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le jeudi 10 f?vrier 2011 ? 16:41 +0000, Ross Lagerwall a ?crit :
> Ross Lagerwall <rosslagerwall at gmail.com> added the comment:
> 
> 32-bit computers can address up to 4GiB of memory

... at least 4 GB. With PAE (Physical Address Extension), we can address
up to 2^36 bytes. It looks like mmap() do support PAE, I suppose that
you need 64 bits offset on a 32 bits system to be able to use PAE :-)

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:06:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 17:06:05 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1297357423.5203.7.camel@marge>
Message-ID: <1297357561.3702.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le jeudi 10 f?vrier 2011 ? 17:03 +0000, STINNER Victor a ?crit :
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le jeudi 10 f?vrier 2011 ? 16:41 +0000, Ross Lagerwall a ?crit :
> > Ross Lagerwall <rosslagerwall at gmail.com> added the comment:
> > 
> > 32-bit computers can address up to 4GiB of memory
> 
> ... at least 4 GB. With PAE (Physical Address Extension), we can address
> up to 2^36 bytes. It looks like mmap() do support PAE, I suppose that
> you need 64 bits offset on a 32 bits system to be able to use PAE :-)

We are talking about virtual addresses, not physical addresses. PAE
doesn't magically enlarge your address registers ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:06:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Feb 2011 17:06:13 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297357573.35.0.378271989678.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Victor - It does not change the API. Only that the ValueError message which had a confusing message that "for iterable data of type <class 'str'> " is made clear that POST should not be a str.
Yes, a TypeError instead of ValueError would be more appropriate here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:12:46 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 10 Feb 2011 17:12:46 +0000
Subject: [issue10656] "Out of tree" build fails on AIX 5.3
In-Reply-To: <1291865704.62.0.494509897126.issue10656@psf.upfronthosting.co.za>
Message-ID: <1297357966.35.0.433174742097.issue10656@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I tried with trunk (python 3.2) on AIX:
./build/configure --with-pydebug --without-computed-gotos
make
and that worked correctly.

Not sure with python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10656>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:20:18 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 10 Feb 2011 17:20:18 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1297358418.19.0.0185346544457.issue6721@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Yeah, I'm trying to figure out what I was thinking then or if I was just plain wrong. :)

I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).

Part of it looks like I wanted a way to detect it was happening as any lock that is held during a fork indicates a _potential_ bug (the lock wasn't registered anywhere to be released before the fork) but not everything needs to care about that.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:24:46 2011
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 10 Feb 2011 17:24:46 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1297358686.67.0.612188042019.issue11076@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Here's a documentation-only patch which adds a section about using vars() to convert a namespace to a dict.

If this becomes a documentation issue, can we target Python 3.2.1 instead of Python 3.3?

----------
Added file: http://bugs.python.org/file20734/issue11076_doc_only.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11076>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:35:23 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 10 Feb 2011 17:35:23 +0000
Subject: [issue11175] allow argparse FileType to accept encoding and errors
	arguments
In-Reply-To: <1297352833.64.0.0994986830559.issue11175@psf.upfronthosting.co.za>
Message-ID: <1297359323.96.0.0591317618678.issue11175@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Probably because the suggestion came from someone thinking about both Python 2 and 3. But given that this feature request can only target Python 3.3, you're absolutely right that there's no need to go through the codecs module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11175>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:40:01 2011
From: report at bugs.python.org (J. Evans)
Date: Thu, 10 Feb 2011 17:40:01 +0000
Subject: [issue5833] readline update
In-Reply-To: <1240605993.87.0.323265568101.issue5833@psf.upfronthosting.co.za>
Message-ID: <1297359601.86.0.884606883674.issue5833@psf.upfronthosting.co.za>


J. Evans <jrevans1 at earthlink.net> added the comment:

I have no problem splitting the patch into multiple files.  When I do so, do I place them here or open separate tickets for each component?

Or if you guys want to just close out the ticket since the actual bug was fixed, I am okay with that too.  We will probably continue to use the patched version of tabexpand for our users since the filename expansion is used quite heavily.  And since we will not be transitioning to py3k anytime in the next several years, we have no issue with what is (or is not) implemented there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5833>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:43:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 17:43:57 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297359837.48.0.0986600614525.issue10966@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm. I'm not sure passing a list of platforms is a good idea. People may want to write e.g. "'bsd' in platform". Also, there are a lot of platforms we don't have access to, so we can't actually maintain a list of platforms.

Also, I really don't like the idea that a missing extension module is a test failure. It can be quite annoying to install all build dependencies (why should people install tcl/tk if they want to hack on e.g. the logging module?), let's not scare people who haven't done so by printing out test failures.

----------
keywords:  -easy
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:46:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 17:46:05 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297359965.68.0.0856504000617.issue11171@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils, Distutils2 -Installation
nosy: +barry, eric.araujo, tarek
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Thu Feb 10 18:53:33 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 10 Feb 2011 17:53:33 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297360413.63.0.562719658826.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Victor: I don't see an API change here.  A ValueError is raised in both cases, and error messages are not part of the API. (And BTW, you may call me Georg.)

Senthil: I'd like the documentation change to be a bit more explicit that a string is always returned.  Since the string must be encoded, it would also be helpful to mention which encoding to use.

The new exception message looks slightly incorrect to me: the argument can also be an iterable of bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:07:06 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 10 Feb 2011 18:07:06 +0000
Subject: [issue11173] Undocumented public APIs in Python 3.2
In-Reply-To: <1297351155.94.0.957592646254.issue11173@psf.upfronthosting.co.za>
Message-ID: <1297361226.71.0.981888594423.issue11173@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In fact, most of the functions are documented.  (Mark S. apparently referred to the "What's new" document when talking about "documented" functions.)

Missing are:

PyAST_CompileEx (because PyAST_Compile wasn't documented either)
PyStructSequence_*
PyType_FromSpec

and the PyThread one which Antoine already mentioned.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11173>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:12:41 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 10 Feb 2011 18:12:41 +0000
Subject: [issue7284] optparse - display version in usage by default
In-Reply-To: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
Message-ID: <1297361561.28.0.815203794959.issue7284@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, optparse is now deprecated, and argparse is the replacement, so I'm closing this report.

----------
nosy: +sandro.tosi
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7284>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:15:46 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 10 Feb 2011 18:15:46 +0000
Subject: [issue4297] Add error_log attribute to optparse.OptionParser
In-Reply-To: <1226413379.99.0.188665223227.issue4297@psf.upfronthosting.co.za>
Message-ID: <1297361746.95.0.669856310772.issue4297@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Daniel, did you read Steven suggestions? are you willing to propose a patch about your feature request against argparse (optparse is deprecated and no more under development in stdlib)?

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4297>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:20:20 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 10 Feb 2011 18:20:20 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1297362020.8.0.990594903014.issue1704474@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi, since optparse is now deprecated (in favor of argparse) and in a year and half there was not progress on this, I'm closing this report.

----------
nosy: +sandro.tosi
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704474>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:20:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 18:20:52 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297362052.02.0.152444972819.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So os.name is also supported. But the point is that if a platform wants to be considered supported then they need to give us a patch to update the tests to make them acceptable to skip.

As for test_ttk and such, those that have a third-party dependency are still optional no matter what. This change is **only** for modules we expect to always build on certain platfoms (e.g., winreg under Windows or crypt on UNIX systems). I mean do we really think ctypes is optional at this point? In general no, only on select platforms where libffi support is lacking. So having the test skip because of a build failure under OS X (like I had for LLVM 2.8 for a while) should not be left behind but instead be considered a failure as ctypes is **supposed** to be supported under darwin. Extension build failure should not always be considered a non-failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:33:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 10 Feb 2011 18:33:44 +0000
Subject: [issue11177] Set asyncore create_socket default argument
In-Reply-To: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>
Message-ID: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

At the current state asyncore implicitly supports TCP (SOCK_STREAM) sockets only, despite UDP support might be added in the future.
For simplicity, create_socket() should assume TCP/IP by default.
This would avoid the user to "import socket" and specify the two constants every time, which is annoying.

----------
files: asyncore_create_socket.patch
keywords: patch
messages: 128327
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Set asyncore create_socket default argument
versions: Python 3.3
Added file: http://bugs.python.org/file20735/asyncore_create_socket.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11177>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:33:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 10 Feb 2011 18:33:52 +0000
Subject: [issue11177] Set asyncore create_socket default argument
In-Reply-To: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>
Message-ID: <1297362832.32.0.576641926021.issue11177@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11177>
_______________________________________

From report at bugs.python.org  Thu Feb 10 19:48:00 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 18:48:00 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1297362052.02.0.152444972819.issue10966@psf.upfronthosting.co.za>
Message-ID: <AANLkTimkj_bGQmMdHwG1zXt-M4kzEeYE2OS=0mO18N+t@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

I should also mention that if the idea of whitelisting failures
doesn't fly, it can always be changed to be a blacklist of failures
(i.e., ditch 'optional' and only use 'required_on'). But I did it this
way to force people to clearly state on what platforms a test was
expected to be skipped on reactively instead of letting the list
slowly degrade as it already has (bunch of stuff inconsistently listed
in regrtest as it is).

On Thu, Feb 10, 2011 at 10:20, Brett Cannon <report at bugs.python.org> wrote:
>
> Brett Cannon <brett at python.org> added the comment:
>
> So os.name is also supported. But the point is that if a platform wants to be considered supported then they need to give us a patch to update the tests to make them acceptable to skip.
>
> As for test_ttk and such, those that have a third-party dependency are still optional no matter what. This change is **only** for modules we expect to always build on certain platfoms (e.g., winreg under Windows or crypt on UNIX systems). I mean do we really think ctypes is optional at this point? In general no, only on select platforms where libffi support is lacking. So having the test skip because of a build failure under OS X (like I had for LLVM 2.8 for a while) should not be left behind but instead be considered a failure as ctypes is **supposed** to be supported under darwin. Extension build failure should not always be considered a non-failure.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10966>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:01:08 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 Feb 2011 19:01:08 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1297364468.71.0.206083819269.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I spent some time bisecting the SVN history in the py3k branch, and believe that r84914 is the commit that introduced this issue.

Details:
  
  Trying on 4-core i386 RHEL 5 box
  $ svn up -r REV
  $ make clean ; make
  (configured --with-pydebug)

Reproducer:

  ./python -c "import multiprocessing.managers ; mpp = multiprocessing.Pool(4); sm = multiprocessing.managers.SyncManager(); sm.start()"

  (running it 3 times; each time, at each build I see it either successfully completing 3 times, or having the Py_FatalError 3 times)

Bisecting:
  r86720: CRASHES with r86729 --with-pydebug (from when I was investigating this before)
  r73573: Runs OK with r73573 --with-pydebug (r73573 was origin for 3.1 tag)

    => somewhere in 73572..86729

  r76195: Runs OK with r76195 --with-pydebug (r76195 added the new GIL)

    => somewhere in 76195..86729

  r80724: Runs OK with r80724 --with-pydebug (changed threading code to "Make (most of) Python's tests pass under Thread Sanitizer.")

    => somewhere in 80724..86729

  r83722: Runs OK with r80724 --with-pydebug (touched multiprocessing)

    => somewhere in 83722..86729

  r85222: CRASHES with r85222 --with-pydebug (rough midpoint)

    => somewhere in 83722..85222

  r84472: Runs OK with r84472 --with-pydebug (arbitrary midpoint)

    => somewhere in 84472..85222

  r84847: Runs OK with r84847 --with-pydebug (arbitrary midpoint)

     => somewhere in 84847..85222

  r85033: CRASHES with r85033 --with-pydebug (arbitrary midpoint)

     => somewhere in 84847..85033

  r84938: CRASHES with r84938 --with-pydebug (arbitrary midpoint)

     => somewhere in 84847..84938

  r84892: Runs OK with r84892 --with-pydebug (arbitrary midpoint)

     => somewhere in 84892..84938

  r84915: CRASHES with r84915 --with-pydebug (arbitrary midpoint)

     => somewhere in 84892..84915

  r84903: Runs OK with r84903 --with-pydebug (arbitrary midpoint)

     => somewhere in 84903..84915

  r84914: CRASHES with r84914 --with-pydebug (affects threads)

     => somewhere in 84903..84914

  r84913: Runs OK with r84913 --with-pydebug (previous commit before 84914)

     => r84914 is the commit that triggered this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:02:44 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 Feb 2011 19:02:44 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1297364564.08.0.514841672097.issue10517@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +krisvale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:03:55 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 Feb 2011 19:03:55 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1297364635.64.0.0417779562919.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

r84914 was the implementation of issue 9786 (Native TLS support for pthreads)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:25:17 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 10 Feb 2011 19:25:17 +0000
Subject: [issue11167] Overflow in unicode_hash
In-Reply-To: <1297330831.08.0.0747559116298.issue11167@psf.upfronthosting.co.za>
Message-ID: <20110210192449.GA5470@sleipnir.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Could you try the same in Python 2.7 ?

It's the same, just in stringobject.c. Many hash functions have this issue.

> The overflow is intended (after all, it's a hash function), but we should
> probably add a cast to Py_hash_t to the hash building line in order to make
> the compiler aware of this.

I think I'd just do the hash calculation in unsigned and cast at the end
of the function. For the conversion from unsigned to signed we'd still
rely on implementation defined behavior [1], but at least the signed
integer overflow would be gone.

[1] Mark Dickinson made an effort to document assumptions for unsigned
to signed conversions. I don't know if this has found its way it into
the developer docs:

http://mail.python.org/pipermail/python-dev/2009-December/094388.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11167>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:41:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 19:41:57 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1297362052.02.0.152444972819.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297366914.3719.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As for test_ttk and such, those that have a third-party dependency are
> still optional no matter what. This change is **only** for modules we
> expect to always build on certain platfoms (e.g., winreg under Windows
> or crypt on UNIX systems).

Ah, thanks for pointing that out to me. That's certainly better than
what I thought :)

> I mean do we really think ctypes is optional at this point?

Why wouldn't it be? It doesn't offer any essential functionality, and
most applications and libraries certainly don't depend on it.
It's far more optional than zlib (which a bunch of stdlib functionality
relies on) IMO.

What's more, standard C isn't enough to compile ctypes (as you witnessed
with LLVM). So, really, making absence of ctypes a failure sounds too
severe to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 20:54:12 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 19:54:12 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297367652.69.0.548885750347.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Well, ctypes failing because it cannot compile is only when a platform that is not listed as optional cannot import it. So if some platform does not support ctypes then it gets added to the list, end of story.

We only support so many platforms as it is. And with the hg transition, if someone maintains a closed-source fork they can easily patch their own version of Python so that test_ctypes is skipped without issue w/o causing us to not notice when ctypes stops compiling on a platform we do support **and** expect it to be available on.

Anyway, I am going to continue to rip out the (un)expected test skip code regardless of how people come down on whether this is too strict or not on a per-test basis as I still think the expected skip list is worthless as-is. We can then discuss this on python-committers (since we have to maintain the test compatibility).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:05:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 20:05:59 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1297367652.69.0.548885750347.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297368355.3719.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, ctypes failing because it cannot compile is only when a platform
> that is not listed as optional cannot import it. So if some platform
> does not support ctypes then it gets added to the list, end of story.

How do you add "llvm under darwin" (or any similar case, e.g. "Sun CC
under Solaris") to that list of platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:09:56 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 20:09:56 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297368596.7.0.460118300268.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

You don't. ctypes failing under LLVM 2.8 should not be a special case of skipping; ctypes not building on darwin regardless of whether it is gcc or clang is a failure. If someone uses a compiler we don't support, that's their decision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:18:01 2011
From: report at bugs.python.org (wrobell)
Date: Thu, 10 Feb 2011 20:18:01 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1297369081.92.0.369139383039.issue4681@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

Ross, you are completely right. thanks for the tips!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:19:08 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 10 Feb 2011 20:19:08 +0000
Subject: [issue11178] Running tests inside a package by module name fails
In-Reply-To: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>
Message-ID: <1297369148.53.0.82343889297.issue11178@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Reported by a user and verified by me with both Python 2.7 and 3.2.

Trying to run tests by module or package name seems to fail.

directory structure:

    project root: C:\Users\hpierson\Projects\pytest
        \test
            __init__.py (empty)
            testfoo.py (sample test file

running test package by name - no tests discovered

C:\Users\hpierson\Projects\pytest
PS? cpy C:\Python31\Scripts\unit2.py test

----------------------------------------------------------------------
Ran 0 tests in 0.000s

 

running test module by name - can't find module

C:\Users\hpierson\Projects\pytest
PS? cpy C:\Python31\Scripts\unit2.py test.testfoo
Traceback (most recent call last):
  File "C:\Python31\Scripts\unit2.py", line 7, in <module>
    main_()
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 237, in main_
    main(module=None)
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 94, in __init__
    self.parseArgs(argv)
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 149, in parseArgs
    self.createTests()
  File "C:\Python31\lib\site-packages\unittest2\main.py", line 158, in createTests
    self.module)
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 133, in loadTestsFromNames
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 133, in <listcomp>
    suites = [self.loadTestsFromName(name, module) for name in names]
  File "C:\Python31\lib\site-packages\unittest2\loader.py", line 101, in loadTestsFromName
    parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'testfoo'

----------
assignee: michael.foord
components: Library (Lib)
messages: 128337
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Running tests inside a package by module name fails
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11178>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:31:56 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 20:31:56 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297369916.54.0.245796693444.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

One other option is to simply have a whitelist of platforms that test.support knows of so it only considers it a failure when the platform being run on is known (regrtest does this already).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:32:25 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 20:32:25 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297369945.54.0.897599746133.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I should mention this would act as a nice testing doc for exactly which platforms CPython considers supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 21:55:54 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Feb 2011 20:55:54 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297371354.04.0.663252338863.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Upon reflection I don't think my suggested email API change is a good one.  Currently it is possible to create a Message using non-ASCII headers and manipulate that message. The fact that you can't serialize that message is, really, a bug: one can and I think should assume utf-8 as the default encoding when serializing a message.

So rejecting non-ASCII strings in mailbox may also be a questionable decision, but since accepting string at all is really a legacy API (one should use a Message or a binary string), I think it is OK to leave it.  (Why should one not use string for input to mailbox?  Because the reason to use string is to avoid going through Message, but if your message includes non-ASCII it would have to be processed through the bug-fixed Message anyway to serialize it correctly...so you might as well just use Message for input to mailbox).

I hope to have a patch for the mailbox-corruption-if-traceback error soon (before the weekend).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:46:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 21:46:30 +0000
Subject: [issue11177] Set asyncore create_socket default argument
In-Reply-To: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>
Message-ID: <1297374390.26.0.178251539199.issue11177@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your "versionchanged" is misleading. It should be something like "family and type can now be omitted".

----------
components: +Library (Lib)
nosy: +pitrou
stage:  -> patch review
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11177>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:50:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 21:50:09 +0000
Subject: [issue11172] Avoid '.' as runpath on AIX
In-Reply-To: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>
Message-ID: <1297374609.88.0.200436797889.issue11172@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou, sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11172>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:51:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 21:51:11 +0000
Subject: [issue11169] compileall doesn't support the PEP 383 (undecodable
	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <1297374671.92.0.615862312913.issue11169@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +r.david.murray
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11169>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:58:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 21:58:22 +0000
Subject: [issue2228] Imaplib speedup patch
In-Reply-To: <1204580526.67.0.16390655339.issue2228@psf.upfronthosting.co.za>
Message-ID: <1297375102.14.0.384841297821.issue2228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The part which is replaced by that patch (the readline() method in IMAP4_SSL) doesn't exist anymore in current imaplib code. Instead the file-like object created by socket.makefile() is used; its readline() method is probably quite faster than any pure Python implementation.

----------
assignee: pierslauder -> 
nosy: +pitrou
resolution:  -> out of date
status: open -> closed
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2228>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:59:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 21:59:11 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297375151.15.0.821244856229.issue10966@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file20725/issue10966.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 22:59:22 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 10 Feb 2011 21:59:22 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1297375162.0.0.799854247134.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

This appears to be happening in a child process when the parent process is running:
  Lib/multiprocessing/util.py, line 255, in _exit_function ()

Liberally adding printf() and getpid() calls in various places, seems to always happen when parent process is within "call_py_exitfuncs()" within Py_Finalize; error is from the child process that was created last.

Using gdb with a breakpoint on "call_py_exitfuncs" and single-stepping seems to confirm a single exitfunc:
  Lib/multiprocessing/util.py, line 255, in _exit_function ()
and that the child dies as that bytecode function is executed.

$ ./python -c "import multiprocessing.managers ; mpp = multiprocessing.Pool(4); sm = multiprocessing.managers.SyncManager(); sm.start()"
Py_InitializeEx called for PID 27824
posix_fork called by PID 27824
child of posix_fork has PID 27825
posix_fork called by PID 27824
child of posix_fork has PID 27826
posix_fork called by PID 27824
child of posix_fork has PID 27827
posix_fork called by PID 27824
child of posix_fork has PID 27828
posix_fork called by PID 27824
child of posix_fork has PID 27832
Py_Finalize called for PID 27824
wait_for_thread_shutdown() finished for PID 27824
Fatal Python error for PID 27832: Invalid thread state for this thread
call_py_exitfuncs() finished for PID 27824
PyOS_FiniInterrupts() finished for PID 27824
[64240 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:01:01 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 22:01:01 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297375261.86.0.188756019789.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Here is the completed patch. It adds required_on and 'optional' args to test.support.import_module() to help delineate if a test should **not** be skipped simply because a module could not be imported. It also changes various tests to use the new args. Finally, the entire concept of (un)expected skips is removed from regrtest.

----------
Added file: http://bugs.python.org/file20736/issue10966.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:09:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Feb 2011 22:09:49 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297375789.13.0.59634307619.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> 1. Make keys(), values(), items() methods return view object for
> ndbm, gdbm and dumb objects. I following the codes in dictobject.c.
Did you have to copy the code?  Isn?t it possible to somehow reuse it?

> The keysview object support len(), "in" operator, and iteratable,
> while valuesview and itemsview object only support len() and iteratable.
That does not seem to comply with the definition of dict views.  Do the views yield elements in the same order?  (In a dict, iteration order is undefined but consistent between the various views, IIUC.)

> 3. Remove dumb's keys() method which calls self._index.keys() since it is unnecessary.
Does dumb have no keys method then?

> 4. Using more specialized assertXxx methods in test cases.
See my comments on http://codereview.appspot.com/4185044/

> #5736 's patch for adding iteration to ndbm and gdbm modules simple
> calling PyObject_GetIter(dbm_keys(dbm, NULL)) for both gdbm and ndbm,
> but I feel it's better to create a seperate iterator object for gdbm objects.
Okay, so I shall close the other bug report, indicating it?s superseded by your patch.

I can?t judge the C code; maybe Raymond or Daniel will.  They?re also experts about collections and ABCs, so they?ll be able to confirm or infirm what I?ve said about dict views and the registration stuff (on codereview).

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:12:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 10 Feb 2011 22:12:44 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1297375964.25.0.370806331764.issue11076@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for this patch.

Documentation fixes are backported from the development branch to stable branches, so yes, this will land in 3.1 too.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
type: feature request -> 
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11076>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:21:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 10 Feb 2011 22:21:50 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1297376510.52.0.558444178279.issue10423@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Steven, I'm not exactly getting what you're meaning here: are you actually saying to replace every occurrence of 'option' with 'argument' in the whole argparse module doc, or just make it stronger in the mentioned line that what was called previously 'option' is now called 'args' ?

PS: wouldn't it be better to use this form "(options, args) = parser.parse_args()" instead of "options, args = parser.parse_args()" ? optparse doc uses the former, so it should be easy to recognize for those willing to migrate to argparse

----------
nosy: +sandro.tosi
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Thu Feb 10 23:33:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 22:33:38 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297377218.43.0.0330610197364.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Another remark. In the "poplib" section, there is a paragraph about asyncore: I don't see how both are related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:34:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 23:34:39 +0000
Subject: [issue7997] http://www.python.org/dev/faq/ doesn't seem to explain
	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1297380879.8.0.400085390772.issue7997@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:35:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Feb 2011 23:35:55 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1297375261.86.0.188756019789.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297380951.3719.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch works fine on Linux but breaks test_pipes and test_sqlite on
Windows:

[1/1] test_pipes
testBadAppendOptions (test.test_pipes.SimplePipeTests) ... ok
testBadOpenMode (test.test_pipes.SimplePipeTests) ... ok
testBadPrependOptions (test.test_pipes.SimplePipeTests) ... ok
testClone (test.test_pipes.SimplePipeTests) ... ok
testEmptyPipeline1 (test.test_pipes.SimplePipeTests) ... 'cat' is not
recognized
 as an internal or external command,
operable program or batch file.
FAIL
testEmptyPipeline2 (test.test_pipes.SimplePipeTests) ... ok
testEmptyPipeline3 (test.test_pipes.SimplePipeTests) ... ok
testQuoting (test.test_pipes.SimplePipeTests) ... ok
testReadOpenSink (test.test_pipes.SimplePipeTests) ... ok
testRepr (test.test_pipes.SimplePipeTests) ... ok
testSetDebug (test.test_pipes.SimplePipeTests) ... ok
testSimplePipe1 (test.test_pipes.SimplePipeTests) ... 'tr' is not
recognized as
an internal or external command,
operable program or batch file.
FAIL
testSimplePipe2 (test.test_pipes.SimplePipeTests) ... The system cannot
find the
 file specified.
ERROR
testSimplePipe3 (test.test_pipes.SimplePipeTests) ... The system cannot
find the
 file specified.
FAIL
testWriteOpenSource (test.test_pipes.SimplePipeTests) ... ok

======================================================================
ERROR: testSimplePipe2 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\test_pipes.py", line 34, in testSimplePipe2
    with open(TESTFN2) as f:
IOError: [Errno 2] No such file or directory: '@test_560_tmp2'

======================================================================
FAIL: testEmptyPipeline1 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\test_pipes.py", line 58, in
testEmptyPipeline1
    self.assertEqual(f.read(), d)
AssertionError: '' != 'empty pipeline test COPY'
+ empty pipeline test COPY

======================================================================
FAIL: testSimplePipe1 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\test_pipes.py", line 26, in testSimplePipe1
    self.assertEqual(f.read(), 'HELLO WORLD #1')
AssertionError: '' != 'HELLO WORLD #1'
+ HELLO WORLD #1

======================================================================
FAIL: testSimplePipe3 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\test_pipes.py", line 44, in testSimplePipe3
    self.assertEqual(f.read(), 'HELLO WORLD #2')
AssertionError: '' != 'HELLO WORLD #2'
+ HELLO WORLD #2

----------------------------------------------------------------------
Ran 15 tests in 0.250s

FAILED (failures=3, errors=1)
test test_pipes failed -- multiple errors occurred

test test_sqlite crashed -- <class 'ImportError'>: No module named _sqlite3
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\regrtest.py", line 948, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "Z:\__svn__\lib\test\test_sqlite.py", line 4, in <module>
    test.support.import_module('_sqlite3', required_on=['win32'])
  File "Z:\__svn__\lib\test\support.py", line 115, in import_module
    return importlib.import_module(name)
  File "Z:\__svn__\lib\importlib\__init__.py", line 124, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "Z:\__svn__\lib\importlib\_bootstrap.py", line 822, in _gcd_import
    raise ImportError(_ERR_MSG.format(name))
ImportError: No module named _sqlite3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:39:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Feb 2011 23:39:19 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297381159.11.0.239206300094.issue11071@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In the What's new in 3.2: there is no mention of the PEP 3003 (Python Language Moratorium). May we add a section "What is not new in 3.2"? :-) This PEP is something specific to Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:55:21 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Feb 2011 23:55:21 +0000
Subject: [issue10966] eliminate use of ImportError implicitly representing
	SkipTest
In-Reply-To: <1295566830.75.0.786153857799.issue10966@psf.upfronthosting.co.za>
Message-ID: <1297382121.2.0.749844202772.issue10966@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

New patch which makes test_pipes back into an explicit skip if os.name !+ posix and makes test_sqlite optional on all platforms.

----------
Added file: http://bugs.python.org/file20737/issue10966.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10966>
_______________________________________

From report at bugs.python.org  Fri Feb 11 00:57:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Feb 2011 23:57:17 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297382237.61.0.151335089195.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Victor, I don't think that would be useful in the Whatsnew document.  That PEP was really about letting other implementations get caught-up.  It has nearly zero relevance to users of CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Fri Feb 11 01:11:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 00:11:43 +0000
Subject: [issue11179] ccbench doesn't work on 3.1/2.7
In-Reply-To: <1297383103.21.0.0381281186819.issue11179@psf.upfronthosting.co.za>
Message-ID: <1297383103.21.0.0381281186819.issue11179@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The ccbench shipped with 3.2 is supposed to work with older versions but:

Traceback (most recent call last):
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 609, in <module>
    main()
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 564, in main
    latency_client(**kwargs)
  File "/home/antoine/py3k/py3k/Tools/ccbench/ccbench.py", line 279, in latency_client
    with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
AttributeError: 'socket' object has no attribute '__exit__'

----------
assignee: pitrou
components: Demos and Tools
messages: 128353
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: ccbench doesn't work on 3.1/2.7
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11179>
_______________________________________

From report at bugs.python.org  Fri Feb 11 01:15:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 00:15:36 +0000
Subject: [issue7997] http://www.python.org/dev/faq/ doesn't seem to explain
	how to regenerate "configure"
In-Reply-To: <1266882841.0.0.727782074241.issue7997@psf.upfronthosting.co.za>
Message-ID: <1297383336.53.0.0816915347954.issue7997@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Python's "configure.in" script typically requires a specific version of > autoconf.  At the moment, this reads:
>     version_required(2.61)

This is a bit outdated. Right now we only have:
AC_PREREQ(2.65)

which IIUC means 2.65 or higher.

> Do not edit "configure"; instead, edit "configure.in" and run
> "autoreconf"

"autoreconf" fails for me, but "autoconf" works. I'm not sure what's the difference.

By the way, the dev FAQ is now maintained at http://hg.python.org/devguide/ although this still needs putting in www.python.org.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Fri Feb 11 01:23:44 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Fri, 11 Feb 2011 00:23:44 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1297383824.59.0.911519169932.issue11176@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

I agree; it's too artsy. I'll see if I can come up with a relevant and clever alternative.

----------
nosy: +anikom15

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Fri Feb 11 01:28:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 00:28:14 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297384094.1.0.318770858606.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is the promised patch, with tests.  For once writing the patch was harder than writing the tests, but only just :)

I'm not sure all the 100% sure the cleanups will work on all systems (I'm looking at you, Windows), but since any problems will occur in a path where an error is already being raised, it doesn't seem as though it can make things worse.

Looking for review and RM approval.

----------
priority: normal -> release blocker
stage: test needed -> patch review
Added file: http://bugs.python.org/file20738/mailbox_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:15:56 2011
From: report at bugs.python.org (newacct)
Date: Fri, 11 Feb 2011 01:15:56 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>


New submission from newacct <spoon.reloaded at gmail.com>:

heapq.nlargest()/nsmallest() currently use a size-k heap to get the k largest/smallest items. This takes O(n log k): heapifying the first k elements (O(k)); iterating through (n-k) elements of the list, each insertion/deletion takes O(log k), for O((n-k)log k); and then sorting the elements at the end for O(k log k).

There are several more efficient ways to do this:

1) O(n + k log n): Put the entire list into the heap at once. This takes O(n). Then we can take out the k largest / smallest from the heap in sorted order, each taking O(log n), for a total of O(n + k log n), which is much better than O(n log k) if k is small and n is big. Unfortunately, this takes a lot (O(n)) of memory.

2) O(n + k log k): Use the linear time (O(n)) selection algorithm to find out what the k'th largest/smallest element is. (http://en.wikipedia.org/wiki/Selection_algorithm#Linear_general_selection_algorithm_-_Median_of_Medians_algorithm) Then, partition (a la Quicksort) the elements into the ones bigger and smaller than this; this is also O(n). Maybe the partitioning can happen as part of the selection algorithm. At the end, sort the k elements, for O(k log k). If we remove the requirement that the result has to be sorted, then this algorithm is just O(n).

----------
messages: 128357
nosy: newacct
priority: normal
severity: normal
status: open
title: More efficient nlargest()/nsmallest()
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:29:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 01:29:38 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297387778.32.0.772767410241.issue11180@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 02:50:59 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Feb 2011 01:50:59 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297389059.22.0.33671254916.issue11180@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think you should implement and benchmark one of them. I'm dubious that the better asymptotic values will really translate into better performance. For example, the O(n) median selection algorithm has a large constant factor associated with it.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:40:04 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 11 Feb 2011 02:40:04 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297392004.68.0.995469127991.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Here's the complete patch, added unittest for width modifier and precision modifier for '%s' formatter of PyUnicode_FromFormat() function.

----------
Added file: http://bugs.python.org/file20739/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 11 03:47:00 2011
From: report at bugs.python.org (Adi Roiban)
Date: Fri, 11 Feb 2011 02:47:00 +0000
Subject: [issue11181] TLS end connection not detected properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>


New submission from Adi Roiban <adi at roiban.ro>:

FTP_TLS.retrybinary should detect the end of a TLS read in the same way as FTP.TLS_retryline does.

it should be something like this... catching ssl.ZeroReturnError as a valid expection for signaling EOF.

                    try:
                        data = conn.recv(blocksize)
                    except ssl.ZeroReturnError:
                        # pyOpenSSL does not return 0, but rather
                        # SSL.ZeroReturnError
                        pass
                    if not data:
                        break
                    callback(data)

----------
components: Library (Lib)
messages: 128360
nosy: adiroiban
priority: normal
severity: normal
status: open
title: TLS end connection not detected properly in retrbinary
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11181>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:05:49 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Feb 2011 04:05:49 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297397149.36.0.149418033131.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is the patch with addressing the comments.
1. It should be TypeError instead of ValueError when str is rejected. We introduced ValueError for this release only, so there is no breakage here.
2. Informed the user that string should be encoded to bytes using user-specified encoding before it is sent as POST data. Also pointed to Examples in the urllib.request section. ( I could not hyperlink directly to #examples section. If that is possible, it would be better).

----------
Added file: http://bugs.python.org/file20740/Issue11082-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:59:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Feb 2011 04:59:09 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297400349.31.0.503399435202.issue11082@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


Removed file: http://bugs.python.org/file20740/Issue11082-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Fri Feb 11 05:59:46 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Feb 2011 04:59:46 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297400386.8.0.247696476758.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

patch with Docs :ref: to proper section.

----------
Added file: http://bugs.python.org/file20741/issue11082-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:02:45 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Fri, 11 Feb 2011 06:02:45 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297404165.59.0.768265397054.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

Test if email.encoders.encode_base64 returns a single line string, or a string broken up in 76 chars line, as per RFC.

----------
Added file: http://bugs.python.org/file20742/issue9298-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:04:55 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Fri, 11 Feb 2011 06:04:55 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297404295.84.0.487121378229.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

Replaces b64encode by encodebytes.

----------
keywords: +patch
Added file: http://bugs.python.org/file20743/issue9298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Fri Feb 11 07:29:16 2011
From: report at bugs.python.org (Ron Adam)
Date: Fri, 11 Feb 2011 06:29:16 +0000
Subject: [issue11182] pydoc.Scanner class not used by anything
In-Reply-To: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>
Message-ID: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>


New submission from Ron Adam <ron_adam at users.sourceforge.net>:

There doesn't seem to be any references to it in any other part of pydoc, or the Library for that matter.  Searching for it on google code search (and also google web search) only turns up auto generated API references for python editing tools like VIM, and of course it's existence in pydoc itself.

This doesn't appear to be related to the ModuleScanner class in any way other than possibly being a bit of left over example code.

Can it be removed?

----------
components: Library (Lib)
messages: 128365
nosy: ron_adam
priority: normal
severity: normal
status: open
title: pydoc.Scanner class not used by anything
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11182>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:55:25 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Feb 2011 07:55:25 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297410925.1.0.00197112890971.issue11116@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Hmm, is "except Exception" the right thing to use here?  The "finally" before executed for really all exceptions.

Otherwise, this can go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 08:58:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Feb 2011 07:58:20 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297411100.74.0.076853513005.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I still find "user-specified encoding" unclear.  This can be addressed at a different time though.

Your exception message is missing a space between "bytes" and "or"; otherwise this is ok to commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Fri Feb 11 09:09:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Feb 2011 08:09:07 +0000
Subject: [issue11181] TLS end connection not detected properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297411747.58.0.450731530298.issue11181@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11181>
_______________________________________

From report at bugs.python.org  Fri Feb 11 09:51:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2011 08:51:34 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297414294.67.0.887677074359.issue11180@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The current routines are designed to consume only k elements of memory.  That is the way it should remain.  Manifesting the entire input iterable into memory is unnecessary and is not cache friendly.

Also, I question your assertions about running time.  In the worst case where the entire input in reverse sorted, it does take O(log k) for each insertion.  For other cases, like random orderings, it takes much less because many of the inputs only need to compare to the very top element of the heap.  In practice for small k and large n, running time close to O(n) is not uncommon.

-----------------
class Int(int):
    def __lt__(self, other):
        global cmps
        cmps += 1
        return int.__lt__(self, other)

from random import shuffle
from heapq import nsmallest

n = 10000
k = 16
data = list(map(Int, range(n)))

for i in range(10):
    shuffle(data)
    cmps = 0
    result = nsmallest(k, data)
    print(cmps, result)

-- test run ------------------

10485 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10560 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10584 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10518 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10582 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10650 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10409 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10577 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10499 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
10603 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

----------
assignee:  -> rhettinger
components: +Library (Lib)
resolution:  -> rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 10:13:05 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 11 Feb 2011 09:13:05 +0000
Subject: [issue6721] Locks in python standard library should be sanitized on
	fork
In-Reply-To: <1297358418.19.0.0185346544457.issue6721@psf.upfronthosting.co.za>
Message-ID: <AANLkTinCxBs9afhQDA+-00T2T9L5=Yh-xORnutwe=aLb@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).

Yeah, apparently OS-X is one of them, the reporter in #11148 is
experiencing segfaults under OS-X.

> Are you suggesting to use pthread_atfork to call pthread_mutex_init on all mutexes created by Python in the child after a fork?  I'll have to ponder that some more.  Given the mutexes are all useless post fork it does not strike me as a bad idea.

Yes, that's what I was thinking. Instead of scattering the
lock-reclaiming code all over the place, try to use a more standard
API specifically designed with that in mind.
Note the base issue is that we're authorizing things which are
forbidden : in a multi-threaded process, only sync-safe calls are
authorized between fork and exec.

2011/2/10 Gregory P. Smith <report at bugs.python.org>:
>
> Gregory P. Smith <greg at krypto.org> added the comment:
>
> Yeah, I'm trying to figure out what I was thinking then or if I was just plain wrong. :)
>
> I was clearly wrong about a release being done in the child being the right thing to do (issue6643 proved that, the state held by a lock is not usable to another process on all platforms such that release even works).
>
> Part of it looks like I wanted a way to detect it was happening as any lock that is held during a fork indicates a _potential_ bug (the lock wasn't registered anywhere to be released before the fork) but not everything needs to care about that.
>
> ----------
> versions: +Python 3.3
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6721>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:05:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 10:05:26 +0000
Subject: [issue11181] TLS end connection not detected properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297418726.04.0.759885001079.issue11181@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: high -> normal
stage:  -> needs patch
type: crash -> behavior
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11181>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:08:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 10:08:30 +0000
Subject: [issue11183] Finer-grained exceptions for the ssl module
In-Reply-To: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>
Message-ID: <1297418910.83.0.110389671752.issue11183@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

pyOpenSSL (*) has the good idea of defining exception subclasses for the various OpenSSL error codes (ZeroReturnError, WantReadError, etc.). The ssl module could do the same.

(*) http://packages.python.org/pyOpenSSL/openssl-ssl.html

----------
components: Library (Lib)
messages: 128370
nosy: exarkun, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: Finer-grained exceptions for the ssl module
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11183>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:48:39 2011
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 11 Feb 2011 10:48:39 +0000
Subject: [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1297421319.19.0.640444185202.issue11076@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

There's no argparse in 3.1, so it should only go into 2.7, 3.2 and 3.3. But yes, the patch looks great to me too.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11076>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:52:10 2011
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 11 Feb 2011 10:52:10 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1297421530.41.0.622752576568.issue10423@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The request was for the latter: "just make it stronger in the mentioned line that what was called previously 'option' is now called 'args'".

As far as adding the parentheses or not, I never once used the parentheses back when I was using optparse, so it didn't even strike me to put them in there. But you're right - the optparse docs do that, so I'm fine if you'd like to make the argparse discussion of optparse match up better with the optparse docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Fri Feb 11 11:57:11 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 11 Feb 2011 10:57:11 +0000
Subject: [issue11181] TLS end connection not detected properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297421831.08.0.48654608064.issue11181@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Please provide more information.
Have you actually seen this happen?
retrlines method isn't currently looking for EOF.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11181>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:37:52 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 11:37:52 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I get 2 errors when running test_io.py with trunk on AIX. 

======================================================================
ERROR: test_large_file_ops (__main__.CIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
OverflowError: Python int too large to convert to C long

======================================================================
ERROR: test_large_file_ops (__main__.PyIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
OverflowError: Python int too large to convert to C long

----------------------------------------------------------------------
Ran 395 tests in 27.958s

FAILED (errors=2, skipped=8)

thanks in advance

----------
components: IO
messages: 128374
nosy: sable
priority: normal
severity: normal
status: open
title: test_io error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 12:40:02 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 11:40:02 +0000
Subject: [issue11185] test_wait4 error on AIX
In-Reply-To: <1297424402.38.0.348928652961.issue11185@psf.upfronthosting.co.za>
Message-ID: <1297424402.38.0.348928652961.issue11185@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I get an error when running test_wait4 with trunk on AIX:

test_wait (__main__.Wait4Test) ... FAIL

======================================================================
FAIL: test_wait (__main__.Wait4Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "./Lib/test/test_wait4.py", line 23, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 0 != 1486954

----------------------------------------------------------------------
Ran 1 test in 12.030s

FAILED (failures=1)
Traceback (most recent call last):
  File "./Lib/test/test_wait4.py", line 32, in <module>
    test_main()
  File "./Lib/test/test_wait4.py", line 28, in test_main
    run_unittest(Wait4Test)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 72, in test_wait
    self.wait_impl(cpid)
  File "./Lib/test/test_wait4.py", line 23, in wait_impl
    self.assertEqual(spid, cpid)
AssertionError: 0 != 1486954

Thanks in advance

----------
messages: 128375
nosy: sable
priority: normal
severity: normal
status: open
title: test_wait4 error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11185>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:00:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 12:00:05 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297425605.83.0.0180168052147.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, strange. Is it a 32-bit build? Is HAVE_LARGEFILE_SUPPORT defined in pyconfig.h?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:14:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 12:14:04 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297426444.08.0.657327128029.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently AIX needs a specific #define to enable large file support:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/prg_lrg_files.htm

Python defines _LARGEFILE_SOURCE by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:38:24 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Feb 2011 12:38:24 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297427904.71.0.712033195375.issue11180@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Raymond]
> Also, I question your assertions about running time. [...]

Interesting observation.  I wonder what the average number of comparisons actually is, for random inputs.  A quick back-of-the-envelope calculation suggests that O(max(k*log(k)*log(n), n)) might be a tighter upper bound.

Anyway, I agree with Benjamin that you (newacct) would need to implement the algorithm and demonstrate an obvious improvement.  Even then, it would be hard to swallow changing the algorithms to require O(n) space.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:40:05 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 11 Feb 2011 12:40:05 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297428005.93.0.286196658195.issue11149@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

I think the patch is good to go, any comments/questions ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11149>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:44:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Feb 2011 12:44:13 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297428253.95.0.964341053217.issue11082@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks. Committed in r88394.

Regarding the encoding information. An explanation of this sort might be helpful.

The string can be encoded using ISO-8859-1 which is the default encoding for POST data or the user can also encode using  a custom encoding , in which case,  Content-Type: header should specify the encoding value in addition to 'application/x-www-form-urlencoded' which is specified for POST data. For Example:, if one has to use utf-8

>>> sdata = urllib.parse.urlencode({"?":"?"})
>>> bytesdata = sdata.encode('utf-8')
>>>reqheaders=dict([("Content-Type"," application/x-www-form-urlencoded ; charset=utf-8")])
>>>urllib.request.Request('http://www.example.com',bytesdata,reqheaders)

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:48:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 12:48:15 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297428495.84.0.702163452654.issue7330@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like your patch fixes #10829: you should add tests for that, you can just reuse the tests of my patch (attached to #10829).

---

unicode_format() looks suboptimal.

+    memset(buffer, ' ', width);
+    width_unicode = PyUnicode_FromStringAndSize(buffer, width);

You should avoid this byte string (buffer) and use memset() on the Unicode string directly. Something like:

Py_UNICODE *u;
Py_ssize_t i;
width_unicode = PyUnicode_FromUnicode(NULL, width);
u = PyUnicode_AS_UNICODE(width_unicode);
for(i=0; i < width; i++) {
  *u = (Py_UNICODE)' ';
  u++;
}

You should also avoid the creation of a temporary unicode object (it can be slow if precision is large) using PySequence_GetSlice(). Py_UNICODE_COPY() does already truncate the string because you can pass an arbitrary length.

---

I don't like "unicode_format" function name: it sounds like "str.format()" in Python. A suggestion: "unicode_format_align"

---

With your patch, "%.200s" truncates the input string to 200 *characters*, but I think that it should truncate to 200 *bytes*, as printf does.

---

-                n += PyUnicode_GET_SIZE(str);
+                n += width > PyUnicode_GET_SIZE(str) ? width : PyUnicode_GET_SIZE(str);

I don't like this change because I hate having to compute manually strings length. It should that it would be easier if you format directly strings with width and precision at step 3, instead of doing it at step 4: so you can just read the length of the formatted string, and it avoids having to handle width/precision in two steps (which may be inconsistent :-/).

---

Your patch implements %.100s (and %.100U): we might decide what to do with #10833 before commiting your patch.

---

In my opinion, the patch is a little bit too big. We may first commit the fix on the code parsing the width and precision: fix #10829?

---

Can you add tests for "%.s"? I would like to know if "%.s" is different than "%s" :-)

---

-                                 "must be a sequence, not %200s",
+                                 "must be a sequence, not %.200s",

Hum, I think that they are many other places where such fix should be done. Nobody noticed this typo before because %.200s nor %200s were implemented (#10833).


---

Finally, do you really need to implement %200s, %2.5s and %.100s? I don't know, but I would be ok to commit the patch if you fix it for all of my remarks :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:55:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 12:55:09 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If you have an undecodable filenames on UNIX, Python 3 escapes undecodable bytes using surrogates. pydoc: HTMLDoc.index() uses indirectly os.listdir() which does such operation, and later filenames are encoded to UTF-8 (the whole HTML content is encoded to UTF-8).

In practice, you cannot import such .py file, you run them using "python script.py", so we can maybe just ignore modules with undecodable filenames. For example:

def isUndecodableFilename(filename):
  return any((0xD800 <= ord(ch) <= 0xDFFF) for ch in filename)

Or we can escape the surrogate characters, but I don't know how. Write "\uDC80" in a HTML document is not a good idea, especially in an URL (e.g. Firefox replaces \ by / in URLs).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 128382
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: pydoc: HTMLDoc.index() doesn't support PEP 383
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Fri Feb 11 13:56:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 12:56:53 +0000
Subject: [issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
In-Reply-To: <1297428909.69.0.247564466299.issue11186@psf.upfronthosting.co.za>
Message-ID: <1297429013.87.0.0532788337313.issue11186@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, my isUndecodableFilename() example is wrong. PEP 383 only uses U+DC80..U+DCFF range:

def isUndecodableFilename(filename):
  return any((0xDC80 <= ord(ch) <= 0xDCFF) for ch in filename)

Example of undecodable filename: b'bla\xe9\xff.py' with UTF-8 filesystem encoding is decoded as 'bla\uDCE9\uDCFF.py'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11186>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:04:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 13:04:11 +0000
Subject: [issue11187] PyUnicode_AsEncodedString: the bootstrap hack is no more
	needed
In-Reply-To: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>
Message-ID: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Since version 3.2, Python uses the locale encoding in PyUnicode_EncodeFSDefault() using _Py_wchar2char() and _Py_char2wchar() until the codec registry is initialized and the locale codec is loaded (until initfsencoding() is done).

Before Python 3.2, Python used ASCII in PyUnicode_AsEncodedString() at bootstrap  (before the codec registry was initialized): we don't need this hack anymore and it is bad to use ASCII instead of the locale encoding (encode/decode can fail).

This ticket is just a reminder for me: I am waiting Python 3.3 to remove PyUnicode_AsEncodedString() bootstrap hack ;-)

----------
components: Interpreter Core
files: unicode_asencodedstring_bootstrap.patch
keywords: patch
messages: 128384
nosy: haypo
priority: normal
severity: normal
status: open
title: PyUnicode_AsEncodedString: the bootstrap hack is no more needed
versions: Python 3.3
Added file: http://bugs.python.org/file20744/unicode_asencodedstring_bootstrap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11187>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:04:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 13:04:15 +0000
Subject: [issue11187] PyUnicode_AsEncodedString: the bootstrap hack is no more
	needed
In-Reply-To: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>
Message-ID: <1297429455.54.0.414698176868.issue11187@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11187>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:16:18 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 13:16:18 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297430178.8.0.0619021232328.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK, so the following patch should help:

Index: configure.in
===================================================================
--- configure.in        (revision 88393)
+++ configure.in        (working copy)
@@ -1375,6 +1375,8 @@
 
 if test "$use_lfs" = "yes"; then
 # Two defines needed to enable largefile support on various platforms
+AC_DEFINE(_LARGEFILES, 1, 
+[This must be defined on some systems to enable large file support.])
 # These may affect some typedefs
 AC_DEFINE(_LARGEFILE_SOURCE, 1, 
 [This must be defined on some systems to enable large file support.])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:39:39 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 13:39:39 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297431579.63.0.759229244641.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

the error is different now that _LARGEFILES is defined:

======================================================================
ERROR: test_large_file_ops (__main__.CIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
IOError: [Errno 22] Invalid argument

======================================================================
ERROR: test_large_file_ops (__main__.PyIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 321, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
IOError: [Errno 22] Invalid argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 14:53:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 13:53:46 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297432426.64.0.525206451636.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, interesting. Can you post the results of the two following snippets:

>>> f = open('foo', 'wb')
>>> f.seek(2**32)
# should be 4294967296

>>> f = open('foo', 'wb')
>>> f.truncate(2**32)
# should be 4294967296

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:06:01 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:06:01 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297433161.97.0.782703989635.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Sorry I made a mistake in my previous patch (_LARGEFILES instead of _LARGE_FILES).

Here is a better one:

Index: configure.in
===================================================================
--- configure.in	(r?vision 88395)
+++ configure.in	(copie de travail)
@@ -1376,6 +1376,14 @@
 if test "$use_lfs" = "yes"; then
 # Two defines needed to enable largefile support on various platforms
 # These may affect some typedefs
+    case $ac_sys_system/$ac_sys_release in
+    AIX*)
+        AC_DEFINE(_LARGE_FILES, 1, 
+        [This must be defined on AIX systems to enable large file support.])
+	;;
+    *)
+        ;;
+    esac
 AC_DEFINE(_LARGEFILE_SOURCE, 1, 
 [This must be defined on some systems to enable large file support.])
 AC_DEFINE(_FILE_OFFSET_BITS, 64,

The test fails in a different way now:


======================================================================
ERROR: test_large_file_ops (__main__.CIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 323, in large_file_ops
    self.assertEqual(f.write(b"xxx"), 3)
IOError: [Errno 27] File too large

======================================================================
ERROR: test_large_file_ops (__main__.PyIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_io.py", line 418, in test_large_file_ops
    self.large_file_ops(f)
  File "./Lib/test/test_io.py", line 323, in large_file_ops
    self.assertEqual(f.write(b"xxx"), 3)
IOError: [Errno 27] File too large

----------------------------------------------------------------------
Ran 395 tests in 27.958s


Here is your trace:
phenix:~/.buildbot/python-aix6/3.x.phenix.xlc/build\> ./python 
Python 3.2rc2+ (py3k:88393M, Feb 11 2011, 14:56:34) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('foo', 'wb')
[55983 refs]
>>> f.seek(2**32)
4294967296
[55987 refs]
>>> f = open('foo', 'wb')
__main__:1: ResourceWarning: unclosed file <_io.BufferedWriter name='foo'>
[55994 refs]
>>> f.truncate(2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 27] File too large
[56027 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:17:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 14:17:17 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297433837.27.0.983572823255.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The finally was doing a _sync_close, which flushes the tmp file and closes it.  The except Exception is checking if any non-BaseException error occurs, *removing* the tmp file, and re-raising the exception.  There's nothing to flush/close in that case.  Then, the else: clause of the exception deals with doing the _sync_close if, eg, we had a keyboard interrupt.  That may or may not leave the mailbox in a sensible state, but it is no worse than the previous behavior.  Certainly for any non-BaseException exception the new code is better; previously you'd most likely wind up with an empty or partially written message tmp file.  I'm open to changing to BaseException, though, if you think that would be better (I can see the argument for that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:19:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 14:19:43 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297433161.97.0.782703989635.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297433977.3693.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch.

> The test fails in a different way now:
> [...]
> IOError: [Errno 27] File too large

This seems to mean that your file system isn't configured for large
files. According to
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/prg_lrg_files.htm :

        For the JFS, the maximum file size is determined by the
        parameters used at the time the file system was made. For JFS
        file systems that are enabled for large files, the maximum file
        size is slightly less than 64 gigabytes (0xff8400000). For all
        other JFS file systems, the maximum file size is 2Gb-1
        (0x7fffffff). Attempts to write a file in excess of the maximum
        file size in any file system format will fail, and errno will be
        set to EFBIG.

(I'm not under AIX, but EFBIG is 27 here)

What does test_largefile output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:30:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:30:10 +0000
Subject: [issue11184] test_io error on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297434610.22.0.184973052763.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

test_largefile complains about the filesystem having no largefile support.
It is probably the case, I will ask a sysadmin, and see if he can get me a file system with large file support so that I can test this feature.


> ./python -Wd -E -bb ./Lib/test/test_largefile.py 
Traceback (most recent call last):
  File "./Lib/test/test_largefile.py", line 163, in test_main
    f.write(b'x')
IOError: [Errno 27] File too large

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./Lib/test/test_largefile.py", line 192, in <module>
    test_main()
  File "./Lib/test/test_largefile.py", line 168, in test_main
    raise unittest.SkipTest("filesystem does not have largefile support")
unittest.case.SkipTest: filesystem does not have largefile support
[81125 refs]

In the meantime, this test should probably be skipped just like in test_largefile.py and the patch with _LARGE_FILES should probably be applied too.

Merci pour l'aide

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:31:28 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:31:28 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297434688.65.0.836804568494.issue11184@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
title: test_io error on AIX -> Broken large file support on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:36:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 14:36:29 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297434989.45.0.0598674233619.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, I think the skipping code in test_largefile should be factored out and used both in test_io and test_largefile (to be honest I don't know why test_io has large file tests as well; perhaps I should merge them together).

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:37:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 14:37:29 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297435049.12.0.586350050231.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Duh.  After writing all that you'd think I'd have seen my mistake.  That's what reviews are for.  So I guess it should be BaseException, since the most likely one is keyboard interrupt and this would prevent a corrupted mailbox in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:40:13 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:40:13 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297435213.96.0.900431622589.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Also:

is it OK if I open a new issue for each broken unit test on AIX even if I have not investigated them at the moment?

I have a dozen broken unit tests on AIX that need to be investigated, but I don't want to spam the bug tracker followers too much.
So tell me if it is a good thing to report each problem as soon as possible or if I should do it step by step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:46:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 14:46:07 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297435213.96.0.900431622589.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297435563.3693.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> is it OK if I open a new issue for each broken unit test on AIX even
> if I have not investigated them at the moment?

Yes. That way they get recorded somewhere and other people can chime in.
If you plan to investigate them you can add a sentence saying so.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:51:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:51:10 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following errors on test_time on AIX:

======================================================================
ERROR: test_mktime (test.test_time.TestAsctime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (test.test_time.Test4dyearBool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
FAIL: test_negative (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_time.py", line 337, in test_negative
    self.assertIn(text, ('-1', '-001'))
AssertionError: '000/' not found in ('-1', '-001')

----------------------------------------------------------------------
Ran 42 tests in 1.217s

FAILED (failures=1, errors=3)

Haven't investigated yet.

----------
messages: 128396
nosy: sable
priority: normal
severity: normal
status: open
title: test_time error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:57:25 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:57:25 +0000
Subject: [issue11189] test_resource error on AIX
In-Reply-To: <1297436245.22.0.679544403008.issue11189@psf.upfronthosting.co.za>
Message-ID: <1297436245.22.0.679544403008.issue11189@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error on test_resource on AIX:

test_resource
test test_resource failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_resource.py", line 28, in test_fsize_ismax
    self.assertEqual(resource.RLIM_INFINITY, max)
AssertionError: 2147483647 != 1073741312

I haven't investigated yet.

----------
messages: 128397
nosy: sable
priority: normal
severity: normal
status: open
title: test_resource error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11189>
_______________________________________

From report at bugs.python.org  Fri Feb 11 15:59:01 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 14:59:01 +0000
Subject: [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following errors on test_locale on AIX:

======================================================================
FAIL: test_strcoll_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_locale.py", line 364, in test_strcoll_with_diacritic
    self.assertLess(locale.strcoll('?', 'b'), 0)
AssertionError: 1 not less than 0

======================================================================
FAIL: test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_locale.py", line 367, in test_strxfrm_with_diacritic
    self.assertLess(locale.strxfrm('?'), locale.strxfrm('b'))
AssertionError: '\u01e2\u0100' not less than '\u0164\u0100'

----------------------------------------------------------------------
Ran 35 tests in 0.020s

FAILED (failures=2)

I haven't investigated yet.

----------
messages: 128398
nosy: sable
priority: normal
severity: normal
status: open
title: test_locale error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11190>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:02:16 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:02:16 +0000
Subject: [issue11191] test_search_cpp error on AIX (aith xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error in distutils on AIX.

======================================================================
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/unixccompiler.py", line 166, in preprocess
    self.spawn(pp_args)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/ccompiler.py", line 911, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'xlc' failed with exit status 40

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/tests/test_config_cmd.py", line 47, in test_search_cpp
    match = cmd.search_cpp(pattern='xxx', body='// xxx')
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/command/config.py", line 203, in search_cpp
    src, out = self._preprocess(body, headers, include_dirs, lang)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/command/config.py", line 126, in _preprocess
    self.compiler.preprocess(src, out, include_dirs=include_dirs)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/distutils/unixccompiler.py", line 168, in preprocess
    raise CompileError(msg)
distutils.errors.CompileError: command 'xlc' failed with exit status 40

I haven't investigated yet.

----------
assignee: tarek
components: Distutils
messages: 128399
nosy: eric.araujo, sable, tarek
priority: normal
severity: normal
status: open
title: test_search_cpp error on AIX (aith xlc)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:02:23 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:02:23 +0000
Subject: [issue11191] test_search_cpp error on AIX (with xlc)
In-Reply-To: <1297436536.39.0.921212376741.issue11191@psf.upfronthosting.co.za>
Message-ID: <1297436543.73.0.60792067897.issue11191@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
title: test_search_cpp error on AIX (aith xlc) -> test_search_cpp error on AIX (with xlc)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11191>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:05:51 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:05:51 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error in test_socket on AIX:

======================================================================
FAIL: testGetaddrinfo (__main__.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 640, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 0 != 1

----------------------------------------------------------------------
Ran 158 tests in 16.904s

FAILED (failures=1, skipped=4)
Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 2012, in <module>
    test_main()
  File "./Lib/test/test_socket.py", line 2008, in test_main
    support.run_unittest(*tests)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1145, in run_unittest
    _run_suite(suite)
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/support.py", line 1128, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_socket.py", line 640, in testGetaddrinfo
    self.assertEqual(socktype, socket.SOCK_STREAM)
AssertionError: 0 != 1

[119732 refs]

I haven't investigated yet.

----------
messages: 128400
nosy: sable
priority: normal
severity: normal
status: open
title: test_socket error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:09:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 15:09:11 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1297436952.0.0.606131841156.issue11192@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:12:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:12:21 +0000
Subject: [issue11189] test_resource error on AIX
In-Reply-To: <1297436245.22.0.679544403008.issue11189@psf.upfronthosting.co.za>
Message-ID: <1297437141.68.0.404733713394.issue11189@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

This is a duplicate of issue 678264.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11189>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:28:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 11 Feb 2011 15:28:21 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

The following tests fail in test_subprocess on AIX:

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_subprocess.py", line 1039, in test_undecodable_env
    self.assertEqual(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


======================================================================
FAIL: test_undecodable_env (test.test_subprocess.ProcessTestCasePOSIXPurePython)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_subprocess.py", line 1039, in test_undecodable_env
    self.assertEqual(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^


----------------------------------------------------------------------
Ran 267 tests in 366.280s

FAILED (failures=2, skipped=22)

I haven't investigated yet.

----------
messages: 128402
nosy: sable
priority: normal
severity: normal
status: open
title: test_subprocess error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:41:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 15:41:05 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297438865.72.0.391858409011.issue11193@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps related to the test_locale failure in issue11190.

----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:43:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Feb 2011 15:43:06 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297438986.52.0.0928148035892.issue11188@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:43:45 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 15:43:45 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297439025.46.0.175412301819.issue9298@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yves: thanks for the patches.  If you feel like redoing the test one as a patch against Lib/email/test/test_email.py, that would be great.  I'd suggest having the test just split the lines and do

  assertLessEqual(max([len(x) for x in lines]), 76)

or something along those lines.

As for the fix, encoders used to use encodebytes, but it tacks on a trailing newline that, according to the old code (see r57800) is unwanted.  So perhaps we need to revert that part of r57800 instead.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Fri Feb 11 16:45:20 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Feb 2011 15:45:20 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1297439120.34.0.939815157173.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file20745/issue9920.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:01:28 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 16:01:28 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297440088.39.0.917162149099.issue11193@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_undecodable_code() in test_cmd_line had a similar issue: on FreeBSD, Solaris and Mac OS X, even if the locale is C (and nl_langinfo(CODESET) announces ASCII), _Py_char2wchar() (mbstowcs) decoded b'\xff' as '\xff' (use ISO-8859-1 encoding). To fix the test, I just patched the test to accept both results: b'\xff' may be decoded as '\udcff' or '\xff'.


test_undecodable_env does something like: os.environb[b'test']=b'abc\xff', but os.getenv() decodes b'abc\xff' as 'abc\xff' instead of 'abc\udcff' even if LC_ALL=C.

I don't understand why the test pass on FreeBSD, Solaris and Mac OS X, but not on AIX. It would be interesting to get the locale encoding of the child process using LC_ALL=C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:03:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Feb 2011 16:03:33 +0000
Subject: [issue11190] test_locale error on AIX
In-Reply-To: <1297436341.9.0.505195116072.issue11190@psf.upfronthosting.co.za>
Message-ID: <1297440213.89.0.30699869426.issue11190@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #11193 (another locale issue on AIX).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11190>
_______________________________________

From report at bugs.python.org  Fri Feb 11 17:06:20 2011
From: report at bugs.python.org (Andrew Dunbar)
Date: Fri, 11 Feb 2011 16:06:20 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1297440380.01.0.550729404486.issue1602@psf.upfronthosting.co.za>


Changes by Andrew Dunbar <hippytrail at gmail.com>:


----------
nosy: +hippietrail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:28:31 2011
From: report at bugs.python.org (Sascha Silbe)
Date: Fri, 11 Feb 2011 17:28:31 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1297445311.07.0.0494660914323.issue2504@psf.upfronthosting.co.za>


Changes by Sascha Silbe <sascha-web-bugs.python.org at silbe.org>:


----------
nosy: +sascha_silbe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:38:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 17:38:48 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297445928.59.0.246877034657.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Revised patch using BaseException.

----------
Added file: http://bugs.python.org/file20746/mailbox_cleanup2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:40:58 2011
From: report at bugs.python.org (O.C.)
Date: Fri, 11 Feb 2011 17:40:58 +0000
Subject: [issue11194] "lock.__exit__ == lock.release" should be False
In-Reply-To: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>
Message-ID: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>


New submission from O.C. <oc-spam66 at laposte.net>:

Hello,

if 'lock' is a threading.Lock, the functions lock.__exit__() and lock.release() are different. The former takes 3 arguments, while the latter takes no argument. However, "lock.__exit__ == lock.release" returns True. Shouldn't it return False ?

Best regards,

O.C.

Details:
In [20]: lock=threading.Lock()
In [21]: lock.acquire()
In [22]: lock.__exit__(None,None,None)
In [23]: lock.locked()
Out[23]: False
In [24]: lock.acquire()
In [25]: lock.release(None,None,None)
TypeError: release() takes no arguments (3 given)
In [26]: lock.__exit__==lock.release
Out[26]: True

----------
components: Library (Lib)
messages: 128409
nosy: dghjfrdj
priority: normal
severity: normal
status: open
title: "lock.__exit__ == lock.release" should be False
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11194>
_______________________________________

From report at bugs.python.org  Fri Feb 11 18:44:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Feb 2011 17:44:05 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1297446245.32.0.167890028602.issue1704474@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Sandro.  I think you may have closed too fast here: optparse is deprecated in docs only, it?s not the recommendation anymore, but IIUC bugs should still be fixed.  A year and a half is sadly not a very long time for a Python bug, time is usually not a criterion for closing.

David, please correct any inaccuracy in my message :)

----------
nosy: +eric.araujo, r.david.murray -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704474>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:01:24 2011
From: report at bugs.python.org (SilentGhost)
Date: Fri, 11 Feb 2011 18:01:24 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297447284.54.0.578941038572.issue11116@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

compileall.rst diff doesn't seem to belong in that patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:01:57 2011
From: report at bugs.python.org (Daniele Varrazzo)
Date: Fri, 11 Feb 2011 18:01:57 +0000
Subject: [issue11195] next fixer fooled by trailing cheracters
In-Reply-To: <1297447317.1.0.237374543357.issue11195@psf.upfronthosting.co.za>
Message-ID: <1297447317.1.0.237374543357.issue11195@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo <piro at develer.com>:

An expression such as "x = i.next()[0]" is not fixed by 2to3 in Python 3.1. "x = (i.next())[0]" works instead.

https://github.com/dvarrazzo/psycopg/commit/9e9c22163706b0fffb9da67fe50ea23f91fe1c72

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128412
nosy: piro
priority: normal
severity: normal
status: open
title: next fixer fooled by trailing cheracters
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11195>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:08:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 18:08:30 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297447710.37.0.0564904125266.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops.  Thanks for catching that.  Will fix before commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:15:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 18:15:34 +0000
Subject: [issue11194] "lock.__exit__ == lock.release" should be False
In-Reply-To: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>
Message-ID: <1297448134.24.0.19441772611.issue11194@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, under the (C) hood, it is in fact the same method, it just takes a variable number of arguments (and ignores them, in the __exit__ case).  The fact that the arguments are rejected in the 'release' case is because of how the C function is defined as a Python method using the C API.  So the result of the boolean test is more accurate than a False report would be, although not precise.  

I don't *think* there is any bug to fix here.  Do you have a use case that this impacts?

----------
nosy: +r.david.murray
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11194>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:29:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 18:29:15 +0000
Subject: [issue1704474] optparse tests fail under Jython
Message-ID: <1297448955.08.0.537335726678.issue1704474@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Making the tests pass on Jython is certainly worthwhile, if anyone wants to do it.  At a quick glance it looks like the optparse tests just need to be updated and made a bit more lenient.  Since Jython is lagging CPython by so much a fix isn't going to help them for a quite a while even if it gets done now.

Really, this is a candidate bug to be moved to the library tracker if/when the CPython/library split happens.  So I suppose we should leave it open in anticipation of that move happening some day :)

----------
resolution: wont fix -> 
status: closed -> open
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1704474>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:31:23 2011
From: report at bugs.python.org (Geza)
Date: Fri, 11 Feb 2011 18:31:23 +0000
Subject: [issue11196] add possibility for returning value the way Matlab does
	it
In-Reply-To: <1297449083.34.0.083242555251.issue11196@psf.upfronthosting.co.za>
Message-ID: <1297449083.34.0.083242555251.issue11196@psf.upfronthosting.co.za>


New submission from Geza <kgeza7 at gmail.com>:

It would be nice if you could write a function like this (besides, of course, the current way):

def result=functionname(params):
  ...
  result=something

It would suffice for most functions, since you usually always return one type of value, and it can be very convenient in certain cases.
This is the way it is done e.g. in Matlab.

Advantages: 
- You can easily see what the function returns (e.g. by writing a tuple as the return value), without having to read the function body, or without hoping to find it in the comments.
- You can initialize the return values, and then care about the cases where they change.
- If you change the setup of the return value (e.g. insert a new item into the tuple), you do not need to change the "return" statement at possibly several places in the function body.

Disadvantages:
- I suggest it as an addition, so there isn't really. One person may decide to use one way, one the other.
- Of course, if you mix using the two ways, you may need to look at the function header to see which one you used.

Some more details to the idea:
- The return values are initialized to None.
- You can use the "return" statement just as before, but without arguments, to return from anywhere in the code.
- If you specify arguments to the "return" statement, Python stops with an exception.

The idea at this stage of Python development may be surprising, but I hope that nevertheless you will consider the idea seriously.

Thanks, and best regard!

----------
components: Interpreter Core
messages: 128416
nosy: Geza
priority: normal
severity: normal
status: open
title: add possibility for returning value the way Matlab does it
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11196>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:33:47 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 11 Feb 2011 18:33:47 +0000
Subject: [issue11196] add possibility for returning value the way Matlab does
	it
In-Reply-To: <1297449083.34.0.083242555251.issue11196@psf.upfronthosting.co.za>
Message-ID: <1297449227.67.0.78186177214.issue11196@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

A change like this would need to go through, at the least, the python-ideas mailing list. Please submit your idea there first.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11196>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:37:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 18:37:49 +0000
Subject: [issue11195] next fixer fooled by trailing cheracters
In-Reply-To: <1297447317.1.0.237374543357.issue11195@psf.upfronthosting.co.za>
Message-ID: <1297449469.1.0.938346620584.issue11195@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11195>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:41:56 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 11 Feb 2011 18:41:56 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1297449716.33.0.54708037976.issue10423@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I've prepared a simple patch: what do you think about it?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:42:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 11 Feb 2011 18:42:21 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1297449741.6.0.648787010611.issue10423@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

now even with patch attached :)

----------
keywords: +patch
Added file: http://bugs.python.org/file20747/issue10423.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:46:11 2011
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Feb 2011 18:46:11 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

As reported to the PSRT:

Python's SimpleHTTPServer class is a simple HTTP server, documented as
serving up the content of the pwd and below readonly via GET and HEAD
commands:

 $ python -m SimpleHTTPServer
 Serving HTTP on 0.0.0.0 port 8000 ...

However, by inserting "../" path fragments within the path section of
the URL, it's possible to traverse other directories within the
filesystem.

For example:

 lynx localhost:8000/../../../../..

shows 5 directories above in the directory structure.

I was also able to browse /proc and /sys on this example using:

 lynx localhost:8000/../../../../../../../../proc
 lynx localhost:8000/../../../../../../../../sys

(by browsing to find the correct number of ".." entries to locate the
root directory); arguable this could be leaking much more information
about the host than the administrator might be expecting (e.g. other
programs being executed on the host, command-line arguments of those
programs etc)

This has been fixed in CGIHTTPServer; see
 http://bugs.python.org/issue2254
and:
 http://svn.python.org/view?view=rev&revision=71303

Guido recommended to not make this secret since no one should be using SimpleHTTPServer in production. He also said this should get fixed.

----------
components: Library (Lib)
messages: 128420
nosy: barry, benjamin.peterson, brett.cannon, dmalcolm, georg.brandl, gps
priority: release blocker
severity: normal
stage: needs patch
status: open
title: information leakage with SimpleHTTPServer
type: security
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:51:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Feb 2011 18:51:11 +0000
Subject: [issue11169] compileall doesn't support PEP 383 (undecodable
	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <1297450271.43.0.812627156684.issue11169@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree that quotes help debugging, so +1 for repr (or !r, not sure which ones reads better).  Not sure this can make it into stable branches.

----------
nosy: +eric.araujo
title: compileall doesn't support the PEP 383 (undecodable paths/filenames) -> compileall doesn't support PEP 383 (undecodable paths/filenames)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11169>
_______________________________________

From report at bugs.python.org  Fri Feb 11 19:53:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Feb 2011 18:53:18 +0000
Subject: [issue11164] xml shouldn't use _xmlplus
In-Reply-To: <1297289428.65.0.494861041692.issue11164@psf.upfronthosting.co.za>
Message-ID: <1297450398.82.0.218202020633.issue11164@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11164>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:29:07 2011
From: report at bugs.python.org (muxum)
Date: Fri, 11 Feb 2011 19:29:07 +0000
Subject: [issue11198] re sub subn backreferrence too few replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>


New submission from muxum <mxgnone at gmx.de>:

#download/try this: http://ideone.com/QA6Fg

from re import *
 
s = 'a->b\na->b\nc->b\nc->b\na->d\na->d\ne->b\ne->b\na->f\na->f\ng->b\ng->b\na->h\na->h\ni->b\ni->b\na->j\na->j\nk->b\nk->b\n'
res = subn(r"(.*\n)(\1)+",r"replaced:\1",s,M)
 
print("output: " + res[0])
print("replace count: %d" % res[1])
 
# if it works right the next print wont show
if res[1] == 8: print("WEIRD: too few replacements ("+str(res[1])+")")

#i'd expect this to replace all ocurrences not only the first 8 times

----------
components: Regular Expressions
messages: 128422
nosy: muxum
priority: normal
severity: normal
status: open
title: re sub subn backreferrence too few replacements
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11198>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:36:58 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 11 Feb 2011 19:36:58 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297453018.3.0.968217703245.issue11197@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

CVE-2011-0705

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:42:45 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 11 Feb 2011 19:42:45 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297453365.83.0.758601633839.issue11197@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:49:21 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Feb 2011 19:49:21 +0000
Subject: [issue11126] Wave.py does not always write proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1297453761.98.0.929809281413.issue11126@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that the _sampwidth multiplier is needed regardless of endianness.

The simplest option would be to pull the _datawritten statement out of the alternation, making the code read

        if self._sampwidth > 1 and big_endian:
            import array
            data = array.array(_array_fmts[self._sampwidth], data)
            data.byteswap()
            data.tofile(self._file)
        else:
            self._file.write(data)
        self._datawritten = self._datawritten + len(data) * self._sampwidth

Note: while _sampwidth is initialized to 0, _ensure_header_written() checks that it is not 0, and it is used elsewhere as a divisor.

The above adds a usually unneeded multiply by 1, but the alternative requires duplication of _file.write and two _datawritten statements

        if self._sampwidth > 1:
            if big_endian:
                import array
                data = array.array(_array_fmts[self._sampwidth], data)
                data.byteswap()
                data.tofile(self._file)
            else: # little_endian
                self._file.write(data)
            self._datawritten = self._datawritten + len(data) * self._sampwidth
        else: # _sampwidth == 1
            self._file.write(data)
            self._datawritten = self._datawritten + len(data)

This module is new to me. Can you think of any way to test this issue, perhaps by writing to StringIO file? This is not a heavily tested module ;-)

In 3.3, the openfp synonym for open could perhaps be deprecated.

----------
nosy: +terry.reedy
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11126>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:51:50 2011
From: report at bugs.python.org (O.C.)
Date: Fri, 11 Feb 2011 19:51:50 +0000
Subject: [issue11194] "lock.__exit__ == lock.release" should be False
In-Reply-To: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>
Message-ID: <1297453910.66.0.862245255526.issue11194@psf.upfronthosting.co.za>


O.C. <oc-spam66 at laposte.net> added the comment:

> Do you have a use case that this impacts?

No, I can live with it. It was rather a point about clarity and consistency. For example, the difference between Lock and RLock:
lock.__exit__==lock.release    -> True
rlock.__exit__==rlock.release  -> False

We came on that topic when using 'with' statements with exceptions and 'returns'. I wanted to check and understand the details, and I was confused by the fact that:
- three arguments will be given to lock.__exit__()
- lock.__exit__ is "the same" as lock.release
- lock.release takes no argument

These propositions are all true, but seem contradictory. The meaning of "the same" is not obvious in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11194>
_______________________________________

From report at bugs.python.org  Fri Feb 11 20:56:07 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Feb 2011 19:56:07 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297454167.34.0.400540754716.issue11188@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:01:23 2011
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 11 Feb 2011 20:01:23 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1297454483.97.0.199321921764.issue10423@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me. This is a doc fix, so it could go into 3.2 and 2.7 as well as 3.3.

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:48:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 11 Feb 2011 20:48:10 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297457290.59.0.48418362198.issue11135@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thansk for the review. Committed as r88400.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11135>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:50:57 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 11 Feb 2011 20:50:57 +0000
Subject: [issue11134] Add missing type slots
In-Reply-To: <1297021909.5.0.150607116867.issue11134@psf.upfronthosting.co.za>
Message-ID: <1297457457.4.0.507336996344.issue11134@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the review. Committed as r88401.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11134>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:51:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Feb 2011 20:51:14 +0000
Subject: [issue11182] pydoc.Scanner class not used by anything
In-Reply-To: <1297405755.94.0.782663220355.issue11182@psf.upfronthosting.co.za>
Message-ID: <1297457474.86.0.623226515534.issue11182@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After saying that pydoc is used by help(), its documentation only tells how to run it standalone. 

help(pydoc) basically says the same, and does not mention any internals, because of "__all__ = ['help']", which the author understood to define the public interface.

So it seems to me that everything other than help() can be considered private and changeable. Scanner does look like a leftover orphan.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11182>
_______________________________________

From report at bugs.python.org  Fri Feb 11 21:59:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Feb 2011 20:59:54 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297457994.53.0.669714175714.issue11180@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I've attached benchmarking code for all three approaches (the current approach and the two proposals).

----------
Added file: http://bugs.python.org/file20748/heapq_benchmark.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Fri Feb 11 22:57:55 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 21:57:55 +0000
Subject: [issue11194] "lock.__exit__ == lock.release" should be False
In-Reply-To: <1297446058.01.0.111688615333.issue11194@psf.upfronthosting.co.za>
Message-ID: <1297461475.57.0.0353700053858.issue11194@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, sometimes you just have to read the source.

Previous to Python3.2, RLock was implemented in Python, and the two methods are actually different methods there.  In Python3.2, rlock.release == rlock.__exit__ is True.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11194>
_______________________________________

From report at bugs.python.org  Fri Feb 11 23:48:35 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 22:48:35 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297464515.3.0.134629215155.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r88403.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Sat Feb 12 00:04:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Feb 2011 23:04:47 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297465487.98.0.866252513341.issue11116@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Decided to backport the fix to 2.7, even though the tests won't backport.  r88406.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Sat Feb 12 00:56:07 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 11 Feb 2011 23:56:07 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297468567.53.0.0112940286944.issue11171@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: tarek -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sat Feb 12 01:30:58 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 12 Feb 2011 00:30:58 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297470658.26.0.94811594689.issue11171@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The suggested change works for me, both when prefix == exec_prefix and when it doesn't.  All standard tests pass, so the fix should be committed.  I'm holding off on doing that to see whether it's applicable to other versions, though if 3.2 is affected, Georg will have to pronounce on the patch.  (My opinion is that it can easily wait for 3.2.1).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:37:08 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Feb 2011 02:37:08 +0000
Subject: [issue11198] re sub subn backreferrence too few replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297478228.19.0.860261161717.issue11198@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11198>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:52:47 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 12 Feb 2011 02:52:47 +0000
Subject: [issue11198] re sub subn backreferrence too few replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297479167.29.0.317899228792.issue11198@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Argument 4 of re.subn(...) is 'count', the maximum number of replacements to perform, but you're passing in the MULTILINE flag, which happens to have the integer value 8, hence you're limiting the maximum number of replacements to 8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11198>
_______________________________________

From report at bugs.python.org  Sat Feb 12 03:55:22 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Feb 2011 02:55:22 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297479322.7.0.247516533957.issue11197@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Feb 12 04:00:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Feb 2011 03:00:01 +0000
Subject: [issue11198] re sub subn backreferrence too few replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297479601.81.0.622032214947.issue11198@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11198>
_______________________________________

From report at bugs.python.org  Sat Feb 12 06:46:21 2011
From: report at bugs.python.org (Michal Nowikowski)
Date: Sat, 12 Feb 2011 05:46:21 +0000
Subject: [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1297489581.5.0.590943529861.issue10999@psf.upfronthosting.co.za>


Michal Nowikowski <godfryd at gmail.com> added the comment:

Is this patch ok?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:23:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Feb 2011 07:23:03 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297495383.91.0.0670025403404.issue11171@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That is my opinion as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:25:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Feb 2011 07:25:53 +0000
Subject: [issue11116] mailbox and email errors
In-Reply-To: <1296815988.0.0.805444909469.issue11116@psf.upfronthosting.co.za>
Message-ID: <1297495553.97.0.154661555865.issue11116@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11116>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:31:31 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Feb 2011 07:31:31 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297495891.82.0.30378896822.issue11197@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This would be nice to fix in 3.2; however, since SimpleHTTPServer is not meant to be used in production, and it's not a regression, I will not hold up the release schedule for it.  I'd need to see a patch for deciding.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:33:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Feb 2011 07:33:55 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1297496035.96.0.926310206863.issue11082@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Lowering priority and making a doc issue now that the code change has been made.

----------
components: +Documentation -Library (Lib)
priority: deferred blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:55:56 2011
From: report at bugs.python.org (Michael Strein)
Date: Sat, 12 Feb 2011 07:55:56 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1297497356.41.0.196847385597.issue1028@psf.upfronthosting.co.za>


Michael Strein <mgstrein at gmail.com> added the comment:

Do we know the status of this issue? Have not seen update in four months. Currently is a major headache on my linux box.

----------
nosy: +mgstrein

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Feb 12 08:57:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Feb 2011 07:57:39 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1297497459.61.0.18850849528.issue1028@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: kbk -> ned.deily
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:19:01 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 12 Feb 2011 08:19:01 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1297498741.18.0.059791697217.issue4709@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:28:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2011 08:28:33 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297499313.87.0.691296426577.issue11180@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Updated the benchmarking code to include a 4th variant that accumulates sorted sublists during the partitioning phase.

Results from one run:

n: 100000	k: 100
[105856, 105917, 105951, 105977, 106366] nsmallest
[166465, 166478, 166507, 166639, 166748] heapifying_smallest
[253705, 260410, 264225, 289600, 333626] selecting_smallest
[111048, 117112, 144633, 168109, 402758] partitioning_smallest

----------
Added file: http://bugs.python.org/file20749/heapq_benchmark.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Sat Feb 12 09:28:41 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Feb 2011 08:28:41 +0000
Subject: [issue11180] More efficient nlargest()/nsmallest()
In-Reply-To: <1297386956.44.0.637022416635.issue11180@psf.upfronthosting.co.za>
Message-ID: <1297499321.85.0.643188994624.issue11180@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20748/heapq_benchmark.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11180>
_______________________________________

From report at bugs.python.org  Sat Feb 12 12:53:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 11:53:45 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297511625.8.0.0388530109497.issue11149@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a potential crasher.
It would also be nice if you listed those cases where Python assumes signed overflow behaviour. Can you open a separate issue for that?

----------
nosy: +mark.dickinson, pitrou
priority: normal -> high
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11149>
_______________________________________

From report at bugs.python.org  Sat Feb 12 14:00:05 2011
From: report at bugs.python.org (rg3)
Date: Sat, 12 Feb 2011 13:00:05 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>


New submission from rg3 <sarbalap+freshmeat at gmail.com>:

If you run the attached program, you can see the program hangs in the connection close stage. Uncommenting the sleep line makes the program work, so I suspect some kind of race condition.

The URL used belongs to a Slackware Linux mirror. I have not been able to reproduce this problem when using a different FTP mirror or using HTTP mirrors. 

The remote server seems to be using pure-ftpd. I have built the software and tested on localhost, but I could not reproduce the problem either.

----------
components: Extension Modules
files: test.py
messages: 128444
nosy: rg3
priority: normal
severity: normal
status: open
title: urllib hangs when closing connection
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20750/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Sat Feb 12 15:19:32 2011
From: report at bugs.python.org (muxum)
Date: Sat, 12 Feb 2011 14:19:32 +0000
Subject: [issue11198] re sub subn backreferrence too few replacements
In-Reply-To: <1297452547.69.0.971183972049.issue11198@psf.upfronthosting.co.za>
Message-ID: <1297520372.67.0.547452334008.issue11198@psf.upfronthosting.co.za>


muxum <mxgnone at gmx.de> added the comment:

aww ic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11198>
_______________________________________

From report at bugs.python.org  Sat Feb 12 16:38:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Feb 2011 15:38:20 +0000
Subject: [issue10999] os.chflags refers to stat constants,
	but the constants are not documented in the stat module
In-Reply-To: <1295898075.1.0.406467023745.issue10999@psf.upfronthosting.co.za>
Message-ID: <1297525100.33.0.987113433305.issue10999@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks good to me.

I wonder if the existing example should be moved up above the description of the chmod flags, though.  This update puts it even farther away from the functions it is an example of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10999>
_______________________________________

From report at bugs.python.org  Sat Feb 12 17:06:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2011 16:06:10 +0000
Subject: [issue3119] pickle.py is limited by python's call stack
In-Reply-To: <1213589185.62.0.660916672679.issue3119@psf.upfronthosting.co.za>
Message-ID: <1297526770.36.0.674590701572.issue3119@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: eliminate recursion in pickling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3119>
_______________________________________

From report at bugs.python.org  Sat Feb 12 17:49:28 2011
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 12 Feb 2011 16:49:28 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297529368.68.0.768287532494.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> > 1. Make keys(), values(), items() methods return view object for ndbm, gdbm and dumb objects. I following the codes in dictobject.c.
> Did you have to copy the code?  Isn?t it possible to somehow reuse it?

I feel not so easy to reuse the code, there could be several differences in the c code. Resuing the code may make the code more complecated. But if someone could find a better way to reuse the code, it would be nice.


> > The keysview object support len(), "in" operator, and iteratable, while valuesview and itemsview object only support len() and iteratable.
> That does not seem to comply with the definition of dict views. 

Oh, yes, I missed the rich compare functions and isdisjoint() method of view objects.


> Do the views yield elements in the same order?  (In a dict, iteration order is undefined but consistent between the various views, IIUC.)
gdbm and dumb views yield elements in the same order, ndbm views doesn't. I missed it.


> > 3. Remove dumb's keys() method which calls self._index.keys() since it is unnecessary.
> Does dumb have no keys method then?
Yes, it does. Its keys() method is provided by Mapping abc already.


Here is the updated patch:
1. Add rich compare functions and disjoint() method to dbm view objects to make them as MappingView objects, and add abc registration for them.
2. Make ndbm view objects yield elements in the same order.
3. Other changes during to the codeview: http://codereview.appspot.com/4185044/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Sat Feb 12 17:49:50 2011
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 12 Feb 2011 16:49:50 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297529390.04.0.0816232720227.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Added file: http://bugs.python.org/file20751/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:28:07 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sat, 12 Feb 2011 18:28:07 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>


New submission from Toshio Kuratomi <a.badger at gmail.com>:

When trying to build distribute on the latest python-3.2rc I get the following traceback in the unittests (two others that are similar as well):

======================================================================
ERROR: test_develop (setuptools.tests.test_develop.TestDevelopTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.2/distutils/util.py", line 283, in subst_vars
    return re.sub(r'\$([a-zA-Z_][a-zA-Z_0-9]*)', _subst, s)
  File "/usr/lib/python3.2/re.py", line 167, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/usr/lib/python3.2/distutils/util.py", line 280, in _subst
    return os.environ[var_name]
  File "/usr/lib/python3.2/os.py", line 450, in __getitem__
    value = self._data[self.encodekey(key)]
KeyError: b'abiflags'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "build/src/setuptools/tests/test_develop.py", line 52, in test_develop
    cmd.ensure_finalized()
  File "/usr/lib/python3.2/distutils/cmd.py", line 109, in ensure_finalized
    self.finalize_options()
  File "build/src/setuptools/command/develop.py", line 51, in finalize_options
    easy_install.finalize_options(self)
  File "build/src/setuptools/command/easy_install.py", line 225, in finalize_options
    self.expand_dirs()
  File "build/src/setuptools/command/easy_install.py", line 335, in expand_dirs
    'install_scripts', 'install_data',])
  File "build/src/setuptools/command/easy_install.py", line 323, in _expand_attrs
    val = subst_vars(val, self.config_vars)
  File "/usr/lib/python3.2/distutils/util.py", line 285, in subst_vars
    raise ValueError("invalid variable '$%s'" % var)
ValueError: invalid variable '$b'abiflags''

It seems that something in the addition of abiflags is causing distutils to search for abiflags in os.environ.  After talking with tarek on IRC we decided to open a bug here to see whether this is desirable change in behaviour within the stdlib.

The revision introducing abiflags is here: http://svn.python.org/view?view=rev&revision=85697

----------
components: Library (Lib)
messages: 128448
nosy: a.badger, barry, doko, tarek
priority: normal
severity: normal
status: open
title: Addition of abiflags breaks distutils
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:40:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 18:40:03 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1297536003.72.0.926179725955.issue11200@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:41:23 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 12 Feb 2011 18:41:23 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1297536083.15.0.857457033109.issue11200@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:47:18 2011
From: report at bugs.python.org (Ana Koren)
Date: Sat, 12 Feb 2011 18:47:18 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>


New submission from Ana Koren <ana.koren at gmail.com>:

I'm running Windows 7 (32-bit) and I downloaded Python 2.7.1 Windows Installer but I can't install it. I get this message:
"The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2203."

----------
messages: 128449
nosy: corenova
priority: normal
severity: normal
status: open
title: Python installation error 2203
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:51:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 18:51:51 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1297536711.8.0.300359136503.issue11200@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, looks like distribute should be updated to include "abiflags" in self.config_vars in setuptools/command/easy_install.py. There seems to be a whole bunch of code pasted directly from distutils and it isn't up-to-date anymore. Compare:
https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/easy_install.py#cl-195
with:
http://code.python.org/hg/branches/py3k/file/9b1daa80168d/Lib/distutils/command/install.py#l321

This bug probably needs to be reported to the distribute issue tracker instead. Tarek, ?ric, can you proceed?

----------
assignee:  -> tarek
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:52:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 18:52:56 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297536776.63.0.562297422909.issue11201@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:53:34 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Feb 2011 18:53:34 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297536814.04.0.436601150848.issue11201@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you confirm that the checksum and size of the file you downloaded matches what's on the site: http://www.python.org/download/releases/2.7.1/

----------
components: +Windows
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:54:56 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 18:54:56 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>


New submission from Anders ?sthus <grapz666 at gmail.com>:

Hi

I'm running Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32 (Server 2008 R2).

I've discovered that when moving files with shutil.move, the file won't inherit the security settings as it should.

When using shutil.copy, it does get the right permissions.

----------
components: IO
messages: 128452
nosy: Anders.?sthus
priority: normal
severity: normal
status: open
title: Win32: shutil.move does not inherit permissions
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:56:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 18:56:01 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297536961.01.0.988743553054.issue11202@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -IO
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:56:49 2011
From: report at bugs.python.org (Ana Koren)
Date: Sat, 12 Feb 2011 18:56:49 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297537009.37.0.349412209994.issue11201@psf.upfronthosting.co.za>


Ana Koren <ana.koren at gmail.com> added the comment:

Yes, I downloaded it from there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:58:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 18:58:43 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297537123.04.0.465848685013.issue11202@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Intuitively, this seems rather normal to me. If I move a file under Unix, I don't expect its access rights or ownership to change. "Move" really means what it means: you have to update its permission explicitly if that's what you need (shutil.copystat() can help you with that, I think).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 19:59:58 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Feb 2011 18:59:58 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297537198.79.0.123155571041.issue11202@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

shutil.move is implemented using copy2, which as the documentation states at the top, "On Windows, file owners, ACLs and alternate data streams are not copied."

See http://docs.python.org/library/shutil

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:10:42 2011
From: report at bugs.python.org (corenova)
Date: Sat, 12 Feb 2011 19:10:42 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297537842.82.0.43496223493.issue11201@psf.upfronthosting.co.za>


corenova <ana.koren at gmail.com> added the comment:

I get the same message when trying to install older versions (2.x) as well as new 3.1.3
I also tried ActivePython and same thing happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:11:17 2011
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Feb 2011 19:11:17 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297537877.22.0.709973782336.issue11202@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:12:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 12 Feb 2011 19:12:28 +0000
Subject: [issue11201] Python installation error 2203
In-Reply-To: <1297536438.88.0.367052645328.issue11201@psf.upfronthosting.co.za>
Message-ID: <1297537948.02.0.567174468362.issue11201@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are you perhaps trying to run the installer from a network folder, or some other location that needs your personal credentials for access?

Please run

   msiexec /i python-2.7.1.msi /l*v python.log

and attach the resulting python.log to this report (compress if it's too large).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11201>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:32:31 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Sat, 12 Feb 2011 19:32:31 +0000
Subject: [issue3860] GzipFile and BZ2File should support context manager
	protocol
In-Reply-To: <1221334142.89.0.958146775419.issue3860@psf.upfronthosting.co.za>
Message-ID: <1297539151.53.0.823466045015.issue3860@psf.upfronthosting.co.za>


K Richard Pixley <rich at noir.com> added the comment:

Documentation needs to be updated to state that these are now context managers.  This is important since they aren't in python-2.x.

I'm not sure whether this should be added to the "new in python" blurbs.

----------
nosy: +teamnoir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3860>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:36:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 12 Feb 2011 19:36:18 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1297539378.32.0.0271916571431.issue10084@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Initial draft of a patch including tests and a new ssl_dispatcher subclass.
asynchat needs to be changed as well, probably by using a mixin class.

----------
keywords: +patch
Added file: http://bugs.python.org/file20752/asyncore_ssl_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10084>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:40:32 2011
From: report at bugs.python.org (K Richard Pixley)
Date: Sat, 12 Feb 2011 19:40:32 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>


New submission from K Richard Pixley <rich at noir.com>:

The documentation for gzip should include the "close" method.

It's use in the 2.7 documentation implies it's existence but it should also be stated explicitly that it exists.

In the 3.x documentation, the use of "close" not in the examples since the examples use context manager.  For 3.x documentation there should be both an explicit mention of the "close" method as well as an explicit mention that GzipFile supports the context manager protocol.

Yes, the use of the context manager in the examples implies that this is true but documentation on other modules states so explicitly so this module should too.

----------
assignee: docs at python
components: Documentation
messages: 128460
nosy: docs at python, teamnoir
priority: normal
severity: normal
status: open
title: gzip doc is behind
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Sat Feb 12 20:54:06 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 19:54:06 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297540446.76.0.258501136862.issue11202@psf.upfronthosting.co.za>


Anders ?sthus <grapz666 at gmail.com> added the comment:

Ok, but the whole page you linked to (http://docs.python.org/library/shutil) confuses me then.

It states at the top:
"Warning

Even the higher-level file copying functions (copy(), copy2()) can?t copy all file metadata.

On POSIX platforms, this means that file owner and group are lost as well as ACLs. On Mac OS, the resource fork and other metadata are not used. This means that resources will be lost and file type and creator codes will not be correct. On Windows, file owners, ACLs and alternate data streams are not copied."

Then, under shutil.copy: "Permission bits are copied". I'm assuming this is UGO permissions on POSIX systems, and thus correct according to the top text.

shutil.copy2 says: Similar to shutil.copy, but with metadata.

Files copied with both shutil.copy and shutil.copy2 both inherits the permissions from their destination, but shutil.move does not.

According to the shutil doc page, neither copy or copy2 should do this. And since they do, and you say shutil.move is implemented using shutil.copy2, shouldn't files moved with shutil.move also then inherit the permissions?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:11:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 20:11:05 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297540446.76.0.258501136862.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297541461.3723.35.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> According to the shutil doc page, neither copy or copy2 should do
> this. And since they do, and you say shutil.move is implemented using
> shutil.copy2, shouldn't files moved with shutil.move also then inherit
> the permissions?

There's a misunderstanding I think. shutil.move()'s main path uses
os.rename(). Only does it fall back on copy2() when rename() fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:14:21 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 20:14:21 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297541661.79.0.393528175698.issue11202@psf.upfronthosting.co.za>


Anders ?sthus <grapz666 at gmail.com> added the comment:

Ok.

But that makes the whole method inconsistent.

Basically, if it's on the same filesystem, rename the file, and thus not inheriting ACL. If it's on another use copy2, and inherit ACL.

That makes no sense, atleast not to me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:15:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2011 20:15:39 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297541739.26.0.799138603385.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Add rich compare functions and disjoint() method to dbm view objects
> to make them as MappingView objects, and add abc registration for them.
I?d prefer you not to register them, but test isinstance(keys(), KeysView), so that we?re sure no method is missing.  (Does not validate behavior, but it?s a starting point.)

Other comments on Rietveld (the code review site).

BTW, if you?re posting updated patches on Rietveld you can remove patches from this bug report, so that people don?t review old patches.  It would also be simpler to keep all discussion there :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:17:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2011 20:17:43 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1297541863.75.0.780096302779.issue5736@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

#9523 has a more comprehensive patch in progress, adding __iter__ and other mapping methods, so I?m closing this one.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Improve dbm modules
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:18:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Feb 2011 20:18:34 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297541914.39.0.449845005951.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closed #5736 as superseded.  Please make sure the comments there about the peculiar API of gdbm don?t come up or are addressed in your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:24:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 20:24:35 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297541661.79.0.393528175698.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297542271.3723.37.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ok.
> 
> But that makes the whole method inconsistent.
> 
> Basically, if it's on the same filesystem, rename the file, and thus
> not inheriting ACL. If it's on another use copy2, and inherit ACL.

I think you're misunderstanding copy2. It will copy the ACL from the
source file, not from the target directory or filesystem.
Actually, if you look at copy2's implementation, it's just copyfile()
followed by copystat().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:33:44 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 20:33:44 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297542824.43.0.726238820934.issue11202@psf.upfronthosting.co.za>


Anders ?sthus <grapz666 at gmail.com> added the comment:

On my system (Win Server 2008 R2 64-Bit, Python 2.7.1), when I use copy, copy2 or move(to another filesystem), the file _will_ get the ACL of the DST folder, and remove any ACL in SRC file that the DST folder does not have.

Thus, it doesn't copy it from the source file, but inherits from the DST folder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 21:45:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 20:45:50 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297542824.43.0.726238820934.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297543547.3723.39.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> On my system (Win Server 2008 R2 64-Bit, Python 2.7.1), when I use
> copy, copy2 or move(to another filesystem), the file _will_ get the
> ACL of the DST folder, and remove any ACL in SRC file that the DST
> folder does not have.
> 
> Thus, it doesn't copy it from the source file, but inherits from the
> DST folder.

Again, this follows from the warning at the top of the shutil doc page:

?On Windows, file owners, ACLs and alternate data streams are not
copied.?

If they are not copied, then obviously they simply get the default value
for a new file, which is simply the value of the containing folder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 22:12:57 2011
From: report at bugs.python.org (=?utf-8?q?Anders_=C3=98sthus?=)
Date: Sat, 12 Feb 2011 21:12:57 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297545177.96.0.407480066973.issue11202@psf.upfronthosting.co.za>


Anders ?sthus <grapz666 at gmail.com> added the comment:

Thank you for taking the time to explain it to me, but it still seems inconsistent to me.

I did a test with the functions copy, copy2, move, os.rename, copyfile, both on the same filesystem and another filesystem, and the result is:

Same filesystem:
	shutil.copy:		Inherit
	shutil.copy2:		Inherit
	shutil.move:		Original
	os.rename:		Original
	shutil.copyfile:	Inherit

Different filesystem:
	shutil.copy:		Inherit
	shutil.copy2:		Inherit
	shutil.move:		Inherit
	os.rename:		Inherit
	shutil.copyfile:	Inherit

On the same system, the result will differ if you move the file to a different location on the same filesystem, or if you move it to another filesystem.

But still, I'm happy. I'll just use copy/copy2 and then delete the original file afterwards :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sat Feb 12 22:19:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 21:19:25 +0000
Subject: [issue11202] Win32: shutil.move does not inherit permissions
In-Reply-To: <1297536896.7.0.682572168427.issue11202@psf.upfronthosting.co.za>
Message-ID: <1297545565.95.0.70814377849.issue11202@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11202>
_______________________________________

From report at bugs.python.org  Sun Feb 13 00:14:05 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Sat, 12 Feb 2011 23:14:05 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297552445.05.0.830840697679.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

I will. Please don't use my patch yet, it breaks something else in the test_email:

./python Lib/test/regrtest.py test_email
[1/1] test_email
test test_email failed -- Traceback (most recent call last):
  File "/export/incoming/python/py3k/Lib/email/test/test_email.py", line 1146, in test_body
    eq(msg.get_payload(), '+vv8/f7/')
AssertionError: '+vv8/f7/\n' != '+vv8/f7/'
- +vv8/f7/
?         -
+ +vv8/f7/

1 test failed:
    test_email


This is with my code patch, not the test patch. I'll look at it, and post again, could be the extra newline you were talking about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Sun Feb 13 00:19:58 2011
From: report at bugs.python.org (John Machin)
Date: Sat, 12 Feb 2011 23:19:58 +0000
Subject: [issue11204] re module: strange behaviour of space inside {m, n}
In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>
Message-ID: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>


New submission from John Machin <sjmachin at lexicon.net>:

A pattern like r"b{1,3}\Z" matches "b", "bb", and "bbb", as expected. There is no documentation of the behaviour of r"b{1, 3}\Z" -- it matches the LITERAL TEXT "b{1, 3}" in normal mode and "b{1,3}" in verbose mode.

# paste the following at the interactive prompt:
pat = r"b{1, 3}\Z"
bool(re.match(pat, "bb")) # False
bool(re.match(pat, "b{1, 3}")) # True
bool(re.match(pat, "bb", re.VERBOSE)) # False
bool(re.match(pat, "b{1, 3}", re.VERBOSE)) # False
bool(re.match(pat, "b{1,3}", re.VERBOSE)) # True

Suggested change, in decreasing order of preference:
(1) Ignore leading/trailing spaces when parsing the m and n components of {m,n}
(2) Raise an exception if the exact syntax is not followed
(3) Document the existing behaviour

Note: deliberately matching the literal text would be expected to be done by escaping the left brace:

pat2 = r"b\{1, 3}\Z"
bool(re.match(pat2, "b{1, 3}")) # True

and this is not prevented by the suggested changes.

----------
messages: 128472
nosy: sjmachin
priority: normal
severity: normal
status: open
title: re module: strange behaviour of space inside {m, n}
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11204>
_______________________________________

From report at bugs.python.org  Sun Feb 13 00:54:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 12 Feb 2011 23:54:03 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1297539378.32.0.0271916571431.issue10084@psf.upfronthosting.co.za>
Message-ID: <1297554839.3723.55.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

First comments:

- secure_connection() should be named ssl_something() like other
methods. ssl_start() perhaps?

- in ssl_shutdown():
+                elif err.args[0] == ssl.SSL_ERROR_SSL:
+                    pass

SSL_ERROR_SSL doesn't exist.  Perhaps you mean ssl.SSL_ERROR_EOF?

- in send(), you should handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE as in recv(). Also:
+                if err.args[0] in (ssl.SSL_ERROR_EOF, ssl.SSL_ERROR_ZERO_RETURN):
+                    return 0

lacks a self.handle_close()?

- in recv(), you have "return ''" where it should be "return b''"

- in test_ssl_established(), I think it would be nice if you used e.g.
getpeercert() to check that we really are in SSL mode. Also, you could
make certificate checking mandatory using e.g.:

    ssl_context = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
    ssl_context.verify_mode = ssl.CERT_REQUIRED
    cert_path = os.path.join(os.path.dirname(__file__), "keycert.pem")
    ssl_context.load_cert_chain(cert_path)
    ssl_context.load_verify_locations(cert_path)

- in addition to test_handle_read() and test_handle_write(), there
should be a test where a server and a client really send data to each
other, and receive at all

(also, I'm not sure why these tests can't be shared with non-SSL test
classes)

- test_create_socket() and test_bind() don't seem to test anything
SSL-related

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10084>
_______________________________________

From report at bugs.python.org  Sun Feb 13 00:54:29 2011
From: report at bugs.python.org (jtidman)
Date: Sat, 12 Feb 2011 23:54:29 +0000
Subject: [issue11126] Wave.py does not always write proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1297554869.07.0.55204774041.issue11126@psf.upfronthosting.co.za>


jtidman <jtidman at siliconcoral.com> added the comment:

Yep, your solution is better.  I can provide some text files (lists of numbers) and two programs, wave2text.py and text2wav.py.  These are the programs I wrote that found this issue in the first place.  Add a few checks and you could run text2wave.py and then wave2text.py and verify that the results of these two steps match the original text files.

I look forward to working on this module with you.  Unfortunately the time frame would have to be sometime in 2011, as I am currently very busy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11126>
_______________________________________

From report at bugs.python.org  Sun Feb 13 04:47:32 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 03:47:32 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297568852.54.0.806337018426.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

I spent today some time to rewrite `memoryobject.c`, and cleaning up the Py_buffer handling in it. (I wrote also the Numpy PEP 3118 implementation, so this was straightforward to do.)

The end result is here: https://bitbucket.org/pv/cpython-stuff/changesets   (bookmark bug/memoryview)

Some points of note:

- Clarification of ownership conventions for Py_buffer in docs:

  http://bitbucket.org/pv/cpython-stuff/changeset/805971191369

  The new implementation is written to respect the invariants
  mentioned there.

- Rewritten memoryobject:

  http://bitbucket.org/pv/cpython-stuff/src/817edc63ce4d/Objects/memoryobject.c

I didn't yet heavily test this (eg. against Numpy), but at least the Python test suite passes. There are also some minor corners that need to be polished. Also some new tests would be needed, as I slightly extended the slicing capabilities of memoryview.

Only one nasty point turned up: the existence of PyMemoryView_FromBuffer. This function breaks the ownership rules: the pointers in Py_buffer structure can point inside the structure --- and the structure can reside e.g. on the stack. Deep copying Py_buffer cannot in general be done, because this can mess up whatever bf_releasebuffer tries to do. The workaround here was to do a deep copy *only* for those pointers that point inside the struct --- although this violates the spirit of the ownership model, it should be essentially always safe to do, and I believe it is the correct solution (at least if PyMemoryView_FromBuffer is to be retained).

    ***

Comments are welcome.

----------
nosy: +pv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:07:36 2011
From: report at bugs.python.org (Adi Roiban)
Date: Sun, 13 Feb 2011 04:07:36 +0000
Subject: [issue11181] TLS end connection not detected properly in retrbinary
In-Reply-To: <1297392420.85.0.207002171629.issue11181@psf.upfronthosting.co.za>
Message-ID: <1297570056.07.0.205036879521.issue11181@psf.upfronthosting.co.za>


Adi Roiban <adi at roiban.ro> added the comment:

Hi,

I apologies for raising this issues.

It looks like FTP_TLS is not available in Python 3.1 ... and retrbinary is working in Python 2.7.

What I actually done, was backporting ftplib.py from 2.7 to 2.5 and using pyOpenSSL instead of the standard ssl module.

It looks like the standard ?ssl? module from 2.7 return 0 instead of ssl.ZeroReturnError.

----------
resolution:  -> invalid
status: open -> closed
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:23:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 04:23:04 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297568852.54.0.806337018426.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297570980.3656.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

> I spent today some time to rewrite `memoryobject.c`, and cleaning up
> the Py_buffer handling in it. (I wrote also the Numpy PEP 3118
> implementation, so this was straightforward to do.)

Thanks for trying this.

> - Rewritten memoryobject:
> 
> http://bitbucket.org/pv/cpython-stuff/src/817edc63ce4d/Objects/memoryobject.c

Some worrying things here:

* memoryview_getbuffer() doesn't call the original object's getbuffer.
  This means that if I do:
        m = memoryview(some_object)
        n = memoryview(m)
        m.release()
  n ends up holding a buffer to some_object's memory, but some_object 
  doesn't know about it and can free the pointer at any time.

* same for _get_sub_buffer_index() and _get_sub_buffer_slice0().
  Actually, the whole concept of non-owner memoryviews seems flawed.

* the fact that slicing increments the parent memoryview's refcount 
  means that a loop like:
     while len(m):
       # do something
       m = m[1:]
  will end up keeping N chained memoryviews on the heap. Currently only
  the last memoryview remains alive.

Some other things:

* why do you accept the ellipsis when indexing? what is it supposed to 
  mean?

* please don't use #warning. Just put the TODO in a /* ... */.

* please no "#if PY_VERSION_HEX >= 0x03000000". Just make your source
  py3k-compatible and we'll take care of backporting it to 2.x if your
  patch is accepted ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:36:40 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 13 Feb 2011 04:36:40 +0000
Subject: [issue11160] ZipFile.comment expects bytes
In-Reply-To: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>
Message-ID: <1297571800.83.0.849756028759.issue11160@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

IMO the Zipfile.comment should accept strings too instead of just accepting bytes , so patching should help i guess

----------
nosy: +swamiyeswanth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11160>
_______________________________________

From report at bugs.python.org  Sun Feb 13 05:41:51 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 13 Feb 2011 04:41:51 +0000
Subject: [issue11160] ZipFile.comment expects bytes
In-Reply-To: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>
Message-ID: <1297572111.99.0.991684632692.issue11160@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

can we use str.encode() function to convert string into bytes ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11160>
_______________________________________

From report at bugs.python.org  Sun Feb 13 06:42:13 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 13 Feb 2011 05:42:13 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297575733.12.0.319385812353.issue11197@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Agreed, fixing this is going to be too complex for 3.2.0, it'll be done for 3.2.1.

Reading over the http.server Simple and CGI HTTPRequestHandler code I see there many problems with the way this code does things today.

General:
 * I'm not sure urllib.parse.unquote() is called on the path in the correct place all the time.  Studying of some RFCs will be required to confirm that.  Specifically the CGI handler unquotes the path before fixing it up.  The Simple handler never unquotes the path.

Simple (and subclasses such as CGI):
 * The mentioned directory traversal vulnerability.

CGI:
 * The _url_collapse_path_split called by is_cgi lets os.sep's through unchecked so a request for /foo/bar\..\..\..\..\..\../ for example should still find its way out on windows.  issue2254 wasn't 100% fixed.
 * _url_collapse_path_split should really ignore the query string and anchor; though the way it is used it likely just wastes time processing them and discarding the result.
 * It uses fork() + execve() on posix systems. It should always use subprocess instead in order to be thread safe.

The first thing I'll be doing is coming up with test cases demonstrating each of these issues.

----------
versions:  -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sun Feb 13 08:17:18 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Sun, 13 Feb 2011 07:17:18 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297581438.2.0.302906066096.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

I've got two issues with this code (Lib/email/test/test_email.py):


1128     def test_body(self):
1129         eq = self.assertEqual
1130         bytes = b'\xfa\xfb\xfc\xfd\xfe\xff'
1131         msg = MIMEApplication(bytes)
1132         eq(msg.get_payload(), '+vv8/f7/')
1133         eq(msg.get_payload(decode=True), bytes)

1) Even though it works, I find the use of a defined type as the name of a variable confusing (line 1130, bytes).

2) The test on line 1132 fails if the base64 payload has an extra newline at the end, but newlines are not an issue in base64 and are actually expected. In fact the test at line 1133 shows that once decoded, the bytes are reverted to their original form.

Is there a way to find who is the author of this test, and what was the intent? Would the following test be acceptable (still testing a valid base64 encoding):

eq(msg.get_payload().strip(), '+vv8/f7/')


Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Sun Feb 13 10:39:13 2011
From: report at bugs.python.org (takayuki)
Date: Sun, 13 Feb 2011 09:39:13 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>


New submission from takayuki <takayuki988 at star.odn.ne.jp>:

Running the following code shows "2 1 4 3", but in reference manual
http://docs.python.org/reference/expressions.html#expression-lists
the evaluation order described as
{expr1: expr2, expr3: expr4}

def f(i):
    print i
    return i

{f(1):f(2), f(3):f(4)}

I found some of past discussions about this problem, for example,
http://mail.python.org/pipermail/python-dev/2002-November/030461.html
http://mail.python.org/pipermail/python-dev/2002-November/030458.html
http://bugs.python.org/issue448679
http://svn.python.org/view?view=rev&revision=30148
, but current implementation seems not to reflect these accomplishment.

In present, which behaviour is legal?

----------
components: None
messages: 128482
nosy: takayuki
priority: normal
severity: normal
status: open
title: Evaluation order of dictionary display is different from reference manual.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 10:46:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Feb 2011 09:46:38 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1297590398.37.0.774642890098.issue11197@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Lowering priority.

----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Sun Feb 13 10:59:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 13 Feb 2011 09:59:46 +0000
Subject: [issue11160] ZipFile.comment expects bytes
In-Reply-To: <1297264140.97.0.306129367766.issue11160@psf.upfronthosting.co.za>
Message-ID: <1297591186.26.0.64487247089.issue11160@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> can we use str.encode() function to convert string into bytes ?

Can you try different ZIP archivers to check which encoding is expected? WinZip, WinRAR, 7-zip, "zip" command line program on Linux, etc.

And do you have any reference into a ZIP documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11160>
_______________________________________

From report at bugs.python.org  Sun Feb 13 11:26:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Feb 2011 10:26:38 +0000
Subject: [issue11206] test_readline unconditionally calls clear_history()
In-Reply-To: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>
Message-ID: <1297592798.04.0.448231212835.issue11206@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This function apparently is not available in all readline versions; e.g. the GNU readline 5.2 currently installed on dinsdale.

This can be fixed (together with the unconditional reliance of test_distutils and test_zipfile on zlib) after 3.2 final.

----------
components: Tests
messages: 128485
nosy: georg.brandl
priority: high
severity: normal
stage: needs patch
status: open
title: test_readline unconditionally calls clear_history()
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11206>
_______________________________________

From report at bugs.python.org  Sun Feb 13 12:53:28 2011
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 13 Feb 2011 11:53:28 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1297598008.52.0.464818450225.issue5231@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sun Feb 13 13:09:26 2011
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 13 Feb 2011 12:09:26 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1297598966.0.0.183835565406.issue5231@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Is this issue from 2 years ago still open? I checked the docs and it seems to be.

If it is, I would like to work on a patch and submit it soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sun Feb 13 13:28:50 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 13 Feb 2011 12:28:50 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297600130.11.0.648901069458.issue11205@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


----------
nosy: +swamiyeswanth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:04:10 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:04:10 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297602250.32.0.790750250541.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Here's a patch.

----------
keywords: +patch
nosy: +skip.montanaro
versions: +Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20753/compile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:07:51 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Feb 2011 13:07:51 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1297602471.98.0.502509050975.issue5231@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It is, but keep issue 10181 in mind (since that may lead to some restructuring of the memoryview code, potentially leading to a need to update your patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5231>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:08:54 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:08:54 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297602534.18.0.286342497342.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Working on a test case too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:14:33 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:14:33 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297602873.16.0.83399108235.issue11205@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file20753/compile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:14:57 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:14:57 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297602897.84.0.502603921059.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

It's not so easy as first appeared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:20:55 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 13:20:55 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297603255.89.0.608108518913.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Hi,

Please focus on the constraints of the consumer not mucking with the content of `Py_buffer`, and calling `bf_releasebuffer` only with data obtained from `bf_getbuffer` and only one. If we agree on this, then how to exactly to do the implementation is just a detail.

The problem in the current way is that the structure sent to `bf_releasebuffer` does not contain the same data as what was filled in by `bf_getbuffer`, and since the contents are dup-ed, `bf_releasebuffer` is called multiple times with the same data. So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what `bf_getbuffer` put there, and (ii) getting the same Py_buffer data only once.

So, `bf_releasebuffer` cannot be used to release any resources allocated in `bf_getbuffer`. For example, Numpy's PEP 3118 implementation does not define a `bf_releasebuffer` although it needs to allocate resources in each call to `bf_getbuffer`. Instead, it has to keep a track of allocated memory, and deallocate all of them on `array_dealloc`. This is a PITA, and one that could be avoided by a small change in the PEP implementation and documentation in Python.

> Some worrying things here:
> 
> * memoryview_getbuffer() doesn't call the original object's getbuffer.
>   This means that if I do:
>         m = memoryview(some_object)
>         n = memoryview(m)
>         m.release()
>   n ends up holding a buffer to some_object's memory, but some_object 
>   doesn't know about it and can free the pointer at any time.

Good point. There are two possible solutions to this:

- Keep a count of how many buffers memoryview() has "exported", 
  and do not allow memoryview.release() if some are active.

  In a sense, this would be more in line with the PEP:
  the PyMemoryViewObject would here act as an ordinary object
  exporting some block of memory, and not do any magic tricks.
  It would guarantee that the buffers it has "exported" stay valid.

- Add additional fields to `PyMemoryViewObject` for storing
  new `strides`, `format`, and `shape` that override the stuff
  in Py_buffer.

  This would allow for calling `PyObject_GetBuffer` for a second time.

Both would be reasonably easy to do.

    ***

Calling PyObject_GetBuffer to get a new hold of a buffer needs some precautions, though. For example:

    >>> mem = memoryview(some_object)
    # do some stuff
    >>> mem2 = memoryview(some_object)
    >>> assert mem.format == mem2.format  # not guaranteed

so there is some extra work `memoryview_getbuffer` could do on top of calling PyObject_GetBuffer.

> * same for _get_sub_buffer_index() and _get_sub_buffer_slice0().
>  Actually, the whole concept of non-owner memoryviews seems flawed.

If the "parent" memoryview keeps its the memory valid as long as such sub-memoryviews exist, such concerns go away.

> * the fact that slicing increments the parent memoryview's refcount 
>  means that a loop like:
>     while len(m):
>       # do something
>       m = m[1:]
>  will end up keeping N chained memoryviews on the heap. Currently only
>  the last memoryview remains alive.

This has an easy solution: if the parent is a non-owner memoryview, take a reference to its obj. This then keeps only buffer-owning view on the stack.

> Some other things:
>
> * why do you accept the ellipsis when indexing? what is it supposed to 
>   mean?

Same meaning as in Numpy. a[...] == a

> * please don't use #warning. Just put the TODO in a /* ... */.

Sure.

> * please no "#if PY_VERSION_HEX >= 0x03000000". Just make your source
>   py3k-compatible and we'll take care of backporting it to 2.x if your
>  patch is accepted ;)

Those are just so that the backporting would be easy. It's not on the stage of a serious patch yet :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:32:38 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:32:38 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297603958.84.0.521985279183.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Okay, this looks better.  I was confusing myself with leftover .pyc
files I think.  Test included.

----------
Added file: http://bugs.python.org/file20754/compile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 14:37:42 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 13:37:42 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297604262.55.0.819952591455.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Georg,  I think this might need to sneak into 3.2.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:13:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Feb 2011 14:13:53 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297606433.32.0.529703521386.issue11205@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think so -- it's a very minor deviation from the spec and not a critical bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:19:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 14:19:14 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297603255.89.0.608108518913.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297606749.3802.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The problem in the current way is that the structure sent to
> `bf_releasebuffer` does not contain the same data as what was filled
> in by `bf_getbuffer`, and since the contents are dup-ed,
> `bf_releasebuffer` is called multiple times with the same data.

Hmm, there's a misunderstanding. bf_releasebuffer is called exactly once
for each call to bf_getbuffer. Of course, bf_getbuffer can be called
several times!

>  So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being
> what `bf_getbuffer` put there,

Well, why should it rely on that?

> So, `bf_releasebuffer` cannot be used to release any resources
> allocated in `bf_getbuffer`.

AFAICT, it can. That's what the "internal" pointer is for:

        This is for use internally by the exporting object. For example,
        this might be re-cast as an integer by the exporter and used to
        store flags about whether or not the shape, strides, and
        suboffsets arrays must be freed when the buffer is released. The
        consumer should never alter this value.

(http://docs.python.org/dev/c-api/buffer.html#Py_buffer.internal)

> > Some worrying things here:
> > 
> > * memoryview_getbuffer() doesn't call the original object's getbuffer.
> >   This means that if I do:
> >         m = memoryview(some_object)
> >         n = memoryview(m)
> >         m.release()
> >   n ends up holding a buffer to some_object's memory, but some_object 
> >   doesn't know about it and can free the pointer at any time.
> 
> Good point. There are two possible solutions to this:
> 
> - Keep a count of how many buffers memoryview() has "exported", 
>   and do not allow memoryview.release() if some are active.

Where would that count be stored?

>   In a sense, this would be more in line with the PEP:
>   the PyMemoryViewObject would here act as an ordinary object
>   exporting some block of memory, and not do any magic tricks.

Well, that sounds wrong to me. The memoryview doesn't export anything;
the original object does.

>   It would guarantee that the buffers it has "exported" stay valid.

How would it, since it doesn't know the original object's semantics?

> - Add additional fields to `PyMemoryViewObject` for storing
>   new `strides`, `format`, and `shape` that override the stuff
>   in Py_buffer.
> 
>   This would allow for calling `PyObject_GetBuffer` for a second time.

Sounds better to me :)

> Calling PyObject_GetBuffer to get a new hold of a buffer needs some precautions, though. For example:
> 
>     >>> mem = memoryview(some_object)
>     # do some stuff
>     >>> mem2 = memoryview(some_object)
>     >>> assert mem.format == mem2.format  # not guaranteed

Well, if the original object decides to change the format between two
calls, then memoryview() should simply reflect that.

> > * same for _get_sub_buffer_index() and _get_sub_buffer_slice0().
> >  Actually, the whole concept of non-owner memoryviews seems flawed.
> 
> If the "parent" memoryview keeps its the memory valid as long as such
> sub-memoryviews exist, such concerns go away.

So release() wouldn't do what it claims to do? That sounds misleading.

> > Some other things:
> >
> > * why do you accept the ellipsis when indexing? what is it supposed to 
> >   mean?
> 
> Same meaning as in Numpy. a[...] == a

Yes, but why we would do that in core Python? a[...] might have a
meaning in NumPy, but it has none in core Python currently.
I'm not against it, but it would warrant discussion on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:19:36 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 14:19:36 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1297606776.53.0.417046307993.issue5302@psf.upfronthosting.co.za>


Alexis Metaireau <ametaireau at gmail.com> added the comment:

The MANIFEST.in is definitely gone in distutils2. 

Can we close that? (don't have the rights to do so ? it can be handy on distutils2 bugs)

----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:23:17 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 14:23:17 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1297606997.0.0.535480521634.issue5243@psf.upfronthosting.co.za>


Alexis Metaireau <ametaireau at gmail.com> added the comment:

Has the patch been applied on distutils(1/2) ?

----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:26:55 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 14:26:55 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297607215.49.0.348248605034.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

3.2 and earlier versions are all frozen, but for 3.3 it might make sense to bump the version number of the bytecode and change STORE_MAP to take the key and value in the opposite order, thus allowing to remove the ROT_TWO I had to add to make this work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:35:10 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 14:35:10 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297607710.96.0.641485698052.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

> Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> once for each call to bf_getbuffer.

Wrong: http://bugs.python.org/issue7433

static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
    int res = 0;
    CHECK_RELEASED_INT(self);
    if (self->view.obj != NULL)
        res = PyObject_GetBuffer(self->view.obj, view, flags);
    if (view)
        dup_buffer(view, &self->view);
    return res;
}

After this, PyBuffer_Release will be called twice: once on the data in *view, by whoever acquired the buffer from memoryview, and once on self->view, by memory_dealloc. Both with the same bit-by-bit content of the Py_buffer structure.

Because there are two Py_buffer structures here, setting view.obj to NULL in PyBuffer_Release does not guarantee correct calls to bf_releasebuffer.

Note that the view.internal pointer is also clobbered above.

> >  So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer
> > being what `bf_getbuffer` put there,
> 
> Well, why should it rely on that?

Because that makes implementing the exporter much easier. Also, writing an implementation for MemoryViewObject does not require clobbering the structure, and I doubt it helps much.

> > So, `bf_releasebuffer` cannot be used to release any resources
> > allocated in `bf_getbuffer`.
>
> AFAICT, it can. That's what the "internal" pointer is for.

Sure, guaranteeing that view->internal pointer is not toyed with would also be enough.

But the documentation should spell out very explicitly what the bf_releasebuffer call can rely on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:35:33 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Feb 2011 14:35:33 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297607733.55.0.0182961327493.issue11205@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Interesting.  I would actually have expected the observed behavior.  I think of the : in a dictionary literal as an assignment.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:36:42 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 14:36:42 +0000
Subject: [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1297607802.74.0.461705955919.issue901727@psf.upfronthosting.co.za>


Alexis Metaireau <ametaireau at gmail.com> added the comment:

I've applied the patch on distutils2. This can now be closed.

----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue901727>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:49:29 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 14:49:29 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
	result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1297608569.04.0.938143054952.issue6087@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <ametaireau at gmail.com>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6087>
_______________________________________

From report at bugs.python.org  Sun Feb 13 15:56:30 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Feb 2011 14:56:30 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297608990.34.0.0601557047234.issue11205@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

BTW, it would be nice to know if this behavior was consistent with the docs at any time (the merge of the AST branch in 2.5 might be an obvious candidate where it was broken).

Also interesting would be what other implementations of Python do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:02:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 15:02:14 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297607710.96.0.641485698052.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297609331.3802.36.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> > once for each call to bf_getbuffer.
> 
> Wrong: http://bugs.python.org/issue7433

This is a different issue.

> static int
> memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
> {
>     int res = 0;
>     CHECK_RELEASED_INT(self);
>     if (self->view.obj != NULL)
>         res = PyObject_GetBuffer(self->view.obj, view, flags);
>     if (view)
>         dup_buffer(view, &self->view);
>     return res;
> }
> 
> After this, PyBuffer_Release will be called twice: once on the data in
> *view, by whoever acquired the buffer from memoryview
> , and once on self->view, by memory_dealloc.

PyObject_GetBuffer() is called twice too: once when creating the
memoryview, once when calling memory_getbuf.
So again, bf_getbuffer is called the same number of times as
bf_releasebuffer.

> Note that the view.internal pointer is also clobbered above.

Are you sure? memoryobject.c doesn't touch that pointer at all.

> > > So, `bf_releasebuffer` cannot be used to release any resources
> > > allocated in `bf_getbuffer`.
> >
> > AFAICT, it can. That's what the "internal" pointer is for.
> 
> Sure, guaranteeing that view->internal pointer is not toyed with would
> also be enough.
> 
> But the documentation should spell out very explicitly what the
> bf_releasebuffer call can rely on.

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:06:23 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 15:06:23 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1297609583.74.0.512501404971.issue2200@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Have the patch been applied ? (the state is still open since last message)

----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:09:38 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 15:09:38 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297609778.0.0.955684185325.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

[clip]
> This is a different issue.

It is the issue relevant for this discussion. As written in my comment: "So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer being what `bf_getbuffer` put there, and (ii) getting the same Py_buffer data only once."

> PyObject_GetBuffer() is called twice too: once when creating the
> memoryview, once when calling memory_getbuf.
> So again, bf_getbuffer is called the same number of times as
> bf_releasebuffer.

Yes, it is called twice, but with exactly the same data in Py_buffer.
So I would rather say that bf_releasebuffer is called twice on the Py_buffer returned by the first Getbuffer, and zero times for the buffer returned by the second one.

> > Note that the view.internal pointer is also clobbered above.
> 
> Are you sure? memoryobject.c doesn't touch that pointer at all.

dup_buffer does *dst = *src, which overwrites the view.internal pointer obtained from one GetBuffer call with a pointer obtained from a previous one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:11:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 15:11:38 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297609778.0.0.955684185325.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297609895.3802.38.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> dup_buffer does *dst = *src, which overwrites the view.internal
> pointer obtained from one GetBuffer call with a pointer obtained from
> a previous one.

Ah, ok, then it deserves fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:17:10 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 15:17:10 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297610230.89.0.28777435626.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

As Georg suggested, it is correct in 2.4, wrong in 2.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:20:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 15:20:54 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297610454.66.0.670022230033.issue11205@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:31:31 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 15:31:31 +0000
Subject: [issue7546] msvc9compiler.py: add .asm extension
In-Reply-To: <1261241045.73.0.563579401037.issue7546@psf.upfronthosting.co.za>
Message-ID: <1297611091.75.0.203983164512.issue7546@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7546>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:34:19 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 15:34:19 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297611259.48.0.0563441940358.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Ok, good, that diversion was then avoided :)

    ***

So, am I on the right track that there would not be many objections to clarifying the docs of Py_buffer spec by stating:

- For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
  is called exactly once.

  Each `bf_releasebuffer` call is guaranteed to get the same
  view->internal pointer as filled in previously by the
  corresponding `bf_getbuffer`.

  All other fields in `Py_buffer` may be modified by the consumer,
  and `bf_releasebuffer` may not assume they contain valid data.

- The exporter of the buffer must ensure that apart from the contents
  of the memory pointed to by `buf`, the contents of the returned
  Py_buffer (format, strides, shape, etc.) remain unchanged.

If the latter is not true, it will lead to no end of trouble in e.g. multithreaded programs.

What about the more strict requirement:

- `bf_releasebuffer` is guaranteed that all fields except `obj`
  are not modified?

This could simplify implementation of exporters, and I suspect that MemoryViewObject is a special case, as most consumers probably would not want to make such modifications.

I can try preparing an updated patch based on some combination of the above, taking into account your comments.

BTW, should I take this discussion to Python-dev? So far, I kept it here, as this bug report seemed to be about general issues in the current implementation and spec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:41:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2011 15:41:02 +0000
Subject: [issue5302] Allow package_data globs match directories
In-Reply-To: <1234909934.56.0.127417684931.issue5302@psf.upfronthosting.co.za>
Message-ID: <1297611662.34.0.715997595157.issue5302@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Even if MANIFEST.in is gone, we still have a way to include files, so the request to allow globs to match directories still apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5302>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:41:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2011 15:41:49 +0000
Subject: [issue5243] Missing dependency in distutils build
In-Reply-To: <1234519029.27.0.18013582736.issue5243@psf.upfronthosting.co.za>
Message-ID: <1297611709.99.0.129559472887.issue5243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If we haven?t closed it, it?s because it has not been.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5243>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:44:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2011 15:44:22 +0000
Subject: [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1297611862.01.0.754401381782.issue901727@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You shouldn?t have :)  apiref.rst is very outdated in d2, because the setup function does not exist.  The docs could be adjusted to document Distribution instead of setup, but we?re not even sure Distribution will stay.

I think I will make a compromise here and apply the patch to distutils1 doc, so that the information is found on the official docs.

----------
components: +Distutils -Distutils2
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue901727>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:44:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2011 15:44:44 +0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1297611884.13.0.96599500647.issue2200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:46:44 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 15:46:44 +0000
Subject: [issue901727] extra_path kwarg to setup() undocumented
In-Reply-To: <1297611862.01.0.754401381782.issue901727@psf.upfronthosting.co.za>
Message-ID: <4D57FCE0.2030507@notmyidea.org>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Still, the extra_path argument exists and can be used, it's worth to
have it documented somewhere, especially if someone have done it.

That's also true that apiref.rst is outdated in d2, and will need a
complete reshape :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue901727>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:55:13 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 15:55:13 +0000
Subject: [issue1083299] Distutils doesn't pick up all the files it should.
Message-ID: <1297612513.47.0.323881153887.issue1083299@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
components:  -Distutils2
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083299>
_______________________________________

From report at bugs.python.org  Sun Feb 13 16:56:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Feb 2011 15:56:39 +0000
Subject: [issue1083299] Distutils doesn't pick up all the files it should.
Message-ID: <1297612599.91.0.0933027225994.issue1083299@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1083299>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:00:23 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 16:00:23 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1297612823.28.0.259918150625.issue1597850@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597850>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:01:04 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 16:01:04 +0000
Subject: [issue1294032] Distutils writes keywords comma-separated
Message-ID: <1297612864.48.0.602460755876.issue1294032@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294032>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:01:47 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 16:01:47 +0000
Subject: [issue1092365] Distutils needs a way *not* to install files
Message-ID: <1297612907.78.0.885190807241.issue1092365@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092365>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:04:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 16:04:24 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297611259.48.0.0563441940358.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297613061.3802.43.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> - For each buffer yielded by `bf_getbuffer`, `bf_releasebuffer`
>   is called exactly once.
> 
>   Each `bf_releasebuffer` call is guaranteed to get the same
>   view->internal pointer as filled in previously by the
>   corresponding `bf_getbuffer`.
> 
>   All other fields in `Py_buffer` may be modified by the consumer,
>   and `bf_releasebuffer` may not assume they contain valid data.
> 
> - The exporter of the buffer must ensure that apart from the contents
>   of the memory pointed to by `buf`, the contents of the returned
>   Py_buffer (format, strides, shape, etc.) remain unchanged.

Yes! Can you write a patch that does these docs changes and also fixes
the internal pointer issue?

> What about the more strict requirement:
> 
> - `bf_releasebuffer` is guaranteed that all fields except `obj`
>   are not modified?

Well, if you manage to change the memoryview implementation for that,
then fine. But I don't know how you plan to manage ownership of fields
such as strides and friends.

> BTW, should I take this discussion to Python-dev? So far, I kept it
> here, as this bug report seemed to be about general issues in the
> current implementation and spec.

I don't think you need to. Nick and Mark follow this issue (and so does
Travis if he's still alive ;)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:05:08 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 16:05:08 +0000
Subject: [issue1635363] Add command line help to windows unistall binary
Message-ID: <1297613108.31.0.328656050974.issue1635363@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1635363>
_______________________________________

From report at bugs.python.org  Sun Feb 13 17:06:10 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Sun, 13 Feb 2011 16:06:10 +0000
Subject: =?utf-8?q?=5Bissue1011113=5D_Make_=E2=80=9Cinstall=E2=80=9D_find_the_buil?=
	=?utf-8?q?d=5Fbase_directory?=
Message-ID: <1297613170.46.0.977965175497.issue1011113@psf.upfronthosting.co.za>


Changes by Alexis Metaireau <alexis at notmyidea.org>:


----------
nosy: +alexis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1011113>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:23:25 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Sun, 13 Feb 2011 18:23:25 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297621405.35.0.0339602346314.issue9298@psf.upfronthosting.co.za>


Changes by Yves Dorfsman <yves at zioup.com>:


Removed file: http://bugs.python.org/file20742/issue9298-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:23:34 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Sun, 13 Feb 2011 18:23:34 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297621414.06.0.722034005242.issue9298@psf.upfronthosting.co.za>


Changes by Yves Dorfsman <yves at zioup.com>:


Removed file: http://bugs.python.org/file20743/issue9298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Sun Feb 13 19:36:14 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Sun, 13 Feb 2011 18:36:14 +0000
Subject: [issue9298] binary email attachment issue with base64 encoding
In-Reply-To: <1279508696.99.0.665109757672.issue9298@psf.upfronthosting.co.za>
Message-ID: <1297622174.75.0.9939864207.issue9298@psf.upfronthosting.co.za>


Yves Dorfsman <yves at zioup.com> added the comment:

encoders.py:
Fixes the issue of base64'ed being > 76 chars


test_email.py:

-test that base64'ed binary is split into 76 chars lines

-WARRNING: Changes the test for MIMEApplication.test_body:
    -it changes the name of the variable 'bytes' to 'bytesdata'
    -it strip()s the base64ed payload before it compares it to the expected payload. With the change above (using encodebytes instead of b64encode in encoders.py), this test, as is, fails, because there is an extra newline at the end. Extra newlines are part of base64 and should not be an issue, as a matter of fact, you obtain the original bytes when you decode, regardless of having extra newlines. It would be good to know the intent of the original author of this test. Was the intent to ensure there were no newline? If so, why? Or was the intent to simply confirm the base64 encoding conform to the standard? If the latter, my change should not be an issue.

All test ("make test") passed with this patch.

----------
Added file: http://bugs.python.org/file20755/issue9298-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9298>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:08:44 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Sun, 13 Feb 2011 19:08:44 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297624124.35.0.201623748108.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Ok, here's a patch with some suggested documentation changes + the minimal changes in memoryview to make bf_releasebuffer behave as advertised. Probably shouldn't be applied as-is, though.

Problems remain. Suppose `bf_getbuffer` for memoryview is implemented so that it returns a view exported by the original object (and not the memoryview). Consider an example:

    >>> obj = PictureSet()       # exposes a buffer, say, to "pic_1"
    >>> a = memoryview(obj)      # points to pic_1

Here, `a` grabs a lock to pic_1.

    >>> obj.choose_picture(2)    # switches the exposed buffer to pic_2
    >>> b = memoryview(obj)      # points to pic_2
    >>> c = memoryview(a)

Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2 and passes it on to `c`. The spec specifies no ways to get additional locks on pic_1.

    >>> a.release()

Now lock on pic_1 is released, and the buffer may be freed (also, if the handling of shape/stride arrays in memoryview is as it is now, also those are invalidated). One of the two is now true: `memoryview(a)` does not always describe the same area of memory as `a`, OR, `c` ends up with a lock on the wrong area of memory and the program hits a SEGV. 

[clip]
> >   In a sense, this would be more in line with the PEP:
> >   the PyMemoryViewObject would here act as an ordinary object
> >   exporting some block of memory, and not do any magic tricks.
> 
> Well, that sounds wrong to me. The memoryview doesn't export 
> anything; the original object does.

Having the memoryview "own" the exported buffer would be a simple solution to the above issue.

The alternative would be to adjust the spec so that the above type of behavior is forbidden (any buffers and the shape/stride arrays ever exported must remain valid until the last one is released). Not sure if it makes sense to do this if the only gain is a simplification in the implementation of memoryview.

> > It would guarantee that the buffers it has "exported" stay valid.
>
> How would it, since it doesn't know the original object's semantics?

The original object must guarantee that the buffers remain valid until released, as specified in the PEP. Of course, this requires that memoryview counts how many buffers it has exported, and allows release() only if the count is zero.

----------
Added file: http://bugs.python.org/file20756/buffer-interface-clarify.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:31:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 19:31:32 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297624124.35.0.201623748108.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297625488.3802.58.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Problems remain. Suppose `bf_getbuffer` for memoryview is implemented
> so that it returns a view exported by the original object (and not the
> memoryview). Consider an example:
> 
>     >>> obj = PictureSet()       # exposes a buffer, say, to "pic_1"
>     >>> a = memoryview(obj)      # points to pic_1
> 
> Here, `a` grabs a lock to pic_1.
> 
>     >>> obj.choose_picture(2)    # switches the exposed buffer to
> pic_2

That's a very bad API to begin with. Anyone thinking it is reasonable to
have the concept of a "current element" in a container should write PHP
code instead. If you have individual pictures, please use individual
objects.

>     >>> b = memoryview(obj)      # points to pic_2
>     >>> c = memoryview(a)
> 
> Here, PyObject_GetBuffer in bf_getbuffer for `a` grabs a lock to pic_2
> and passes it on to `c`

So what? c will represent pic_2 anyway, so the behaviour is right. Awful
certainly for the user, but that's because PictureSet implements a
braindead API.

> , and the buffer may be freed (also, if the handling of shape/stride
> arrays in memoryview is as it is now, also those are invalidated). One
> of the two is now true: `memoryview(a)` does not always describe the
> same area of memory as `a`, OR, `c` ends up with a lock on the wrong
> area of memory and the program hits a SEGV. 

This all points to completely broken logic in the imaginary PictureSet
class. If someone doesn't get their semantics right, it is not the
buffer API's problem. bf_getbuffer and bf_releasebuffer must implement
symmetric operations; perhaps that's not explicitly worded, but it seems
quite obvious to me.

> The alternative would be to adjust the spec so that the above type of
> behavior is forbidden (any buffers and the shape/stride arrays ever
> exported must remain valid until the last one is released).

Why would you adjust the spec? This just stems from common sense.
If you provide a pointer to a consuming API, you have to ensure the
pointer remains valid as long as the consuming API is using that
pointer. Actually, that's *exactly* why there's a bf_releasebuffer
method at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 20:42:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 19:42:18 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297626138.54.0.334471448448.issue10181@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That said:

> Having the memoryview "own" the exported buffer would be a simple
> solution to the above issue.

If you can implement that without exhibing the issues we discussed above (e.g. O(N) memory consumption when doing repetitive slicing), then why not.

Also, thanks for the patch. Please refrain from spurious formatting changes, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 21:33:57 2011
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 13 Feb 2011 20:33:57 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1297629237.79.0.977570617114.issue11149@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

@Antoine Pitrou , that is tracked by http://bugs.python.org/issue1621

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11149>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:51:10 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Feb 2011 21:51:10 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297633870.1.0.835347565909.issue11205@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

<sigh> If only a test had been checked-in eight years ago ...

It looks like a number of things have to be changed in order to bring behavior back to what the docs promise.  Dict literals and dict comprehensions need to be fixed in both the compile.py and compile.c.  To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD opcodes need minor modifications (just switch the u and w variable assignments).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:52:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Feb 2011 21:52:18 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297633938.58.0.535449166012.issue11205@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

takayuki, a special thanks to you for submitting such a well-researched bug report :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:54:40 2011
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Feb 2011 21:54:40 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297634080.11.0.545925141672.issue11205@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

> To avoid introducing a ROT_TWO, the store STORE_MAP and MAP_ADD
> opcodes need minor modifications (just switch the u and w variable
> assignments).

Either of which would not be possible in anything other that 3.3 or 
later, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:56:03 2011
From: report at bugs.python.org (David Knapp)
Date: Sun, 13 Feb 2011 21:56:03 +0000
Subject: [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>


New submission from David Knapp <psychicsurgeon at gmail.com>:

Python had a seg fault with the following simple code.

>>> import PIL.Image as Img
>>> import numpy as np
>>> i = Img.open('/home/falmarri/Dropbox/obey.jpg')
>>> n = np.array(bytearray(i.tostring()),dtype=np.uint16)
zsh: segmentation fault  python

Running it under gdb gave the following

(gdb) run g19_framebuffer.py
Starting program: /usr/bin/python g19_framebuffer.py
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
_unaligned_strided_byte_copy (dst=0xcb9543 "\366\377\177", outstrides=1, src=0x7ffff3503da5 <Address 0x7ffff3503da5 out of bounds>, 
    instrides=4969607, N=10000, elsize=<value optimized out>) at /usr/include/bits/string3.h:52
warning: Source file is more recent than executable.
52        return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));


It could be that I'm doing it wrong though.

----------
messages: 128523
nosy: David.Knapp
priority: normal
severity: normal
status: open
title: Pythong seg fault with PIL/numpy
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11207>
_______________________________________

From report at bugs.python.org  Sun Feb 13 22:59:12 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 13 Feb 2011 21:59:12 +0000
Subject: [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1297634352.45.0.660618659334.issue11207@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Can you give a longer backtrace? Since that failure is happening in a system library we need to know where the segfault first occurs in either PIL, numpy, or CPython.

And have you tried this in Python 2.7?

----------
nosy: +brett.cannon
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11207>
_______________________________________

From report at bugs.python.org  Sun Feb 13 23:01:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Feb 2011 22:01:05 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297634465.58.0.479885788421.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm still not comfortable with a convention that relies on *clients* of the PEP 3118 API not mucking with the internals of the Py_buffer struct.

I'm *much* happier with the rule based on malloc/free semantics where the *pointer* passed to PyObject_GetBuffer must match a single later call to PyObject_ReleaseBuffer. This is also a convention that should be quite familiar to any C/C++ developers using the API directly.

Note my comment earlier, pointing out that under those rules, dup_buffer actually does the right thing given the way it is used in the current implementation, but there's one current bug (issue 9990) where the wrong address is passed to the release buffer call - get_buffer is called with a stack address, the contents are copied to a heap address, then the heap address is used in the release_buffer call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 23:12:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Feb 2011 22:12:45 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297635165.41.0.851663838676.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as the question of re-exporting the underlying view or not goes, I agree having "memoryview(a)" potentially refer to different underlying memory from "a" itself (because the source object has changed since the first view was exported) is a recipe for confusion. It is also important for ensuring memoryview slicing works correctly.

>From a didactic point of view, this would also have the benefit of providing a canonical example of managing exported Py_buffer structs in the CPython source code.

The "repeated slicing" issue is definitely a concern, though. If we declare memoryview objects officially immutable, then we can avoid that by shortcutting the chaining with a typecheck on the referenced object (i.e. call GetBuffer on the source object directly if it is a memoryview, but on the memoryview we're copying otherwise)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 23:20:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Feb 2011 22:20:20 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297635620.25.0.104833943252.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I should note that the idea of using a Py_buffer's "internal" field as the unique ID rather than the Py_buffer's address does have some merit, but I still overall prefer a design that places fewer constraints on API consumers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sun Feb 13 23:33:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Feb 2011 22:33:44 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297634465.58.0.479885788421.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297636420.3802.72.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm still not comfortable with a convention that relies on *clients*
> of the PEP 3118 API not mucking with the internals of the Py_buffer
> struct.

Which clients? Those who export the buffer, or those who consume it?

> I'm *much* happier with the rule based on malloc/free semantics where
> the *pointer* passed to PyObject_GetBuffer must match a single later
> call to PyObject_ReleaseBuffer.

Agreed that Py_buffer should have been a PyObject from the start, but
the PEP chose differently.

We now have backwards compatibility constraints. What do we do with
PyMemoryView_FromBuffer? Also, there's probably some code out there that
likes to copy Py_buffers around.

> As far as the question of re-exporting the underlying view or not
> goes, I agree having "memoryview(a)" potentially refer to different
> underlying memory from "a" itself (because the source object has
> changed since the first view was exported) is a recipe for confusion.

If an object changes its buffer while it's exported somewhere, it will
always result in confusion for the user, regardless of how the
memoryview object is implemented. All normal uses of the buffer API
assume that the buffer's memory doesn't change while it's being accessed
by its consumer (what would it mean to SHA1-hash or zlib-compress a
changing piece of memory?).
So I don't know why the memoryview object *in particular* should care
about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 00:04:56 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 13 Feb 2011 23:04:56 +0000
Subject: [issue11208] example misprint in documentation whatsnew/3.2
In-Reply-To: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>
Message-ID: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>


New submission from July Tikhonov <july.tikh at gmail.com>:

>>> list(accumulate(8, 2, 50))

fails. Correct version is

>>> list(accumulate([8, 2, 50]))

----------
assignee: docs at python
components: Documentation
files: whatsnew.3.2.accumulate.example.diff
keywords: patch
messages: 128529
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: example misprint in documentation whatsnew/3.2
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20757/whatsnew.3.2.accumulate.example.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11208>
_______________________________________

From report at bugs.python.org  Mon Feb 14 00:41:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Feb 2011 23:41:54 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1297640514.25.0.145998269475.issue11205@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

How much to change and how far to backport may make for a good python-dev discussion.  

ISTM that changing generated code goes hand-in-hand with changing opcode semantics (as long as the magic number gets bumped).  OTOH, none of this may be worth backporting at all since no one seems to have noticed or cared for eight years.   

I don't have any feelings about it one way or the other, but it would great to see Py3.2.1 get fixed properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Mon Feb 14 01:08:02 2011
From: report at bugs.python.org (David Knapp)
Date: Mon, 14 Feb 2011 00:08:02 +0000
Subject: [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1297642082.21.0.751809081875.issue11207@psf.upfronthosting.co.za>


David Knapp <psychicsurgeon at gmail.com> added the comment:

Sorry I'm not all that experienced with gdb. Let me know if there's more to get.

(gdb) bt
#0  _unaligned_strided_byte_copy (dst=0xcb9623 "\366\377\177", outstrides=1, src=
    0x7ffff3503da5 <Address 0x7ffff3503da5 out of bounds>, instrides=4969607, N=10000, elsize=<value optimized out>)
    at /usr/include/bits/string3.h:52
#1  0x00007ffff5ee2cca in _strided_buffered_cast (dptr=<value optimized out>, dstride=<value optimized out>, 
    delsize=<value optimized out>, dswap=<value optimized out>, dcopyfunc=<value optimized out>, sptr=<value optimized out>, 
    sstride=4969607, selsize=1, sswap=0, scopyfunc=0x7ffff5eec340 <UBYTE_copyswapn>, N=10000, buffers=0x7fffffffd7d0, 
    bufsize=10000, castfunc=0x7ffff5edbf30 <UBYTE_to_USHORT>, dest=0x9634a0, src=0xa3d7e0)
    at numpy/core/src/multiarray/convert_datatype.c:164
#2  0x00007ffff5ee2c66 in _strided_buffered_cast (dptr=<value optimized out>, dstride=<value optimized out>, 
    delsize=<value optimized out>, dswap=<value optimized out>, dcopyfunc=<value optimized out>, sptr=<value optimized out>, 
    sstride=4969607, selsize=1, sswap=0, scopyfunc=0x7ffff5eec340 <UBYTE_copyswapn>, N=13039280, buffers=0x7fffffffd7d0, 
    bufsize=10000, castfunc=0x7ffff5edbf30 <UBYTE_to_USHORT>, dest=0x9634a0, src=0xa3d7e0)
    at numpy/core/src/multiarray/convert_datatype.c:175
#3  0x00007ffff5f13337 in _broadcast_cast (out=0x9634a0, in=0xa3d7e0, castfunc=<value optimized out>, iswap=<value optimized out>, 
    oswap=<value optimized out>) at numpy/core/src/multiarray/convert_datatype.c:255
#4  0x00007ffff5f14e48 in _array_copy_into (dest=0x9634a0, src=0xa3d7e0, usecopy=<value optimized out>)
    at numpy/core/src/multiarray/ctors.c:861
#5  0x00007ffff5f16d3b in PyArray_FromArray (arr=0xa3d7e0, newtype=<value optimized out>, flags=<value optimized out>)
    at numpy/core/src/multiarray/ctors.c:2021
#6  0x00007ffff5f0f4ae in PyArray_FromAny (op=<bytearray at remote 0xb869f0>, newtype=0x7ffff61527e0, min_depth=0, max_depth=0, 
    flags=112, context=<value optimized out>) at numpy/core/src/multiarray/ctors.c:1785
#7  0x00007ffff5f214e6 in PyArray_CheckFromAny (op=<bytearray at remote 0xb869f0>, descr=0x7ffff61527e0, min_depth=-212845147, 
    max_depth=228, requires=112, context=<unknown at remote 0x1>) at numpy/core/src/multiarray/ctors.c:1934
#8  0x00007ffff5f2283a in _array_fromobject (__NPY_UNUSED_TAGGEDignored=<value optimized out>, args=<value optimized out>, 
    kws=<value optimized out>) at numpy/core/src/multiarray/multiarraymodule.c:1500
#9  0x00000000004a5ce4 in do_call (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in <module> (), 
    throwflag=<value optimized out>) at ../Python/ceval.c:3965
#10 call_function (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in <module> (), throwflag=<value optimized out>)
    at ../Python/ceval.c:3773
#11 PyEval_EvalFrameEx (f=Frame 0x91ac90, for file g19_framebuffer.py, line 121, in <module> (), throwflag=<value optimized out>)
    at ../Python/ceval.c:2412
#12 0x00000000004a6bd1 in PyEval_EvalCodeEx (co=0x7ffff7f06a80, globals=<value optimized out>, locals=<value optimized out>, args=
    0x0, argcount=<value optimized out>, kws=<value optimized out>, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at ../Python/ceval.c:3000
#13 0x00000000004a6ca2 in PyEval_EvalCode (co=0xcb9623, globals=<unknown at remote 0x1>, locals=<unknown at remote 0x7ffff3503da5>)
    at ../Python/ceval.c:541
#14 0x00000000004c702e in run_mod (fp=<value optimized out>, filename=0x7fffffffe232 "g19_framebuffer.py", 
    start=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, closeit=1, flags=0x7fffffffde30)
    at ../Python/pythonrun.c:1351
#15 PyRun_FileExFlags (fp=<value optimized out>, filename=0x7fffffffe232 "g19_framebuffer.py", start=<value optimized out>, 
    globals=<value optimized out>, locals=<value optimized out>, closeit=1, flags=0x7fffffffde30) at ../Python/pythonrun.c:1337
#16 0x00000000004c7244 in PyRun_SimpleFileExFlags (fp=<value optimized out>, filename=0x7fffffffe232 "g19_framebuffer.py", 
    closeit=1, flags=0x7fffffffde30) at ../Python/pythonrun.c:941
#17 0x00000000004180c1 in Py_Main (argc=-135348096, argv=<value optimized out>) at ../Modules/main.c:577
#18 0x00007ffff69dad8e in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffdf48)
    at libc-start.c:226
#19 0x00000000004172c9 in _start ()


If it matters, I figured out I was trying to do what I was doing incorrectly. So I've found a better way to do it. 

The problem is specific to the bytearray() here, so it could very well be a problem with either bytearray or numpy.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11207>
_______________________________________

From report at bugs.python.org  Mon Feb 14 01:20:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 00:20:09 +0000
Subject: [issue11207] Pythong seg fault with PIL/numpy
In-Reply-To: <1297634163.23.0.527834418081.issue11207@psf.upfronthosting.co.za>
Message-ID: <1297642809.05.0.29785708157.issue11207@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Judging from the traceback, you should probably report that issue to numpy instead.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11207>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:18:49 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:18:49 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297649929.41.0.729620204574.issue7330@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file18305/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:18:54 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:18:54 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297649934.73.0.517676071442.issue7330@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file19132/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:18:59 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:18:59 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297649939.42.0.211907337026.issue7330@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20731/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:22:41 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:22:41 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297650161.23.0.22985861127.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file18402/issue8634.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:22:45 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:22:45 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297650165.6.0.302287969001.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file19987/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Mon Feb 14 03:22:50 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 02:22:50 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297650170.17.0.575932067502.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20726/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Mon Feb 14 04:07:28 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 03:07:28 +0000
Subject: [issue1635741] Interpreter seems to leak references after finalization
Message-ID: <1297652848.01.0.246706859163.issue1635741@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Feb 14 06:17:50 2011
From: report at bugs.python.org (Johannes Ammon)
Date: Mon, 14 Feb 2011 05:17:50 +0000
Subject: [issue11209] Example for itertools.count is misleading
In-Reply-To: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>
Message-ID: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>


New submission from Johannes Ammon <johannes.ammon at gmail.com>:

The example code for itertools.count (http://docs.python.org/library/itertools.html#itertools.count) says 

    # count(2.5, 0.5) -> 3.5 3.0 4.5 ...

I think that should read

    # count(2.5, 0.5) -> 2.5 3.0 3.5 ...

----------
assignee: docs at python
components: Documentation
messages: 128533
nosy: docs at python, jammon
priority: normal
severity: normal
status: open
title: Example for itertools.count is misleading
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11209>
_______________________________________

From report at bugs.python.org  Mon Feb 14 06:56:57 2011
From: report at bugs.python.org (Alex)
Date: Mon, 14 Feb 2011 05:56:57 +0000
Subject: [issue11209] Example for itertools.count is misleading
In-Reply-To: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>
Message-ID: <1297663017.85.0.994724659053.issue11209@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Patch for 2.7.

----------
keywords: +patch
nosy: +alex
Added file: http://bugs.python.org/file20758/python-11209.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11209>
_______________________________________

From report at bugs.python.org  Mon Feb 14 07:05:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Feb 2011 06:05:34 +0000
Subject: [issue11209] Example for itertools.count is misleading
In-Reply-To: <1297660670.65.0.462812812654.issue11209@psf.upfronthosting.co.za>
Message-ID: <1297663534.19.0.301948093353.issue11209@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in 2.7 and 3.1.
Was already fixed in 3.2.
Thanks for the report.

----------
nosy: +rhettinger
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11209>
_______________________________________

From report at bugs.python.org  Mon Feb 14 07:58:55 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 14 Feb 2011 06:58:55 +0000
Subject: [issue3710] Reference leak in thread._local
In-Reply-To: <1219882144.91.0.399316525956.issue3710@psf.upfronthosting.co.za>
Message-ID: <1297666735.74.0.680362424124.issue3710@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3710>
_______________________________________

From report at bugs.python.org  Mon Feb 14 11:15:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 10:15:21 +0000
Subject: [issue11210] PyErr_SetFromWindowsErrWithFilenameObject() doesn't
	exist: remove it from pyerrors.h
In-Reply-To: <1297678521.8.0.172330383513.issue11210@psf.upfronthosting.co.za>
Message-ID: <1297678521.8.0.172330383513.issue11210@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyAPI_FUNC(PyObject *) PyErr_SetFromWindowsErrWithFilenameObject(int, const char *); has a strange prototype: "FilenameObject" usually indicates a PyObject* argument, not a char* argument. The function doesn't exist in Python/errors.c, but there is a PyErr_SetExcFromWindowsErrWithFilenameObject() function.

PyErr_SetFromWindowsErrWithFilenameObject() was introduced in pyerrors.h by r28999 (8 years ago), but I am unable to find any concrete implementation.


Attached patch removes PyErr_SetFromWindowsErrWithFilenameObject() from pyerrors.h.

----------
components: Interpreter Core, Unicode
files: pyerrors_h.patch
keywords: easy, patch
messages: 128536
nosy: haypo
priority: normal
severity: normal
status: open
title: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: remove it from pyerrors.h
versions: Python 3.3
Added file: http://bugs.python.org/file20759/pyerrors_h.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11210>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:11:54 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 11:11:54 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1297636420.3802.72.camel@localhost.localdomain>
Message-ID: <AANLkTimc8H8Ayiosr+x0KddMv-=enR+zQnHDxZyguOkg@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Mon, Feb 14, 2011 at 8:33 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>> I'm still not comfortable with a convention that relies on *clients*
>> of the PEP 3118 API not mucking with the internals of the Py_buffer
>> struct.
>
> Which clients? Those who export the buffer, or those who consume it?

Consumers. (I'll try to stick to provider/consumer terminology, as
that's clearer in this context

>> I'm *much* happier with the rule based on malloc/free semantics where
>> the *pointer* passed to PyObject_GetBuffer must match a single later
>> call to PyObject_ReleaseBuffer.
>
> Agreed that Py_buffer should have been a PyObject from the start, but
> the PEP chose differently.

malloc/free modelled semantics have *nothing* to do with Py_buffer
being a full PyObject in its own right. All I mean is that whatever
pointer you call ReleaseBuffer with should be the one you passed to
GetBuffer, and the only thing tp_releasebuffer implementations should
rely on is the address of that pointer rather than the struct
contents. However, from what Pauli has said, we may want to go with
the alternative approach of saying the struct address is irrelevant,
and only the content matter, using the "internal" field to
disambiguate different exported buffers. I believe either will work,
and either places additional constraints on buffer API consumers that
aren't currently clearly documented.

> We now have backwards compatibility constraints. What do we do with
> PyMemoryView_FromBuffer? Also, there's probably some code out there that
> likes to copy Py_buffers around.

Such code is likely to be broken regardless of how we clarify the
semantics, in the same way that our own dup_buffer is currently broken
under either set of semantics (i.e. calling ReleaseBuffer with a
different address in one case, clobbering the "internal" field in
other cases). We will probably need to expose an official Py_buffer
copying function that gets all the subtle details right so that
extension authors can more easily avoid making the same mistakes.

>> As far as the question of re-exporting the underlying view or not
>> goes, I agree having "memoryview(a)" potentially refer to different
>> underlying memory from "a" itself (because the source object has
>> changed since the first view was exported) is a recipe for confusion.
>
> If an object changes its buffer while it's exported somewhere, it will
> always result in confusion for the user, regardless of how the
> memoryview object is implemented. All normal uses of the buffer API
> assume that the buffer's memory doesn't change while it's being accessed
> by its consumer (what would it mean to SHA1-hash or zlib-compress a
> changing piece of memory?).
> So I don't know why the memoryview object *in particular* should care
> about this.

I'm not talking about an exported view changing its details (that's
explicitly disallowed by the PEP), I'm talking about the fact that
sequential calls to PyObject_GetBuffer are permitted to return
different answers. That's the point Pauli's PictureSet example
illustrated - even though the toy example uses a somewhat clumsy API,
it's perfectly legitimate according to the documentation, and it shows
that the current memoryview implementation may behave strangely when
you copy or slice a view of a mutable object, even though the view
itself is guaranteed to remain valid.

Consider the following:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: Existing exports of data: object cannot be re-sized

Now suppose that instead of disallowing the resize, bytearray (or a
similar object) permitted it by allocating a new memory buffer, while
keeping a reference to the old buffer around until the memoryview
releases it (an approach that is perfectly legitimate according to the
PEP). In that case, our current "use the source object" approach to
memoryview copying and slicing will backfire badly, since copies and
slices will be working off the *new* (empty) state of the object,
while the original memoryview will still be looking at the old
populated state. I think Pauli's right, we need to make memoryview
re-exporting significantly smarter in order to cope correctly with
mutable objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:29:16 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 11:29:16 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297682956.43.0.797434215545.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Another idea we may want to revisit is the PyManagedBuffer concept, which would be a true PyObject that existed solely to simplify sharing of Py_buffer structs.

If memoryview used such an object internally, then copying and slicing would be quite simple - just INCREF the managed buffer instance without letting the original source object know anything was going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 12:41:42 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 11:41:42 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297683702.78.0.921023517817.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, to summarise that revisit into a coherent proposal:

1. Add "PyManagedBuffer" as an even lower level wrapper around Py_buffer. The only thing this would support is doing GetBuffer on construction and ReleaseBuffer when destroyed (or when explicitly asked to do so), as well as access to the information in the Py_buffer struct.

2. Adjust PyMemoryView to use that object to access the source object that implements the PEP 3118 API.

3. When copying or slicing memoryview objects, the new PyMemoryView instance acquires a reference to the existing PyManagedBuffer instance instead of creating a new one.

4. If memoryview.release() attempts to explicitly release the buffer, but there are additional references to the PyManagedBuffer object, the request will fail with a BufferError.

5. dup_buffer is deleted (with extreme prejudice)

6. 3rd party code is encouraged in the C API documentation to never ever copy Py_buffer structs around and to use PyManagedBuffer instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:02:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 12:02:23 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297684943.84.0.84922549062.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On further reflection, I realised point 4 in that suggestion isn't reliable in a formal sense. Consider:

with memoryview(a) as m:
    m[:]

The slice won't reference the buffer again, but isn't guaranteed by the language definition to have been garbage collected at the time m.release() is called by the with statement.

Altering release() to simply decrement the reference count of the managed buffer would defeat the whole point of having that method, so it may be necessary to allow early release with outstanding references and then include a "still alive" check in the code that allows access to the buffer details (similar to the way weak references work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 13:28:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 12:28:58 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297686538.17.0.609880307441.issue11188@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>  File ".../Lib/test/test_time.py", line 351, in test_mktime
>    self.assertEqual(time.mktime(tt), t)
> OverflowError: mktime argument out of range

I don't know which values are "out of range". But I guess that the test fails because of t=-1, which would mean that tm_wday field is not modified by mktime().

I don't know if mktime() does really not support t=-1, or if we should use another sentinel. The original patch to fix this issue (support t=-1, issue #1726687) used tm_wday=42 instead of tm_wday=-1:

+	/* invalid value that will not be changed if there is an error. */
+	buf.tm_wday = 42;
 	tt = mktime(&buf);
-	if (tt == (time_t)(-1)) {
+	if ((tt == (time_t)(-1)) && (buf.tm_wday == 42)) {
 		PyErr_SetString(PyExc_OverflowError,
 				"mktime argument out of range");
 		return NULL;

The current code uses:

    buf.tm_wday = -1;  /* sentinel; original value ignored */                   
    tt = mktime(&buf);                                                          
    /* Return value of -1 does not necessarily mean an error, but tm_wday       
     * cannot remain set to -1 if mktime succedded. */                          
    if (tt == (time_t)(-1) && buf.tm_wday == -1) {                              
        PyErr_SetString(PyExc_OverflowError,                                    
                        "mktime argument out of range");                        
        return NULL;                                                            
    }                 


>  File ".../Lib/test/test_time.py", line 337, in test_negative
>    self.assertIn(text, ('-1', '-001'))
> AssertionError: '000/' not found in ('-1', '-001')

AIX doesn't support negative tm_year value. It should be added to the timemodule blacklist (#ifdef):

#if defined(_MSC_VER) || defined(sun)
    if (buf.tm_year + 1900 < 1 || 9999 < buf.tm_year + 1900) {
        PyErr_Format(PyExc_ValueError,
                     "strftime() requires year in [1; 9999]",
                     buf.tm_year + 1900);
        return NULL;
    }
#endif

I don't know if there is a reliable C define to check if the current OS is AIX (something like #ifdef sun). Python configure script checks if "uname -s" output starts with "AIX". We should maybe add a Python define in pyconfig.h using the configure script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:03:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 13:03:50 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <AANLkTimc8H8Ayiosr+x0KddMv-=enR+zQnHDxZyguOkg@mail.gmail.com>
Message-ID: <1297688626.3725.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >> I'm *much* happier with the rule based on malloc/free semantics where
> >> the *pointer* passed to PyObject_GetBuffer must match a single later
> >> call to PyObject_ReleaseBuffer.
> >
> > Agreed that Py_buffer should have been a PyObject from the start, but
> > the PEP chose differently.
> 
> malloc/free modelled semantics have *nothing* to do with Py_buffer
> being a full PyObject in its own right.

Well, the moment you're talking about having a struct of heterogeneous
fields whose address should remain identical, why not use the one
internal abstraction that is designed exactly for that, aka PyObject.
Sure you can devise an other ownership model, but what's the point?
I'm talking about avoiding NIH and an additional maintenance burden due
to avoidable cruft.

> > We now have backwards compatibility constraints. What do we do with
> > PyMemoryView_FromBuffer? Also, there's probably some code out there that
> > likes to copy Py_buffers around.
> 
> Such code is likely to be broken regardless of how we clarify the
> semantics,

Well, PyMemoryView_FromBuffer is used in the stdlib right now (in the IO
lib).

> I think Pauli's right, we need to make memoryview
> re-exporting significantly smarter in order to cope correctly with
> mutable objects.

Ok.

> 1. Add "PyManagedBuffer" as an even lower level wrapper around
> Py_buffer. The only thing this would support is doing GetBuffer on
> construction and ReleaseBuffer when destroyed (or when explicitly
> asked to do so), as well as access to the information in the Py_buffer
> struct.
> 
> 2. Adjust PyMemoryView to use that object to access the source object
> that implements the PEP 3118 API.

Ouch. Why not fold all that directly into memoryview? A third
abstraction for support of what is supposed to be a simple API sounds 
too much.
(see, if Py_buffer was a PyObject, we'd have only one abstraction)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:23:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 13:23:55 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297689835.53.0.256193427194.issue11193@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I don't understand why the test pass on FreeBSD, Solaris and
> Mac OS X, but not on AIX.

Oh, the command line and the filesystem encodings may be different. test_undecodable_env() of test_subprocess.py uses os.environ which uses sys.getfilesystemencoding(), whereas test_undecodable_code() of test_cmd_line.py uses _Py_char2wchar() which uses mbstowcs() functions (which use the locale encoding).

sys.getfilesystemencoding() is initialized from nl_langinfo(CODESET).

nl_langinfo(CODESET) gives maybe "ISO-8859-1" (or an alias to this encoding) even if LC_ALL=C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:49:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 13:49:03 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297691343.35.0.941797889047.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The managed buffer needs to be a separate object so that multiple memoryview objects can share it. Essentially, we would end up with two APIs - the raw Py_buffer API and the higher level PyManagedBuffer one.

C extensions would have the choice of using the low level API (most likely the case for existing extensions) or making life easier for themselves by using the higher level one. It is, at least from the consumer side, almost exactly what you suggested in the first place: a PEP 3118 style API where the main interface object is a true PyObject instance. Providers will still need to deal with correctly populating the passed in Py_buffer instances, but that can be handled easily enough by storing exported managed buffers in a Python list and storing indices in the Py_buffer internal field.

PyMemoryView itself isn't appropriate as that higher level API, since it does a lot more than just provide an easy way to share a Py_buffer struct (specifically, thanks to slicing, a memoryview instance may not expose the entire underlying buffer). Managed buffers would be much simpler, simply providing read-only access to the fields of the managed Py_buffer struct.

Depending on how we end up defining the required consumer semantics, PyMemoryView_FromBuffer may or may not be fully salvageable. If we find dup_buffer semantics that are universally correct, then we may be able to keep it in its current form by building those into an alternate ManagedBuffer constructor, otherwise we may need to restrict it to cases where the obj field is NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:54:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Feb 2011 13:54:01 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1297691641.62.0.57961823023.issue670664@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue670664>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:54:58 2011
From: report at bugs.python.org (Fabian Groffen)
Date: Mon, 14 Feb 2011 13:54:58 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297691698.15.0.544780086951.issue7305@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

I can reproduce this on Solaris 10/Sparc64 only, using Python 2.7.1.  My core files aren't really useful though, nothing it can point to, everything is corrupt.

----------
nosy: +grobian
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Mon Feb 14 14:57:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Feb 2011 13:57:01 +0000
Subject: [issue11208] example misprint in documentation whatsnew/3.2
In-Reply-To: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>
Message-ID: <1297691821.83.0.939201610538.issue11208@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11208>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:03:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Feb 2011 14:03:10 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297692190.55.0.441884504461.issue10181@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If it helps, one way to think of it is that post-redesign, the PyManagedBuffer would be the "real" API object, with Py_buffer merely a way for data exporters to provide the information needed to initialise the managed buffer properly. (That actually fairly accurately tracks the origin of the Py_buffer struct - to avoid huge numbers of output variables in the GetBuffer API calls)

Is such a solution ideal? No, but it would be significantly better than what we have now. If the PEP had been implemented as written, we would also have been much better off, but given that we failed to pick up the discrepancies between spec and implementation at the time, we're now stuck with trying to improve the situation without breaking backwards compatibility.

Since I now agree with your diagnosis that the heart of the problem is the fact that Py_buffer contains lots of pointers and thus is difficult to copy safely, wrapping it in a PyObject (without adding any additional behaviour) in order to minimise copying seems like the most obvious solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:04:43 2011
From: report at bugs.python.org (Fabian Groffen)
Date: Mon, 14 Feb 2011 14:04:43 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297692283.83.0.509683657459.issue7305@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

Perhaps I should have been a bit more clear.  Python 2.6 works fine for me on Solaris 10/Sparc64 (64-bits).  Python 2.7.1 also works on Solaris 10/Sparc (32-bits), but not on Sparc64 (64-bits).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:25:18 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 14:25:18 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297693518.0.0.143037062233.issue11193@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I am not sure this is what you want:

> LC_ALL=C ./python
Python 3.2rc3 (py3k:88417M, Feb 14 2011, 10:37:42) 
[GCC 4.2.0] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getfilesystemencoding()
'iso8859-1'
>>> 

What information can I provide to help solve this bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Mon Feb 14 15:32:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 14:32:25 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297693945.03.0.580522341252.issue11193@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>>> sys.getfilesystemencoding()
'iso8859-1'

Ok, I expected this result.

Can you also try:

$ LC_ALL=C ./python -c "import sys; print(ascii(sys.argv))" $(echo -ne "abc\xff")
['-c', 'abc\udcff']
$ LC_ALL=C python3.1 -c "import locale; print(locale.nl_langinfo(locale.CODESET))"
ANSI_X3.4-1968
$ LC_ALL=C python3.1 -c "import locale; print(locale.getpreferredencoding())"
ANSI_X3.4-1968

Anyway, test_undecodable_env() is not written to support ISO-8859-1 filesystem encoding. I should patch the test to check the filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:08:19 2011
From: report at bugs.python.org (Toni Mueller)
Date: Mon, 14 Feb 2011 15:08:19 +0000
Subject: [issue11211] gzip.open() fails for gzipped file
In-Reply-To: <1297696099.3.0.962769507979.issue11211@psf.upfronthosting.co.za>
Message-ID: <1297696099.3.0.962769507979.issue11211@psf.upfronthosting.co.za>


New submission from Toni Mueller <tonimueller at users.sourceforge.net>:

I have files that I would like to read with Python, but can't:

$ python jmlreader.py woerter-allg.jml
Traceback (most recent call last):
  File "jmlreader.py", line 14, in <module>
    readFile(sys.argv[1])
  File "jmlreader.py", line 10, in readFile
    for line in f:
  File "/usr/lib/python2.6/gzip.py", line 438, in next
    line = self.readline()
  File "/usr/lib/python2.6/gzip.py", line 393, in readline
    c = self.read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 219, in read
    self._read(readsize)
  File "/usr/lib/python2.6/gzip.py", line 255, in _read
    self._read_gzip_header()
  File "/usr/lib/python2.6/gzip.py", line 156, in _read_gzip_header
    raise IOError, 'Not a gzipped file'
IOError: Not a gzipped file

The file itself is a gzipped file, though: 

$ gzip -cd woerter-allg.jml|head
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Lesson>
<Category name="All">
<Deck>
<Card AmountLearnedBack="0" AmountLearnedFront="0" Backside="yu3 yan2  (zhong3)&#10;&#10;Sprache" DateCreated="02-Mar-2009 16:05:15" DateModified="02-Mar-2009 16:05:15" DateTouched="02-Mar-2009 16:05:15" Frontside="?????" TestsHit="0" TestsTotal="0">
<Side/>
<Side/>
</Card>
<Card AmountLearnedBack="0" AmountLearnedFront="0" Backside="shu4&#10;&#10;Baum, pflanzen, hervorbringen" DateCreated="02-Mar-2009 16:06:26" DateModified="02-Mar-2009 16:06:49" DateTouched="02-Mar-2009 16:06:26" Frontside=" ?" TestsHit="0" TestsTotal="0">
<Side/>

Unfortunately, the file is a bit weird:

$ file woerter-allg.jml
woerter-allg.jml: Zip archive data, at least v2.0 to extract

Rewriting the program with zlib, instead of gzip, didn't help a bit:

$ python jmlreader.py woerter-allg.jml.gz 
Traceback (most recent call last):
  File "jmlreader.py", line 15, in <module>
    readFile(sys.argv[1])
  File "jmlreader.py", line 11, in readFile
    unc = zlib.decompress(s)
zlib.error: Error -3 while decompressing data: incorrect header check


IOW, the file was actually compressed with gzip, not zip.

It would be nice if the gzip module could read the file. I've attached a file that reproduces the problem.

----------
components: Extension Modules
files: test.jml
messages: 128550
nosy: tonimueller
priority: normal
severity: normal
status: open
title: gzip.open() fails for gzipped file
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20760/test.jml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11211>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:13:22 2011
From: report at bugs.python.org (Pauli Virtanen)
Date: Mon, 14 Feb 2011 15:13:22 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297696402.36.0.412718898483.issue10181@psf.upfronthosting.co.za>


Pauli Virtanen <pav at iki.fi> added the comment:

Nick's plan of action above seems mostly OK to me.

Though, it might be simpler to collapse the PyManagedBuffer object to PyMemoryView, even if this requires memoryviews to serve two purposes.

[Nick:]
> I'm still not comfortable with a convention that relies on *clients*
> of the PEP 3118 API not mucking with the internals of the Py_buffer
> struct.

Some points against: (i) Having to look up keys by memory address from an additional PyDict is more work for the exporter than just passing around some PyMem_Malloc'd information in `internal`. (ii) There is already an "obj" field in the structure that the consumers are supposed to not mess with. (iii) The exporter cannot use the `internal` field for anything if bf_releasebuffer cannot rely on it being intact.

If the recommended consumer API is changed so that Py_buffer mainly sits inside a PyObject, it becomes more clear that Py_buffer is read-only for the consumer (-- which is what I believe the PEP intended, but did not write down).

[Nick:]
> Altering release() to simply decrement the reference count of the 
> managed buffer would defeat the whole point of having that method, so
> it may be necessary to allow early release with outstanding references
> and then include a "still alive" check in the code that allows access
> to the buffer details (similar to the way weak references work).

Early release does not seem possible if the buffer does not come from the original object:

    lst = []
    with memoryview(a) as m:
        b = numpy.array(m)
        lst.append(b)

Now, m.__exit__ cannot release the buffer, since `b` holds a buffer-interface lock to `m`. `b` is 3rd party code, and does not know anything about MemoryViews.

Some alternatives: (i) require that bf_getbuffer always gives a new lock on all exported buffers, if there are multiple, (ii) allow memoryview.__exit__ to fail silently, (iii) drop the context management.

I guess (i) would be a sane choice -- I don't see many use cases for the same object exporting multiple different buffers. It's not needed by Numpy, and I suspect there is no existing 3rd party code that relies on this (because it doesn't work with the current implementation of memoryview :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:15:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 15:15:17 +0000
Subject: [issue11211] gzip.open() fails for gzipped file
In-Reply-To: <1297696099.3.0.962769507979.issue11211@psf.upfronthosting.co.za>
Message-ID: <1297696517.37.0.950855172079.issue11211@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test.jml is a ZIP archive, not a gzip archive.

"gzip -d" is kind enough to unpack it even if it is ZIP file and not a gzip file.

So it's not a Python bug at all.

----------
nosy: +haypo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11211>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:31:15 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 15:31:15 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

On AIX, executables are compiled by default so that they cannot allocate more than 256MB of memory.

This is not enough in some cases; for example this is not enough to get the Python test suite to run completely.

As explained in IBM documentation:

By default each program gets one segment register (see 2.24) for its
data segment. As each segment register covers 256 MB, any calls to
malloc more will fail. Also programs that declare large global or static
arrays may fail to load. To allocate more segment registers to your
program, use the linker option -bmaxdata to specify the number of bytes
you need in the data segment as follows:

cc -o myprog -bmaxdata:0x20000000 myprog.c

The example above would allocate an additional segment register to allow
for 512MB of data.

export LDR_CNTRL=MAXDATA=0x20000000
start_process
unset LDR_CNTRL

Marking An Executable For Large Page Use
The XCOFF header in an executable file contains a new flag to indicate that the program wants to use
large pages to back its data and heap segments. This flag can be set when the application is linked by
specifying the -blpdata option on the ld command. The flag can also be set or cleared using the ldedit
command. The "ldedit -blpdata filename" command sets the large page data/heap flag in the specified
file. The "ldedit -bnolpdata filename" clears the large page flag. The ldedit command may also be used
to set an executable's maxdata value

----------
components: Build
messages: 128553
nosy: sable
priority: normal
severity: normal
status: open
title: Python memory limit on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:38:09 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 15:38:09 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297697889.85.0.535393655705.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a patch that would provide an --enable-aix-maxdata option to configure, in order to support 512MB of mermory.

I have not tested it yet.

----------
keywords: +patch
Added file: http://bugs.python.org/file20761/patch_maxdata.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Mon Feb 14 16:56:44 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 15:56:44 +0000
Subject: [issue11193] test_subprocess error on AIX
In-Reply-To: <1297438101.89.0.389896513062.issue11193@psf.upfronthosting.co.za>
Message-ID: <1297699004.19.0.169597321967.issue11193@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

$ LANG=C ./python -Wd -E -bb -c "import sys; print(ascii(sys.argv))" $(echo -ne "abc\xff")['-c', 'abc\xff']
['-c', 'abc\xff']
$ LANG=C ./python -Wd -E -bb -c "import locale; print(locale.nl_langinfo(locale.CODESET))"
ISO8859-1
$ LANG=C ./python -Wd -E -bb -c "import locale; print(locale.getpreferredencoding())"
ISO8859-1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11193>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:48:01 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 16:48:01 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297702081.83.0.612100426261.issue11188@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I tried the following patch (_AIX is defined on AIX platforms):

Index: Modules/timemodule.c
===================================================================
--- Modules/timemodule.c	(r?vision 88420)
+++ Modules/timemodule.c	(copie de travail)
@@ -474,7 +474,7 @@
     else if (!gettmarg(tup, &buf) || !checktm(&buf))
         return NULL;
 
-#if defined(_MSC_VER) || defined(sun)
+#if defined(_MSC_VER) || defined(sun) || defined(_AIX)
     if (buf.tm_year + 1900 < 1 || 9999 < buf.tm_year + 1900) {
         PyErr_Format(PyExc_ValueError,
                      "strftime() requires year in [1; 9999]",
@@ -694,11 +694,12 @@
     time_t tt;
     if (!gettmarg(tup, &buf))
         return NULL;
-    buf.tm_wday = -1;  /* sentinel; original value ignored */
+    /* invalid value that will not be changed if there is an error. */
+    buf.tm_wday = 42;
     tt = mktime(&buf);
     /* Return value of -1 does not necessarily mean an error, but tm_wday
      * cannot remain set to -1 if mktime succedded. */
-    if (tt == (time_t)(-1) && buf.tm_wday == -1) {
+    if ((tt == (time_t)(-1)) && (buf.tm_wday == 42)) {
         PyErr_SetString(PyExc_OverflowError,
                         "mktime argument out of range");
         return NULL;

This resulted in the following:
======================================================================
ERROR: test_mktime (__main__.TestAsctime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (__main__.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_mktime (__main__.Test4dyearBool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 351, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

----------------------------------------------------------------------
Ran 42 tests in 1.395s

FAILED (errors=3)

So test_negative is now OK, but tm_wday = 42 did not solve the problem it seems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon Feb 14 17:49:05 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 16:49:05 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1297702145.97.0.713236991021.issue9920@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is the result after applying that patch:

======================================================================
FAIL: test_specific_values (__main__.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_cmath.py", line 380, in test_specific_values
    msg=error_message)
  File "Lib/test/test_cmath.py", line 128, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: atanh0225: atanh(complex(-0.0, 5.6067e-320))
Expected: complex(-0.0, 5.6067e-320)
Received: complex(0.0, 5.6067e-320)
Received value insufficiently close to expected value.

----------------------------------------------------------------------
Ran 16 tests in 0.081s

FAILED (failures=1, skipped=2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:09:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:09:05 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297703345.85.0.145623064222.issue11212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't see why we would provide an option to replace a magic number with another magic number. I find it strange that AIX doesn't simply enable unbounded virtual address spaces.
(by "unbounded" I mean "bounded by CPU limitations only")

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:12:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:12:56 +0000
Subject: [issue11213] distutils2 test issue
In-Reply-To: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>
Message-ID: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Just to test that auto-nosy works.

----------
assignee: tarek
components: Distutils2
messages: 128559
nosy: alexis, eric.araujo, pitrou, tarek
priority: normal
severity: normal
status: open
title: distutils2 test issue
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11213>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:13:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:13:14 +0000
Subject: [issue11213] distutils2 test issue
In-Reply-To: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>
Message-ID: <1297703594.97.0.257798213457.issue11213@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, works fine!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11213>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:23:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 17:23:36 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297704216.83.0.675566536267.issue11188@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> So test_negative is now OK

Ok, I converted your comment to a patch: strftime_aix.patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file20762/strftime_aix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:29:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 17:29:30 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297704570.4.0.16890971378.issue11188@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> but tm_wday = 42 did not solve the problem it seems.

Can you try with tm_yday=-1 or tm_isdst=-2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:36:09 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 17:36:09 +0000
Subject: [issue11214] test_asyncore fails on AIX
In-Reply-To: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>
Message-ID: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

When running test_asyncore on AIX, I get the following error:

[122/337] test_asyncore
test test_asyncore failed -- Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_asyncore.py", line 332, in test_strerror
    self.assertIn("unknown error", err.lower())
AssertionError: 'unknown error' not found in 'error -1 occurred.'

I haven't investigated yet.

----------
messages: 128563
nosy: sable
priority: normal
severity: normal
status: open
title: test_asyncore fails on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11214>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:39:10 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 17:39:10 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

I have the following error when running test_fileio on AIX:

======================================================================
FAIL: testAbles (test.test_fileio.OtherFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/test_fileio.py", line 269, in testAbles
    self.assertEqual(f.seekable(), False)
AssertionError: True != False

----------------------------------------------------------------------
Ran 34 tests in 0.032s

FAILED (failures=1)

I haven't investigated yet.

----------
messages: 128564
nosy: sable
priority: normal
severity: normal
status: open
title: test_fileio error on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11215>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:39:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:39:29 +0000
Subject: [issue11214] test_asyncore fails on AIX
In-Reply-To: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>
Message-ID: <1297705169.5.0.593601420477.issue11214@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11214>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:42:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Feb 2011 17:42:19 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297704570.4.0.16890971378.issue11188@psf.upfronthosting.co.za>
Message-ID: <AANLkTinYuMzKOy98TqN4G7Ax0n8Am0igWK6sVKM2mszD@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have come across the following post:

http://code.google.com/p/y2038/wiki/AmazingDiscoveries

I think some of the findings there may be relevant as we push the
boundaries of supported time values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:42:52 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:42:52 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1297705372.78.0.830980857275.issue11215@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks vaguely similar to http://bugs.python.org/issue6236#msg91007, although the latter has been fixed.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11215>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:48:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 14 Feb 2011 17:48:55 +0000
Subject: [issue11214] test_asyncore fails on AIX
In-Reply-To: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>
Message-ID: <1297705735.59.0.25683015845.issue11214@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'd say the test can be removed. It's not really important.

----------
assignee:  -> giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11214>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:51:31 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 14 Feb 2011 17:51:31 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297705891.08.0.221111349646.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes, welcome into the strange world of AIX...

You can allow up to 8 segments, which represent 2GB:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame3.doc_5.1/am51_perftune113.htm

We could change the option to become:
--with-aix-maxdata=value
where value could be between 0 and 8, with a default at 0 (nothing passed to the compiler).

Would that be OK with you?

The good news is that thanks to this patch I was able to play the full python test suite on AIX:

313 tests OK.
8 tests failed:
    test_asyncore test_cmath test_distutils test_fileio test_locale
    test_resource test_time test_wait4
16 tests skipped:
    test_ctypes test_curses test_dbm_gnu test_epoll test_gdb
    test_kqueue test_largefile test_ossaudiodev test_pep277
    test_startfile test_tk test_ttk_guionly test_unicode_file
    test_winreg test_winsound test_zipfile64

Not too bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Mon Feb 14 18:58:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Feb 2011 17:58:04 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297705891.08.0.221111349646.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297706280.3725.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> We could change the option to become:
> --with-aix-maxdata=value
> where value could be between 0 and 8, with a default at 0 (nothing
> passed to the compiler).

Doesn't LDFLAGS work for that? I don't think we want a lot of
platform-specific options like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Mon Feb 14 19:21:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Feb 2011 18:21:16 +0000
Subject: [issue11208] example misprint in documentation whatsnew/3.2
In-Reply-To: <1297638296.9.0.737008909299.issue11208@psf.upfronthosting.co.za>
Message-ID: <1297707676.76.0.64874622395.issue11208@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.
Thank for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11208>
_______________________________________

From report at bugs.python.org  Mon Feb 14 19:42:31 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Mon, 14 Feb 2011 18:42:31 +0000
Subject: [issue11213] distutils2 test issue
In-Reply-To: <1297703576.68.0.79511908701.issue11213@psf.upfronthosting.co.za>
Message-ID: <1297708951.27.0.905957982417.issue11213@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

yeah, thanks for that !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11213>
_______________________________________

From report at bugs.python.org  Mon Feb 14 21:05:09 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Feb 2011 20:05:09 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1297713909.81.0.0879706673481.issue11171@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Fixed in release27-maint: r88422

I am unable to reproduce in Python 3.1 (which does not have the sysconfig module) or 3.2 (which uses a different build-flags specific location for its Makefile).

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Mon Feb 14 21:26:19 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Mon, 14 Feb 2011 20:26:19 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>


New submission from Shay Rojansky <roji at roji.org>:

This may be my misunderstanding of the correct behavior, thanks in advance for your patience...

The issue happens when calling set_charset (or set_payload charset) after a Message has already been created and contains a Content-Transfer-Encoding header. Here's an example:

>>> from email.mime.text import MIMEText
>>> 
>>> part = MIMEText('Some stuff a????a', 'plain', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:17 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

U29tZSBzdHVmZiBhw6nDoMOnw6dh

>>> part.set_payload('Other stuff a????a', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:25 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

Other stuff a????a
>>> 
>>> del part['Content-Transfer-Encoding']
>>> part.set_payload('Still some other stuff a????a', 'utf-8')
>>> print part
>From nobody Mon Feb 14 19:57:40 2011
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

U3RpbGwgc29tZSBvdGhlciBzdHVmZiBhw6nDoMOnw6dh

First the text part is created with charset UTF-8, a dump shows a properly-encoded base64 UTF-8 part.

Then an attempt is made to modify the payload. The set_charset documentation clearly states that the message will be properly encoded/converted, but we get a malformed part with Content-Transfer-Endogin=base64 but without a base64-encoded payload.

Finally, as a workaround, I delete the Content-Transfer-Encoding header and try again, at which point the new payload is properly encoded.

Again, I'm sure there are reasons for this behavior, which nevertheless seems like a bug to me (shouldn't set_charset perform base64 and change the Content-Transfer-Encoding if necessary regardless of previous headers?). Maybe a documentation update would help people with this.

Thank you very much!

----------
components: Library (Lib)
messages: 128573
nosy: Shay.Rojansky
priority: normal
severity: normal
status: open
title: email.message.Message set_charset does not encode properly?
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Mon Feb 14 21:37:39 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Mon, 14 Feb 2011 20:37:39 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1297715859.96.0.933692815272.issue11216@psf.upfronthosting.co.za>


Shay Rojansky <roji at roji.org> added the comment:

Sorry, the "print part" below doesn't work on Python3 (I'm back in 2.6), but I see the same trouble by using part.__str__()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Mon Feb 14 21:58:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Feb 2011 20:58:58 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1297717138.38.0.730614544371.issue11216@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the docs don't say that the headers will be removed or modified as needed, only added as needed ;/.  And in fact the set_charset code does "if 'Content-Transfer-Encoding' not in self".  set_payload also says it is the caller's responsibility to "maintain the payload's invariants".  I'm not sure what that means, but I suspect it means making sure it is consistent with any existing Content-Transfer-Encoding header.

So it looks to me like this is (a) a doc bug and (b) an API bug(*).  The latter can only be corrected in 3.3.

I'm open to argument that this should be treated as a code bug, but that argument needs to include reasons why fixing it would not cause backward incompatibility problems.

Although I assigned this to myself so I don't lose it, a proposed documentation patch would be welcome.

(*) I say an API bug because my guess is that the API works the way it does on the theory that a program might be updating an existing Message object and should in that instance change only what it is directed to change (the payload content, and the charset attribute if specified), even if that would produce an invalid Message.  The way the email package evolved this would make sense, but I think if we were (when we are) doing it over now a better API would be to maintain a valid Message object through the standard API and provide a "lower level" API for those programs needing to produce RFC-invalid messages for whatever reason.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Mon Feb 14 22:15:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 14 Feb 2011 21:15:10 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1297718110.7.0.917559589765.issue10181@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Mon Feb 14 22:23:05 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 14 Feb 2011 21:23:05 +0000
Subject: [issue9960] test_structmembers fails on s390x (bigendian 64-bit):
	int/Py_ssize_t issue
In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>
Message-ID: <1297718585.58.0.765638756362.issue9960@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, this regressed in 2.6.6 relative to 2.6.5, due to r79646 adding the T_STRING_INPLACE test code to the 2.6 branch.

Note to self: https://bugzilla.redhat.com/show_bug.cgi?id=677392

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9960>
_______________________________________

From report at bugs.python.org  Tue Feb 15 00:01:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Feb 2011 23:01:02 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297724462.88.0.414691167249.issue11188@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> http://code.google.com/p/y2038/wiki/AmazingDiscoveries

<<< AIX again

Merijn informs me that before year 0 AIX gets very, very slow. >>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 06:59:09 2011
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 15 Feb 2011 05:59:09 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>


New submission from Tom Loredo <loredo at astro.cornell.edu>:

When building a universal framework Python-2.7.1 with homebrew on 10.6.6, python-32 (and its target, python2.7-32) are built and installed in the framework executable path, but they are not linked in /usr/local/bin.  msg101156 in Issue 8089 recognized this as a general MacPython problem in a 2.6.5 release candidate but deferred a fix for 2.6.6.  Apparently the fix was never implemented, or perhaps it was decided the link was not appropriate.  It seems to me it *is* appropriate (framework users don't currently have easy command-line access to python-32), but I defer to the experts!

----------
assignee: ronaldoussoren
components: Macintosh
messages: 128578
nosy: ronaldoussoren, tloredo
priority: normal
severity: normal
status: open
title: python-32 not linked in /usr/local/bin in framework builds
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Tue Feb 15 09:33:27 2011
From: report at bugs.python.org (Martin von Gagern)
Date: Tue, 15 Feb 2011 08:33:27 +0000
Subject: [issue11218] pattern=None when following documentation for load_tests
	and unittest.main()
In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>
Message-ID: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za>


New submission from Martin von Gagern <Martin.vGagern at gmx.net>:

If I follow the documentation at http://docs.python.org/library/unittest.html#unittest.main by putting the following two snippets of code in my module file:

def load_tests(loader, standard_tests, pattern='test*.py'):
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
    standard_tests.addTests(package_tests)
    return standard_tests

if __name__ == "__main__":
    unittest.main()

then the application will fail with an obscure error message:

======================================================================
ERROR: __main__ (unittest.loader.LoadTestsFailure)
----------------------------------------------------------------------
TypeError: object of type 'NoneType' has no len()

----------------------------------------------------------------------
Ran 1 test in 0.000s

Monkeypatching unittest.loader._make_failed_load_tests to display a stack trace, I got this:

Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 71, in loadTestsFromModule
    return load_tests(self, tests, None)
  File "tester.py", line 15, in load_tests
    package_tests = loader.discover(start_dir=this_dir, pattern=pattern)
  File "/usr/lib64/python2.7/unittest/loader.py", line 204, in discover
    tests = list(self._find_tests(start_dir, pattern))
  File "/usr/lib64/python2.7/unittest/loader.py", line 247, in _find_tests
    if not self._match_path(path, full_path, pattern):
  File "/usr/lib64/python2.7/unittest/loader.py", line 235, in _match_path
    return fnmatch(path, pattern)
  File "/usr/lib64/python2.7/fnmatch.py", line 43, in fnmatch
    return fnmatchcase(name, pat)
  File "/usr/lib64/python2.7/fnmatch.py", line 75, in fnmatchcase
    res = translate(pat)
  File "/usr/lib64/python2.7/fnmatch.py", line 87, in translate
    i, n = 0, len(pat)
TypeError: object of type 'NoneType' has no len()

The error is due to the fact that pattern is passed as None to load_tests, but apparently loader.discover doesn't loke a None pattern.

I would suggest that
a) discover internally translates None to the default of 'test*.py' or
b) the documentation is changed to cater for this common use case, i.e. by including a "pattern is None" case distinction in its load_tests snippet.

In case b) is implemented but not a), it would be nice to have a more expressive error message by catching the error somewhat sooner.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: tester.py
messages: 128579
nosy: docs at python, gagern
priority: normal
severity: normal
status: open
title: pattern=None when following documentation for load_tests and unittest.main()
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file20763/tester.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11218>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:29:48 2011
From: report at bugs.python.org (Fabian Groffen)
Date: Tue, 15 Feb 2011 09:29:48 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297762188.27.0.461935121612.issue7305@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

Sorry for the noise.  My issue seems to be caused by a broken openssl.  It is a specific problem with the code for sparcv9 and the T1 CPU.  Python can't do much about this.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:43:04 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 15 Feb 2011 09:43:04 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297762984.36.0.764302681346.issue7305@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the update on this issue.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 10:59:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 15 Feb 2011 09:59:29 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1297763969.16.0.996271367799.issue11217@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Taking a quick look at it, it appears that the Mac Makefile "installunixtools" target could/should create those links.  Note, this is not a problem for the standard OS X installers as Mac/BuildScript/build-installer.py (in buildPython) ensures that links are made in /usr/local/bin for all files in the framework bin directory at the end of the build.

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:05:33 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 15 Feb 2011 11:05:33 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1297767933.5.0.430918262106.issue11216@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Shay.Rojansky: because of the fact that i needed a free last saturday for just having the time to click around a bit to find the relevant docs in the python.org jungle ...

<http://wiki.python.org/moin/Email%20SIG> and *especially* <http://wiki.python.org/moin/Email%20SIG/DesignThoughts> may be of interest for you - read those when you are starting to think that it's you who is broken.  Nope!  It's really the package!

P.S.: sorry, David, i really didn't know, and somehow i also missed that single minute to look at bitdance.com.  But now i've found the docs and maybe here time is being worth enough for a broken package to be fixed,  the right way.  Then even more people can earn more money in a hurry - with it.  (It's only school english in the end.)

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:49:05 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 11:49:05 +0000
Subject: [issue877121] configure detects incorrect compiler optimization
Message-ID: <1297770545.21.0.66435207331.issue877121@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

If have the same issue with Oracle Studio 12.2 on Solaris 10 with Python 2.7.1:

....
cc -G -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -OPT:Olimit=0 -g -DNDEBUG -xO4 -I. -IInclude -I./Include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include/ncurses -I/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/include build/temp.solaris-2.10-sun4u-2.7/san_u10/home/recette/ssa/support-2.6.x/Python-2.7.1/Modules/_struct.o -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/usr/local/lib -L. -lpython2.7 -o build/lib.solaris-2.10-sun4u-2.7/_struct.so
cc: Warning: Option -OPT:Olimit=0 passed to ld, if ld is invoked, ignored otherwise
/usr/ccs/bin/ld: illegal option -- O
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s)

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue877121>
_______________________________________

From report at bugs.python.org  Tue Feb 15 12:57:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 11:57:45 +0000
Subject: [issue877121] configure detects incorrect compiler optimization
Message-ID: <1297771065.21.0.805891775971.issue877121@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Was fixed in r85656 by Martin (in 3.2), but needs backporting.

----------
assignee:  -> loewis
nosy: +loewis, pitrou
stage: needs patch -> committed/rejected
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue877121>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:00:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 12:00:37 +0000
Subject: [issue11210] PyErr_SetFromWindowsErrWithFilenameObject() doesn't
	exist: remove it from pyerrors.h
In-Reply-To: <1297678521.8.0.172330383513.issue11210@psf.upfronthosting.co.za>
Message-ID: <1297771237.55.0.661023743178.issue11210@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis, mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11210>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:06:31 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 12:06:31 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297771591.68.0.823797461764.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Hum, I was incorrect in previous note:
You can remove -L\$(srcdir) on this line, but then you need to specify the full path to Modules/python.exp. See patch below:

Index: configure.in
===================================================================
--- configure.in        (revision 88422)
+++ configure.in        (working copy)
@@ -1642,7 +1655,7 @@
 then
        case $ac_sys_system/$ac_sys_release in
        AIX*)
-               BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) -bI:Modules/python.exp -L\$(srcdir)"
+               BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) -bI:\$(srcdir)/Modules/python.exp"
                LDSHARED="\$(BINLIBDEST)/config/ld_so_aix \$(CC) -bI:\$(BINLIBDEST)/config/python.exp"
                ;;
        IRIX/5*) LDSHARED="ld -shared";;


Also, I think there are other issues with building Python 3.2 with shared libraries. I am currently investigating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:07:31 2011
From: report at bugs.python.org (Martijn van Oosterhout)
Date: Tue, 15 Feb 2011 12:07:31 +0000
Subject: [issue5831] Doc mistake : threading.Timer is *not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1297771651.1.0.981793326542.issue5831@psf.upfronthosting.co.za>


Martijn van Oosterhout <kleptog at gmail.com> added the comment:

Note this is a behaviour change. Under the old scheme (Foo is a class)

Foo.timerclass = Timer

created a method, whereas now it will just assign the class as an attribute. To work around this you had to use _Timer. Will that dummy class remain as an alias to avoid breaking code (in 2.7 at least)?

----------
nosy: +Martijn.van.Oosterhout

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5831>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:13:16 2011
From: report at bugs.python.org (River Tarnell)
Date: Tue, 15 Feb 2011 12:13:16 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297771996.76.0.830500614197.issue7305@psf.upfronthosting.co.za>


River Tarnell <r.tarnell at IEEE.ORG> added the comment:

If no one else can reproduce this I suppose there's no point leaving it open, but it's still present for me using Python 2.7.1:

% bzip2 -dc Python-2.7.1.tar.bz | tar xvf -
% cd Python-2.7.1
% CC=cc CXX=CC CPPFLAGS='-I/usr/sfw/include' LDFLAGS='-L/usr/sfw/lib -R/usr/sfw/lib' ./configure --enable-ipv6 --prefix=$HOME/pytest
% gmake -j5
% gmake install
% $HOME/pytest/bin/python
Python 2.7.1 (r271:86832, Feb 15 2011, 12:06:37) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.urlopen('https://wiki.toolserver.org')
zsh: segmentation fault (core dumped)  $HOME/pytest/bin/python
% pstack core
core 'core' of 12301:   /home/rriver/pytest/bin/python
 feb265bd AES_encrypt () + f1
% cat /etc/release
                    Oracle Solaris 10 9/10 s10x_u9wos_14a X86

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:15:06 2011
From: report at bugs.python.org (River Tarnell)
Date: Tue, 15 Feb 2011 12:15:06 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297772106.34.0.390944377123.issue7305@psf.upfronthosting.co.za>


River Tarnell <r.tarnell at IEEE.ORG> added the comment:

Also, when compiled with OpenSSL 1.0.0c, the problem doesn't occur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 13:25:07 2011
From: report at bugs.python.org (Fabian Groffen)
Date: Tue, 15 Feb 2011 12:25:07 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297772707.12.0.512289218389.issue7305@psf.upfronthosting.co.za>


Fabian Groffen <grobian at gentoo.org> added the comment:

I recompiled openssl with noasm flag now for sparcv9 (like I do on 32-bits compiles), and the example runs fine for me on the T1, proving Python is not to blame here.

That said, if your problem only occurs with 0.9.8 isn't it then likely that that version has some bug which is fixed in 1.0.0 series?
My gdb backtraces pointed at code inside libcrypto (one of the ASM accelerators).

I am using GCC and a minimum of host-provided libs though.

% python2.7 -V
Python 2.7.1 (r271:86832, Feb 14 2011, 12:37:15) 
[GCC 4.3.2] on sunos5
% file `which python2.7`
/scratch/tmp/gentoo/sparcv9/usr/bin/python2.7: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
% uname -a
SunOS build-t1000-sol10.cwi.nl 5.10 Generic_139555-08 sun4v sparc SUNW,SPARC-Enterprise-T1000 Solaris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:00:23 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 13:00:23 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297774823.06.0.111228775269.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

OK, Python with shared libraries is broken in trunk since the library was renamed to libpython3.2m.
Here is a patch to correct that:

Index: Modules/ld_so_aix.in
===================================================================
--- Modules/ld_so_aix.in        (revision 88422)
+++ Modules/ld_so_aix.in        (working copy)
@@ -131,7 +131,7 @@
   shift
 done
 
-if test "$objfile" = "libpython at VERSION@.so"; then
+if test "$objfile" = "libpython at VERSION@@ABIFLAGS at .so"; then
   ldsocoremode="true" 
 fi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:12:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Feb 2011 13:12:10 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297775530.2.0.100426666667.issue941346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This looks like it should (and could) go into 3.2 final.  Agreed?

----------
nosy: +barry, benjamin.peterson, georg.brandl
priority: normal -> release blocker
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:13:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 13:13:37 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297775617.09.0.546221692261.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:18:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Feb 2011 13:18:07 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297775887.3.0.697717736385.issue941346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK. S?bastien, could you make and attach a complete patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:23:19 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Feb 2011 13:23:19 +0000
Subject: [issue5831] Doc mistake : threading.Timer is *not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1297776199.25.0.0737862504768.issue5831@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Discussion should be moved to #10968, please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5831>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:47:06 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 13:47:06 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297777626.09.0.770859603021.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is the full patch.
I also modified Makefile.pre.in to clean Modules/python.exp when doing distclean.

----------
Added file: http://bugs.python.org/file20764/patch_aix_shared_32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 14:53:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 13:53:18 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297777998.77.0.581907459415.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 15:13:06 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 14:13:06 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297779186.94.0.8661390422.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

This link flag should only be applied to the python executable.
There is already LINKFORSHARED which is great for that.
LDFLAGS will apply it to all the shared libraries which is not really what we want.

I can compile Python with support for 512MB without any modification to configure like that:

CC=xlc_r OPT="-O2 -qmaxmem=100000" ./configure --without-computed-gotos --enable-shared
make LINKFORSHARED="-Wl,-bE:Modules/python.exp -lld -Wl,-bmaxdata:0x20000000"

It is just not very elegant and will make the builbdot script even more complex than it is currently.
Also it will make it more difficult for AIX users to find out about this limitation or build python with support for more memory (though I agree this represents very few people).

If you don't want it in configure though, I will add a note in AIX-NOTES about this limitation and how to build Python with support for more memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Tue Feb 15 15:13:15 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 14:13:15 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297779195.82.0.78448984504.issue11212@psf.upfronthosting.co.za>


Changes by S?bastien Sabl? <sable at users.sourceforge.net>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Tue Feb 15 15:16:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 14:16:12 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297779372.14.0.184462433687.issue11212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> LDFLAGS will apply it to all the shared libraries which is not really
> what we want.

Is there a downside?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Tue Feb 15 15:37:54 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 14:37:54 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297780674.61.0.719287702959.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I don't know distutils well enough, but I am afraid the LDFLAGS flag used to compile python is reused in some way when linking some python extensions or some application that embed python.
(I use an application that embed python on AIX, I should check what happens when I compile it).

Except for that, I can't see any problem now, but I would not be feel comfortable propagating this option in LDFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Tue Feb 15 15:57:46 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 14:57:46 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297781866.42.0.964682514504.issue11188@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is what I could find in the "man mktime":
"""
       Upon successful completion, the mktime subroutine sets the values of the tm_wday and tm_yday fields appropriately. Other fields are set to
       represent the specified time since January 1, 1970. However, the values are forced to the ranges specified in the /usr/include/time.h file.
       The final value of the tm_mday field is not set until the values of the tm_mon and tm_year fields are determined. Note: The mktime
       subroutine cannot convert time values before 00:00:00 UTC, January 1, 1970 and after 03:14:07 UTC, January 19, 2038.
"""

I tried tm_yday=-1 then tm_isdst=-2 and both gave the same errors as before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 16:45:02 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Feb 2011 15:45:02 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297784702.25.0.863640231523.issue941346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r88426.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:06:07 2011
From: report at bugs.python.org (River Tarnell)
Date: Tue, 15 Feb 2011 16:06:07 +0000
Subject: [issue7305] urllib2.urlopen() segfault using SSL on Solaris
In-Reply-To: <1257946972.34.0.0114488119184.issue7305@psf.upfronthosting.co.za>
Message-ID: <1297785967.74.0.680601669945.issue7305@psf.upfronthosting.co.za>


River Tarnell <r.tarnell at IEEE.ORG> added the comment:

Well, I can "prove" it's not OpenSSL's fault either, since "openssl s_client" works fine ;-)  (As do many other OpenSSL-using applications.)

In any case, since I'm not using SPARC, it's unlikely that a bug in the SPARC asm code is the cause of the problem.  Of course it could still be some other OpenSSL bug, or it could be that Python is using OpenSSL wrongly (and perhaps something changed between 0.9.7 and 1.0.0 that prevents the problem occuring).

We now use our own OpenSSL instead of Sun's, so this isn't a problem anymore, but it will affect anyone using Python on Solaris 10 with Sun's OpenSSL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7305>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:13:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Feb 2011 16:13:24 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297786404.27.0.76922665013.issue11188@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

S?bastien,

Can you tell us what time.localtime(t) produces for t in (-2, -1, 0, 1)?  Apparently time.mktime() fails on values produced by time.localtime() and this sounds like a platform bug.  It is OK to restrict time_t to positive values, but in this case time.localtime(t) should reject t < 0.

If there is a Python issue here, it is likely to be in error detection in time.localtime().

Also, what is your timezone?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:22:08 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 15 Feb 2011 16:22:08 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1297786928.91.0.677690491844.issue7877@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7877>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:29:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Feb 2011 16:29:31 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297786404.27.0.76922665013.issue11188@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=1kXcis2tdym1vssDhwhSffzSJoRntxP5_TaY2@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like different standards have different requirements for
localtime() error handling compare:

http://pubs.opengroup.org/onlinepubs/009695399/functions/localtime.html

and

http://pubs.opengroup.org/onlinepubs/7990989775/xsh/localtime.html

The later does not require that  localtime() returns NULL or sets
errno on error.  AIX documentation seems to be silent on this issue as
well:

http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/ctime.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 17:56:36 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 16:56:36 +0000
Subject: [issue640553] Misuse of /usr/local/in setup.py
Message-ID: <1297788996.54.0.135422046972.issue640553@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

This bug is still present in Python 2.7.1. I have also just been beaten by it on solaris.

I have libintl.so.1 in /usr/lib and libintl.so.8 in /usr/local/lib.

I have never specified that I wanted to use /usr/local/lib anywhere, but the compilation scripts insist on linking _locale.so with libintl.so.8, which may not be available on the platforms where I will deploy my python binaries.

/usr/local/lib should only be used if it is explicitly specified in LDFLAGS in my opinion.

----------
nosy: +sable
versions: +Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue640553>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:05:36 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 17:05:36 +0000
Subject: [issue640553] Misuse of /usr/local/in setup.py
Message-ID: <1297789536.42.0.37987945777.issue640553@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I can only bypass this by explicitly specifying -L/usr/lib so that it will take precedence over -L/usr/local/lib.

But this behavior is still broken...
"Explicit is better than implicit."
I can see no reason why /usr/local should be implicitly added; people that really need it can always do export LDFLAGS="$LDFLAGS -L/usr/local/lib"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue640553>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:18:03 2011
From: report at bugs.python.org (Ben Gamari)
Date: Tue, 15 Feb 2011 17:18:03 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297790283.12.0.522916005947.issue3244@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

Has there been any progress here?

----------
nosy: +bgamari

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:23:14 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 17:23:14 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297790594.2.0.453351115493.issue11188@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Python 3.2rc3+ (py3k:88422M, Feb 15 2011, 16:57:29) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> for t in (-2, -1, 0, 1):
...     print(time.localtime(t))
... 
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=59, tm_sec=58, tm_wday=3, tm_yday=1, tm_isdst=0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=59, tm_sec=59, tm_wday=3, tm_yday=1, tm_isdst=0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0, tm_sec=1, tm_wday=3, tm_yday=1, tm_isdst=0)

I am in Paris. On the system, I get:
$ date
Tue Feb 15 18:18:58 NFT 2011
$ env | grep TZ
TZ=NFT-1DFT,M3.5.0,M10.5.0

which is strange since NFT seems to be in Australia.

I will check that tomorrow with the sysadmin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:43:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Feb 2011 17:43:19 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297790594.2.0.453351115493.issue11188@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZzYXYuftvoUDeNHuSGn=OQK4NH2=3bWvwG5E-@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

2011/2/15 S?bastien Sabl? <report at bugs.python.org>:
..
>>>> for t in (-2, -1, 0, 1):
> ... ? ? print(time.localtime(t))
> ...
> time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=59, tm_sec=58, tm_wday=3, tm_yday=1, tm_isdst=0)
..

This looks right. (For time.timezone = -3600.)   I actually suspected
that you were east of Greenwich.   My hypothesis is that AIX localtime
implementation adjusts t -> t - timezone before computing broken down
time and thus fails to detect that localtime() is given negative
argument.  If my hypothesis is correct, time.gmtime(-1) should fail on
your system.

..
> TZ=NFT-1DFT,M3.5.0,M10.5.0
>
> which is strange since NFT seems to be in Australia.

In your TZ setting, the UTC offset and DST rules are specified
explicitly, so it does not matter what names are given to the
timezones for most time calculations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:47:37 2011
From: report at bugs.python.org (Forest Bond)
Date: Tue, 15 Feb 2011 17:47:37 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297792057.49.0.277584904299.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hi,

Sorry for the long delay.  I have tested against a Python web application using restish via various WSGI web servers (CherryPy, wsgiref) and I have not seen problems.  It may cause problems with other server-side implementations.

I will not have time to do broad testing against many different server-side implementations.  Is there harm in applying the patch and fixing bugs that get reported?

Thanks,
Forest

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 18:48:59 2011
From: report at bugs.python.org (Forest Bond)
Date: Tue, 15 Feb 2011 17:48:59 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297792139.5.0.130949574642.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Looks like bgamari and I stepped on each other's requests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 19:36:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Feb 2011 18:36:57 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297795017.22.0.176216327564.issue3244@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This patch needs a Doc component.

Having finally taken a quick look at the RFC (I haven't read it through yet), I think this does belong in email and not http.  The RFC makes it clear that while the most common implementation is http, it is designed to be generic, and as such IMO the logical place for it in the stdlib is with the rest of the MIME types, in email.  From a usability standpoint, however, it would be more convenient in http, so if most people think it should go into http I won't object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 19:58:55 2011
From: report at bugs.python.org (Landreville)
Date: Tue, 15 Feb 2011 18:58:55 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1297796335.56.0.763238052474.issue9437@psf.upfronthosting.co.za>


Landreville <landreville at deadtreepages.com> added the comment:

> I've committed a patch which does just this (in r85422). Hopefully it
> won't break anything.

Could I convince you to patch 2.7 as well?

----------
nosy: +TheoLandreville, benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Tue Feb 15 19:59:24 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Tue, 15 Feb 2011 18:59:24 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297796364.92.0.0431052446329.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Antoine,

can you take a look at issue 730467? That's a trivial patch to correct a compilation issue on AIX with a C++ compiler; and that means one less entry in the AIX-NOTES file to write before the 3.2 release...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:00:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 19:00:10 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1297796410.13.0.820150657388.issue730467@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730467>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:00:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 19:00:48 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297796448.78.0.0872995635512.issue10709@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> can you take a look at issue 730467?

Yes, this is in my bug queue. But unless Georg decides otherwise, this will go in after 3.2 is released (in 3.2.1 probably).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:03:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Feb 2011 19:03:31 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1297796335.56.0.763238052474.issue9437@psf.upfronthosting.co.za>
Message-ID: <1297796608.3722.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I've committed a patch which does just this (in r85422). Hopefully it
> > won't break anything.
> 
> Could I convince you to patch 2.7 as well?

It was backported in r86848. This means it should be available in 2.7.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:14:34 2011
From: report at bugs.python.org (Jesse Noller)
Date: Tue, 15 Feb 2011 19:14:34 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297797274.59.0.951694392121.issue3244@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Yeah, despite what the RFC says, the most common usage is in web clients, and stuffing it in the email module won't be obvious to 95% of the population I think, unless that's where the implementation lives, but we can add a doc stub in the http docs pointing to it and why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 20:49:22 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Feb 2011 19:49:22 +0000
Subject: [issue730467] Not detecting AIX_GENUINE_CPLUSPLUS
Message-ID: <1297799362.48.0.744284147395.issue730467@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed to py3k in r88430.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue730467>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:14:19 2011
From: report at bugs.python.org (Forest Bond)
Date: Tue, 15 Feb 2011 21:14:19 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297804459.18.0.154024082313.issue3244@psf.upfronthosting.co.za>


Forest Bond <forest at alittletooquiet.net> added the comment:

Hi,

So is the following enough to get this applied?  If so, I'm game.

* Review RFC and enforce Content-Encoding: binary if applicable [checat].
* Generate CR+LF line endings [checat].
* Review RFC and address "line-splitting and header-folding" if applicable [checat].
* Write documentation.

I can have this done in a week or so, but I'd like to have some confidence that it will be applied if I spend the time on it.

Thanks,
Forest

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 22:55:44 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Feb 2011 21:55:44 +0000
Subject: [issue3244] multipart/form-data encoding
In-Reply-To: <1214849078.87.0.171093103517.issue3244@psf.upfronthosting.co.za>
Message-ID: <1297806944.88.0.132716991529.issue3244@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In principle I think something like this should go in.  Since it is a Message subclass, I'd like it to follow the current Message API whether or not it is located in the email package.  __str__ and as_string have the right default for line length (no folding).  The current default for line endings is \n, and I think the class should stick with that.  You can't use __str__ or as_string to generate what you send on the wire if you are supporting binary data.

I am planning additions to the email API that will make integrating this class and adjusting the generated line endings easier.  For the latter (assuming the email-sig approves) I plan a __bytes__ method that will generate "wire format", which would include using \r\n line endings and should be just what you need.

The current email package does not support the binary content transfer encoding, only 8bit.  Support for the binary CTE is another planned addition for 3.3, and I think it can be prioritized ahead of most other features, given that this code needs it.

So, you might want to wait until the email pieces are in place, and possibly even help me develop them :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3244>
_______________________________________

From report at bugs.python.org  Tue Feb 15 23:15:58 2011
From: report at bugs.python.org (Tom Loredo)
Date: Tue, 15 Feb 2011 22:15:58 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1297808158.61.0.911536775601.issue11217@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

I believe the main Makefile makes the Mac/Makefile.in installunixtools target automatically, and I don't see that it should do "the right thing" regarding linking a python-32.

I did the brew install again, logging the output, and adding an explicit "make frameworkinstallunixtools" (which I believe executes the Make makefile installunixtools target).  This is the log output showing that target is executed already by default, and that it is not linking python2.7-32:


cd Mac && make installunixtools DESTDIR=""
if [ ! -d "/usr/local/Cellar/python/2.7.1/bin" ]; then  \
		/usr/local/bin/ginstall -c -d -m 755 "/usr/local/Cellar/python/2.7.1/bin" ;\
	fi
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
		  python2.7 pythonw2.7 idle2.7 \
		  pydoc2.7 python2.7-config smtpd2.7.py \
		  2to3-2.7 ;\
	do \
		ln -fs "/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/${fn}" "/usr/local/Cellar/python/2.7.1/bin/${fn}" ;\
	done
==> make frameworkinstallunixtools
make frameworkinstallunixtools 
cd Mac && make installunixtools DESTDIR=""
if [ ! -d "/usr/local/Cellar/python/2.7.1/bin" ]; then  \
		/usr/local/bin/ginstall -c -d -m 755 "/usr/local/Cellar/python/2.7.1/bin" ;\
	fi
for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
		  python2.7 pythonw2.7 idle2.7 \
		  pydoc2.7 python2.7-config smtpd2.7.py \
		  2to3-2.7 ;\
	do \
		ln -fs "/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/${fn}" "/usr/local/Cellar/python/2.7.1/bin/${fn}" ;\
	done

I don't see how the -32 versions would be linked by this part of the Makefile:


	for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
		  python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
		  pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py \
		  2to3-$(VERSION) ;\


Looking further at the logged output, the -32 versions appear to be extracted from a universal pythonw:


lipo -extract i386 -output /usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32 pythonw
lipo -extract i386 -output /usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7-32 pythonw
ln -sf python2.7-32 "/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/python-32"
ln -sf pythonw2.7-32 "/usr/local/Cellar/python/2.7.1/Frameworks/Python.framework/Versions/2.7/bin/pythonw-32"

I don't see how the unixtools targets will find these.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Wed Feb 16 00:02:26 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Feb 2011 23:02:26 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1297810946.93.0.489200136375.issue4709@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Wed Feb 16 00:08:10 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Feb 2011 23:08:10 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1297811290.71.0.370757097407.issue10504@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Wed Feb 16 00:11:08 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Feb 2011 23:11:08 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1297811468.75.0.197630266706.issue6335@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Wed Feb 16 00:15:33 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Feb 2011 23:15:33 +0000
Subject: [issue10615] Trivial mingw compile fixes
In-Reply-To: <1291380362.46.0.195053370852.issue10615@psf.upfronthosting.co.za>
Message-ID: <1297811733.7.0.0739116239411.issue10615@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10615>
_______________________________________

From report at bugs.python.org  Wed Feb 16 02:14:41 2011
From: report at bugs.python.org (Winston Ewert)
Date: Wed, 16 Feb 2011 01:14:41 +0000
Subject: [issue10775] assertRaises as a context manager should accept a 'msg'
	keyword argument.
In-Reply-To: <1293391143.22.0.15906903458.issue10775@psf.upfronthosting.co.za>
Message-ID: <1297818881.24.0.177796027833.issue10775@psf.upfronthosting.co.za>


Winston Ewert <winstonewert at gmail.com> added the comment:

I decided to try my hand at writing a patch for python.

I ended up implementing the behavior for assertRaises, assertRaisesRegex, assertWarns, and assertWarnsRegex. I also made those functions complain about other arguments rather then just ignoring them.

----------
keywords: +patch
nosy: +Winston.Ewert
Added file: http://bugs.python.org/file20765/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10775>
_______________________________________

From report at bugs.python.org  Wed Feb 16 04:22:49 2011
From: report at bugs.python.org (Kelsey)
Date: Wed, 16 Feb 2011 03:22:49 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>


New submission from Kelsey <kelsey.hightower at gmail.com>:

Distutils2 should produce a warning when the license is specified in both the License and Classifier metadata fields

----------
assignee: tarek
components: Distutils2
messages: 128624
nosy: alexis, eric.araujo, kelseyhightower, tarek
priority: normal
severity: normal
status: open
title: Produce a warning when the license is specified in both the License and Classifier metadata fields
type: feature request
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 04:25:43 2011
From: report at bugs.python.org (Kelsey)
Date: Wed, 16 Feb 2011 03:25:43 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297826743.12.0.642648845124.issue11219@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Changes and additional tests can be reviewed on my patch queue.

https://bitbucket.org/khightower/distutils2-patch-queue/changeset/d7dff88ab524

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 05:15:42 2011
From: report at bugs.python.org (Ian Wetherbee)
Date: Wed, 16 Feb 2011 04:15:42 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>


New submission from Ian Wetherbee <ian.wetherbee at gmail.com>:

Certain https urls do not open using urllib2 (py2.6) and urllib(py3.1), but they open using the latest version of curl and firefox.

To reproduce:
>>> import urllib.request
>>> urllib.request.urlopen("https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse")
Traceback (most recent call last):
  File "/usr/lib64/python3.1/urllib/request.py", line 1072, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/usr/lib64/python3.1/http/client.py", line 932, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib64/python3.1/http/client.py", line 970, in _send_request
    self.endheaders(body)
  File "/usr/lib64/python3.1/http/client.py", line 928, in endheaders
    self._send_output(message_body)
  File "/usr/lib64/python3.1/http/client.py", line 782, in _send_output
    self.send(msg)
  File "/usr/lib64/python3.1/http/client.py", line 723, in send
    self.connect()
  File "/usr/lib64/python3.1/http/client.py", line 1055, in connect
    self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file)
  File "/usr/lib64/python3.1/ssl.py", line 381, in wrap_socket
    suppress_ragged_eofs=suppress_ragged_eofs)
  File "/usr/lib64/python3.1/ssl.py", line 135, in __init__
    raise x
  File "/usr/lib64/python3.1/ssl.py", line 131, in __init__
    self.do_handshake()
  File "/usr/lib64/python3.1/ssl.py", line 327, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:488: error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.1/urllib/request.py", line 121, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib64/python3.1/urllib/request.py", line 349, in open
    response = self._open(req, data)
  File "/usr/lib64/python3.1/urllib/request.py", line 367, in _open
    '_open', req)
  File "/usr/lib64/python3.1/urllib/request.py", line 327, in _call_chain
    result = func(*args)
  File "/usr/lib64/python3.1/urllib/request.py", line 1098, in https_open
    return self.do_open(http.client.HTTPSConnection, req)
  File "/usr/lib64/python3.1/urllib/request.py", line 1075, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno 1] _ssl.c:488: error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter>

Curl request:
$ curl https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="https://apps.uillinois.edu/selfservice/error/">here</A>.<P>
<HR>
<ADDRESS>Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server Server at ui2web1a.admin.uillinois.edu Port 443</ADDRESS>
</BODY></HTML>

----------
components: None
messages: 128626
nosy: Ian.Wetherbee
priority: normal
severity: normal
status: open
title: https sslv3 error 14077417: illegal parameter
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:40:34 2011
From: report at bugs.python.org (Tom Loredo)
Date: Wed, 16 Feb 2011 06:40:34 +0000
Subject: [issue10907] OS X installer: warn users of buggy Tcl/Tk in OS X 10.6
In-Reply-To: <1295020361.6.0.15646249296.issue10907@psf.upfronthosting.co.za>
Message-ID: <1297838434.1.0.845724860824.issue10907@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

I see this is marked as fixed but pending; perhaps the following comment will be useful.

I encountered the IDLE/Tk instability issue when working on the Homebrew formula for Python-2.6.5 a year ago (March 2010).  Building a universal framework Python on Intel (32/64-bit) produced an IDLE that froze when one created a new window, a common problem even back then.  Attempting to resolve the issue was further complicated by 2.6.5 not having a way to access 32-bit Python in a universal build (since fixed!).

I came up with three workarounds that produced Python builds for 10.6 with an IDLE that at least did not have the new-window freeze.  I'm not a heavy IDLE user, so I didn't test beyond that, and perhaps one or more of the workarounds would still have problems.  Two workarounds could produce 64-bit Python with a non-freezing IDLE; the last one could only produce a 32-bit version, but built on 10.6.

The workarounds:

* As already noted, installing the current ActiveTcl before building Python produced a working IDLE, 32-bit or 64-bit.

* I was able to build a 32/64 universal Cocoa version of Tcl/Tk 8.5 using an 8.6beta backport; I believe I learned of it in the Tcl thread here:

http://mail.python.org/pipermail/pythonmac-sig/2010-March/thread.html

The version I used is on GitHub:

https://github.com/das/tcltk/tree/de-carbon-8-5

I have a brew formula that builds it (at least the version of March 2010) and installs it as a public framework, so Python can find it.  The resulting IDLE did not have the new windows freeze.  If this is a real fix, it might be helpful for users who have license issues with ActiveTcl.

* The last workaround uses the fact that Apple ships both 8.4 and 8.5 versions of Tcl/Tk with 10.6, though the 8.4 Tk is only 32-bit.  I hacked Python's setup.py to detect if a 32-bit 10.6 build is in progress; if so, it linked against 8.4 instead of 8.5, and it produced an IDLE that at least didn't have the new window freeze.  Perhaps 8.4 is old enough to have other issues, but if it would be acceptable as a stopgap, I'm sure Ned et al. could come up with a better setup.py hack than I did.  The advantage of this approach is that it does not require any software that doesn't ship with Snow Leopard.  Since it only works for 32-bit builds, it probably doesn't have advantages over installing the 32-bit 10.3-10.6 Python.  But if you must *build* on 10.6 and have a working IDLE without using ActiveTcl, this might be an option.

I find two things somewhat confusing regarding the current version of the web site:

* My impression was that Python's tkinter figures out what Tcl/Tk to link to at build time, not runtime.  The table on the web site suggests I can use a pre-built Python with an ActiveTcl that I install myself later.  Is this correct?  If so, does ActiveTcl have to be present when the installer is run, or can it be installed later?

* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But the 2.7.2 patched README indicates ActiveTcl-8.5.9 will work.  Will it not work with 2.7.1?

Thanks a lot for your continued work on this thorny issue!

----------
nosy: +tloredo
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10907>
_______________________________________

From report at bugs.python.org  Wed Feb 16 07:49:46 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Feb 2011 06:49:46 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297838986.47.0.989573516295.issue11220@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 08:32:11 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Feb 2011 07:32:11 +0000
Subject: [issue1173475] __slots__ for subclasses of variable length types
Message-ID: <1297841531.95.0.757412965768.issue1173475@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
keywords:  -after moratorium
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1173475>
_______________________________________

From report at bugs.python.org  Wed Feb 16 08:32:57 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Feb 2011 07:32:57 +0000
Subject: [issue1498363] Improve super() objects support for implicit method
	calls
Message-ID: <1297841577.18.0.0544684351802.issue1498363@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
keywords:  -after moratorium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1498363>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:31:39 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 08:31:39 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>


New submission from Jonathan Livni <jonathan.livni at gmail.com>:

all( (x<=y) for x,y in zip(L, L[1:]) )
all([(x<=y) for x,y in zip(L, L[1:])])

Both lines of code above check if L is a non-decreasing list. Both should return the same results. But under some conditions, they don't. I've encountered this with a list of Decimal numbers.
This is 100% reproducible on my Win7 64bit vanilla Python 2.6.6 32bit setup, alas I cannot share the specific code that generates this difference.
See attached screenshot from Eclipse Pydev debugger.

----------
components: Windows
files: Eclipse.JPG
messages: 128628
nosy: Jonathan.Livni
priority: normal
severity: normal
status: open
title: all() returns wrong result when the parameters are non-encapsulated list-comprehension
versions: Python 2.6
Added file: http://bugs.python.org/file20766/Eclipse.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:40:02 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Feb 2011 08:40:02 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297845602.65.0.873758111173.issue11221@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It's not easy to reproduce this without the full list of decimals.

Do you have a nonstandard decimal Context set?

What is the result if you put the LC into a function, i.e.

def f(L):
    return [(x<=y) for x,y in zip(L, L[1:])]

print all(f(L))

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:47:54 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 08:47:54 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297846074.77.0.419133898925.issue11221@psf.upfronthosting.co.za>


Jonathan Livni <jonathan.livni at gmail.com> added the comment:

The exact list of decimals doesn't help - I tried taking the list and reproducing the bug with the following short script, but the problem did not reproduced:

from decimal import Decimal
L = [Decimal('6.700'), Decimal('6.800'), Decimal('7.140'), Decimal('7.460'), Decimal('7.735'), Decimal('8.160'), Decimal('8.280'), Decimal('8.355'), Decimal('8.710'), Decimal('9.640'), Decimal('10.155'), Decimal('10.460'), Decimal('10.810'), Decimal('11.875'), Decimal('12.310'), Decimal('12.315'), Decimal('13.250'), Decimal('13.205'), Decimal('13.750'), Decimal('14.245'), Decimal('14.805'), Decimal('15.385'), Decimal('15.955'), Decimal('16.365'), Decimal('16.960'), Decimal('17.500'), Decimal('19.445')]
print all(x<=y for x, y in zip(L, L[1:]))

The script above rightfully printed False.
The decimal list above was taken from the pydev debugger session where I found the bug.

In the original script I do not mess around with Decimal at all. I just cast too and from float and use simple arithmetics with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:52:08 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 08:52:08 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297846328.11.0.610407141026.issue11221@psf.upfronthosting.co.za>


Jonathan Livni <jonathan.livni at gmail.com> added the comment:

Another note - the original problematic code looks like this:

def non_decreasing(L):
    return all(x<=y for x, y in zip(L, L[1:]))

Changing it to:

def non_decreasing(L):
    def f(L):
        return [x<=y for x, y in zip(L, L[1:])]
    return all(f(L))    

also worked around the bug

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 09:56:02 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Feb 2011 08:56:02 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297846562.73.0.368642302497.issue11220@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

curl (7.21.0) fails with the same error message too for the target website. (Is the server doing anything different. For other HTTPS sites (which also use redirection) urllib.request works fine )

senthil at ubuntu:~/python/py3k$ curl -v https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
* About to connect() to ui2web1.apps.uillinois.edu port 443 (#0)
*   Trying 64.22.183.24... connected
* Connected to ui2web1.apps.uillinois.edu (64.22.183.24) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter
* Closing connection #0
curl: (35) error:14077417:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert illegal parameter

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:10:46 2011
From: report at bugs.python.org (Ian Wetherbee)
Date: Wed, 16 Feb 2011 09:10:46 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297847446.56.0.319813499389.issue11220@psf.upfronthosting.co.za>


Ian Wetherbee <ian.wetherbee at gmail.com> added the comment:

The server seems to be sending a bad TLS handshake, so curl falls back on SSLv3 with TLS disabled.

curl 7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.8.0 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

curl -v https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
* About to connect() to ui2web1.apps.uillinois.edu port 443 (#0)
*   Trying 64.22.183.24... connected
* Connected to ui2web1.apps.uillinois.edu (64.22.183.24) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12226
* Error in TLS handshake, trying SSLv3...
> GET /BANPROD1/bwskfcls.P_GetCrse HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.8.0 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host: ui2web1.apps.uillinois.edu
> Accept: */*
> 
* Connection died, retrying a fresh connect
* Closing connection #0
* Issue another request to this URL: 'https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse'
* About to connect() to ui2web1.apps.uillinois.edu port 443 (#0)
*   Trying 64.22.183.24... connected
* Connected to ui2web1.apps.uillinois.edu (64.22.183.24) port 443 (#0)
* TLS disabled due to previous handshake failure
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using SSL_RSA_WITH_RC4_128_MD5
* Server certificate:
* 	subject: CN=ui2web1.apps.uillinois.edu,OU=AITS 20100517-25690,O=University of Illinois,L=Urbana,ST=Illinois,C=US
* 	start date: May 17 00:00:00 2010 GMT
* 	expire date: May 17 23:59:59 2011 GMT
* 	common name: ui2web1.apps.uillinois.edu
* 	issuer: E=premium-server at thawte.com,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA
> GET /BANPROD1/bwskfcls.P_GetCrse HTTP/1.1
> User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.8.0 zlib/1.2.3 libidn/1.16 libssh2/1.2.4
> Host: ui2web1.apps.uillinois.edu
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Wed, 16 Feb 2011 07:49:43 GMT
< Server: Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server
< Location: https://apps.uillinois.edu/selfservice/error/
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="https://apps.uillinois.edu/selfservice/error/">here</A>.<P>
<HR>
<ADDRESS>Oracle-Application-Server-10g/10.1.2.3.0 Oracle-HTTP-Server Server at ui2web1b.admin.uillinois.edu Port 443</ADDRESS>
</BODY></HTML>
* Closing connection #0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:31:54 2011
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 16 Feb 2011 09:31:54 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297848714.41.0.104523374185.issue941346@psf.upfronthosting.co.za>


Michael Haubenwallner <michael.haubenwallner at salomon.at> added the comment:

> You can remove -L\$(srcdir) on this line, but then you need to specify > the full path to Modules/python.exp. See patch below:

Interesting, didn't experience this to be necessary with Python-2.7.1 here... Maybe because I do an in-source build, haven't tried an out-of-source build at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:47:48 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Feb 2011 09:47:48 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297849668.59.0.368144802902.issue11220@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The problem is the server strictly accepts SSLv3 only and urllib and http.client send SSLv23 protocol.

(In http/client.py, line 1077)
             if context is None:
                 # Some reasonable defaults
                 context = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
                 context.options |= ssl.OP_NO_SSLv2
             will_verify = context.verify_mode != ssl.CERT_NONE


However, in order to use only SSLv3, one can set the context to ssl.PROTOCOL_SSLv3 in the HTTPSHandler and use it.

import urllib.request
import ssl
https_sslv3_handler = urllib.request.HTTPSHandler(context=ssl.SSLContext(ssl.PROTOCOL_SSLv3))
opener = urllib.request.build_opener(https_sslv3_handler)
urllib.request.install_opener(opener)
urllib.request.urlopen('https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:48:35 2011
From: report at bugs.python.org (wrobell)
Date: Wed, 16 Feb 2011 09:48:35 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
In-Reply-To: <1293282928.77.0.893563694653.issue10130@psf.upfronthosting.co.za>
Message-ID: <1297849715.6.0.913091124213.issue10130@psf.upfronthosting.co.za>


wrobell <wrobell at pld-linux.org> added the comment:

it would be nice to have some short TOC at the beginning.

at the moment, one has to scroll through several pages of "what's new in python [23].[0-9]" table of contents until he/she gets into tutorial.

----------
nosy: +wrobell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:55:18 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 09:55:18 +0000
Subject: [issue11188] test_time error on AIX
In-Reply-To: <1297435870.78.0.786178293384.issue11188@psf.upfronthosting.co.za>
Message-ID: <1297850118.75.0.213247617492.issue11188@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

gmtime(-1) worked fine :/

>>> import time
>>> time.gmtime(-1)
time.struct_time(tm_year=1969, tm_mon=12, tm_mday=31, tm_hour=23, tm_min=59, tm_sec=59, tm_wday=2, tm_yday=365, tm_isdst=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11188>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:57:24 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 09:57:24 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297850244.16.0.622466490296.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Are you using --enable-shared when compiling python?
That is when you should see the error (it could not find python.exp at some stage).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Feb 16 10:58:27 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 09:58:27 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297850307.22.0.574983554947.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

By the way... thanks Georg!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:01:18 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 10:01:18 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297850478.68.0.0875279989819.issue941346@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Also Michael, I am working on the 3.2 branch, it may be different with Python 2.7.1 but I haven't tested yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:02:16 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Feb 2011 10:02:16 +0000
Subject: [issue7284] optparse - display version in usage by default
In-Reply-To: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
Message-ID: <1297850536.85.0.902648376834.issue7284@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Does argparse display version by default?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7284>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:05:25 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Feb 2011 10:05:25 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297850725.78.0.47690318424.issue11221@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is an interesting puzzle.  In both cases, the zip() function is called and runs to completion before either the list comprehension or genexp is started or called.  The code for all() is somewhat simple -- it iterates over the input and tests whether the value is true.  That is also the same in both.

one essential difference between the two then is that the x, y variables get exposed in the list comprehension but not in the genexp.  The only way I can see to get to two to evaluate differently is to mutate the exposed variables before the comparison:

>>> from decimal import *
>>> L = list(map(Decimal, '6.700 6.800 7.140 7.460 7.735'.split()))
>>> def f(z):
	global y
	y -= 100
	return z

>>> all([(f(x)<=y) for x, y in zip(L, L[1:])])
False
>>> all((f(x)<=y) for x, y in zip(L, L[1:]))
True

I don't see how that mutation could happen in your functions unless decimal has been subclassed to override its __le__ method.

Another way to get a midstream mutation is for L to change in mid-computation in multi-threaded code.  Is your example single threaded?  Is the debugger affecting the run in some way?

The disassembly shows 1) when zip is called, 2) whether x,y are exposed, and 3) whether a list is being iterated or the genexp:

>>> from dis import dis
>>> dis(compile('all((x<=y) for x, y in zip(a, b))', '', 'eval'))
  1           0 LOAD_NAME                0 (all)
              3 LOAD_CONST               0 (<code object <genexpr> at 0x16b3f50, file "", line 1>)
              6 MAKE_FUNCTION            0
              9 LOAD_NAME                1 (zip)
             12 LOAD_NAME                2 (a)
             15 LOAD_NAME                3 (b)
             18 CALL_FUNCTION            2
             21 GET_ITER            
             22 CALL_FUNCTION            1
             25 CALL_FUNCTION            1
             28 RETURN_VALUE        
>>> dis(compile('all([(x<=y) for x, y in zip(a, b)])', '', 'eval'))
  1           0 LOAD_NAME                0 (all)
              3 BUILD_LIST               0
              6 DUP_TOP             
              7 STORE_NAME               1 (_[1])
             10 LOAD_NAME                2 (zip)
             13 LOAD_NAME                3 (a)
             16 LOAD_NAME                4 (b)
             19 CALL_FUNCTION            2
             22 GET_ITER            
        >>   23 FOR_ITER                25 (to 51)
             26 UNPACK_SEQUENCE          2
             29 STORE_NAME               5 (x)
             32 STORE_NAME               6 (y)
             35 LOAD_NAME                1 (_[1])
             38 LOAD_NAME                5 (x)
             41 LOAD_NAME                6 (y)
             44 COMPARE_OP               1 (<=)
             47 LIST_APPEND         
             48 JUMP_ABSOLUTE           23
        >>   51 DELETE_NAME              1 (_[1])
             54 CALL_FUNCTION            1
             57 RETURN_VALUE  

Nothing else interesting pops-out.

One question out of curiousity.  In the JPG file that is attached, the return type is listed as bool_ instead of bool.  Is that normal for an eclipsed debugger values display?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:16:26 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 10:16:26 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297851386.38.0.364335237782.issue11184@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is the patch.
It only impacts AIX systems and is minimalist, so I think it should be safe for Python 3.2.

----------
keywords: +patch
Added file: http://bugs.python.org/file20767/patch_aix_largefile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:36:44 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Wed, 16 Feb 2011 10:36:44 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297852604.81.0.527444395964.issue11219@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

Hi, 

I was more thinking about something like: if the license is specified in the "License" metadata, then check that it's not a well known license (which can and must be provided by the classifiers instead).

At the end, the code you've wrote is useful, but not complete.

Additionally, it seems that your patch make check complaining if you just have *defined* classifiers and license (even if the license is not provided in the classifiers: it complains if there is both defined, regardless what is defined). It should check instead if the classifier field contain the same thing than the license field.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:45:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 10:45:50 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1297853150.62.0.924713228377.issue10968@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One concern expressed on a duplicate report by Martijn van Oosterhout:

> Note this is a behaviour change. Under the old scheme (Foo is a class)
>
> Foo.timerclass = Timer
>
> created a method, whereas now it will just assign the class as an
> attribute. To work around this you had to use _Timer. Will that dummy
> class remain as an alias to avoid breaking code (in 2.7 at least)?

Stable versions (2.7, 3.1, soon 3.2) won?t get this change.  They may get a doc patch to warn people about the fake class/factory thing.


In the py3k documentation for threading, some of the fake classes are documented as factories (Event) and other ones as classes (Timer); do you people think there would be harm in cleaning up all those outdated shenanigans for 3.3, with due versionchanged notes in the doc?

----------
nosy: +Martijn.van.Oosterhout

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10968>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:49:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 10:49:37 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297853377.13.0.989893433777.issue11219@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

PEP 345 actually defines two fields that should be used only when a suitable Trove classifier does not exist:

> Platform (multiple use)
> A Platform specification describing an operating system supported by
> the distribution which is not listed in the "Operating System" Trove
> classifiers.

> License (optional)
> Text indicating the license covering the distribution where the
> license is not a selection from the "License" Trove classifiers. See
> "Classifier" below. This field may also be used to specify a
> particular version of a licencse which is named via the Classifier
> field, or to indicate a variation or exception to such a license.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 11:54:07 2011
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 16 Feb 2011 10:54:07 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>


New submission from John Szakmeister <john at szakmeister.net>:

I configured the build:
    ./configure --with-system-ffi --enable-shared --with-computed-gotos --prefix=$HOME/.local/python3 

Ran make with 4 jobs (make -j4), and got:
    make: *** No rule to make target `libpython3.2m.dylib', needed by `python.exe'.  Stop.
    make: *** Waiting for unfinished jobs....

It seems there might be a $(VERSION)/$(LDVERSION) problem somewhere in the Makefile, but I'm uncertain where the issue is exactly.  Looks like using --enable-framework instead of --enable-shared works, but I'd rather not have the framework right now.

----------
components: Build
messages: 128647
nosy: jszakmeister
priority: normal
severity: normal
status: open
title: Python3.2rc3 fails to build on Mac OS X with a non-framework build
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:01:26 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 16 Feb 2011 11:01:26 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854086.32.0.944876102242.issue11222@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I have not tried 3.2 yet, but Issue 11046 may be of interest for you!
Try the undocumented:

configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5

in the meanwhile - it may help you out.

----------
nosy: +ronaldoussoren, sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:01:26 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 11:01:26 +0000
Subject: [issue11172] Avoid '.' as runpath on AIX
In-Reply-To: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>
Message-ID: <1297854086.97.0.174307725478.issue11172@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

This has been corrected for python 3.2 in issue 941346.
Need to be tested on python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11172>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:01:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 11:01:56 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854116.3.0.675458573924.issue11222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you please attach your Makefile file?

In Makefile.pre.in, I see:

libpython$(VERSION).dylib: $(LIBRARY_OBJS)

VERSION should be 3.2, only LDVERSION is the VERSION + the ABI flags (eg. 3.2dm). And I don't see any usage of libpython$(LDVERSION).dylib in Makefile(.pre.in).

(You might also try "make SHELL='bash -x'" or "make -d" to get more information)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:02:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 11:02:32 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297854152.95.0.724253203113.issue11220@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I get an error using the following curl too:

curl 7.20.1 (x86_64-mandriva-linux-gnu) libcurl/7.20.1 OpenSSL/1.0.0a zlib/1.2.3 libidn/1.18 libssh2/1.2.5
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

The same URL sends wget into a loop:

$ LANG=C wget -v -O - https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
--2011-02-16 12:01:39--  https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
Resolving ui2web1.apps.uillinois.edu... 64.22.183.24
Connecting to ui2web1.apps.uillinois.edu|64.22.183.24|:443... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2011-02-16 12:01:40--  (try: 2)  https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
Connecting to ui2web1.apps.uillinois.edu|64.22.183.24|:443... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

--2011-02-16 12:01:43--  (try: 3)  https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse
Connecting to ui2web1.apps.uillinois.edu|64.22.183.24|:443... connected.
HTTP request sent, awaiting response... No data received.
Retrying.


IMO, this all points to the remote server being poorly compliant. Senthil's solution seems good enough here.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:04:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 11:04:09 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1297854249.64.0.0557885291307.issue941346@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Georg, the non-abiflags portion seems to need backporting.

----------
assignee:  -> georg.brandl
priority: release blocker -> normal
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:05:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 11:05:20 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854320.12.0.160418677059.issue11222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah, there is also Mac/Makefile.in: attach also Mac/Makefile.

(and there is also Mac/PythonLauncher/Makefile.in, but I don't think that the issue comes from this file)

((can it be related to python*-config program?))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:05:42 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 11:05:42 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854342.16.0.454609173893.issue11222@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:06:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 11:06:02 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854362.59.0.83101949741.issue11222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

@Georg: Is this issue a release blocker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:07:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 16 Feb 2011 11:07:07 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297854427.24.0.690616425677.issue11222@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Ooops.  In fact 3.2 did well with that undocumented thing either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:18:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 11:18:57 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297855137.31.0.842065635933.issue11222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:36:53 2011
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 16 Feb 2011 11:36:53 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297856213.06.0.977444018905.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Here is the top-level Makefile.

----------
Added file: http://bugs.python.org/file20768/Makefile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:38:18 2011
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 16 Feb 2011 11:38:18 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297856298.37.0.262735779634.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Interesting.  I don't see a Mac/Makefile.  Perhaps it's only pulled in with the framework build?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:41:31 2011
From: report at bugs.python.org (John Szakmeister)
Date: Wed, 16 Feb 2011 11:41:31 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297856491.34.0.2344526674.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

MACOSX_DEPLOYMENT_TARGET=10.5 made no bit of difference for me.  Steffen, I take it that it didn't help you either?  You said "did well", but the rest of your text indicates otherwise. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:46:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 11:46:50 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297856810.14.0.0914659472192.issue11222@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ah ok, the issue comes from configure.in near line 779:

    Darwin*)
    	LDLIBRARY='libpython$(LDVERSION).dylib'
	BLDLIBRARY='-L. -lpython$(LDVERSION)'
	RUNSHARED='DYLD_LIBRARY_PATH=`pwd`:${DYLD_LIBRARY_PATH}'
	;;

The problem is that configure.in uses libpython$(LDVERSION).dylib, whereas Makefile.pre.in uses libpython$(VERSION).dylib. Attached patch changes Makefile.pre.in to use libpython$(LDVERSION).dylib.

I don't know if this change is correct or not. I don't know if the options for the compilation in framework mode should be changed too. I don't know what is the Mac framework :-)

See also http://www.python.org/dev/peps/pep-3149/ (ABI version tagged .so files)

----------
keywords: +patch
Added file: http://bugs.python.org/file20769/darwin_ldlibrary.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:47:03 2011
From: report at bugs.python.org (Kelsey)
Date: Wed, 16 Feb 2011 11:47:03 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297856823.84.0.920645179099.issue11219@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Based on the feedback, I will rework the patch to include the following:

* Produce a warning only if the user supplied Platform or License metadata is listed in Trove classifiers (Exact match?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:53:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 11:53:12 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297857192.07.0.0806563377876.issue11219@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That?s not quite what the PEP says.  Please read it again and try to follow the text in your code.  Thanks for your work :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:58:00 2011
From: report at bugs.python.org (Alexis Metaireau)
Date: Wed, 16 Feb 2011 11:58:00 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297857480.5.0.19725808052.issue11219@psf.upfronthosting.co.za>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

That's almost what the PEP says, or at least what I understand of it.

The platform and license fields should be used only if no matching classifier exists for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 12:59:25 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 16 Feb 2011 11:59:25 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297857565.98.0.588607075672.issue11222@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Aeh, your patch does it.
You may be interested of all Mac OS X compilation notes??

/usr/bin/ranlib: file: libpython3.2m.a(dynamic_annotations.o) has no symbols
/usr/bin/ranlib: file: libpython3.2m.a(pymath.o) has no symbols
ranlib libpython3.2m.a
ranlib: file: libpython3.2m.a(dynamic_annotations.o) has no symbols
ranlib: file: libpython3.2m.a(pymath.o) has no symbols
/usr/bin/gcc   -framework CoreFoundation -o python.exe Modules/python.o libpython3.2m.a -ldl  -framework CoreFoundation     
building dbm using ndbm
ld: warning: directory '/usr/lib/termcap' following -L not found
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from /Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_tkinter.c:67:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:MULTIPLE: warning: function declaration isn?t a prototype
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
In file included from /System/Library/Frameworks/Tk.framework/Headers/tk.h:78,
                 from /Users/steffen/arena/code.extern.repos/py3k.hg/Modules/tkappinit.c:17:
/System/Library/Frameworks/Tk.framework/Headers/X11/Xlib.h:MULTIPLE: warning: function declaration isn?t a prototype
i686-apple-darwin10-gcc-4.2.1: -framework: linker input file unused because linking not done
i686-apple-darwin10-gcc-4.2.1: Tk: linker input file unused because linking not done
/Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:49: warning: function declaration isn?t a prototype
/Users/steffen/arena/code.extern.repos/py3k.hg/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:379: warning: function declaration isn?t a prototype

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:06:02 2011
From: report at bugs.python.org (Kelsey)
Date: Wed, 16 Feb 2011 12:06:02 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297857962.45.0.207757592421.issue11219@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Eric, I am not sure we can check for more than an exact match on Platform and License metadata fields.

D2 maintains a list of all Trove Classifiers which can be searched for an exact match; if a match is found warn the user that a Classifier should be used instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:12:15 2011
From: report at bugs.python.org (Egon Smiwa)
Date: Wed, 16 Feb 2011 12:12:15 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297858335.34.0.00842395947618.issue11135@psf.upfronthosting.co.za>


Egon Smiwa <smiwa.egon at googlemail.com> added the comment:

You bring the tp_doc parameter pointer 
into the ownership of the new typeobject?
and tp_doc is assumed to be created by pyObject_malloc?
IMO, if CPython wants to be the owner of the string parameter,
then it should make a copy of that parameter (tp_doc) 
and become owner of that copy.

----------
nosy: +Egon.Smiwa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11135>
_______________________________________

From report at bugs.python.org  Wed Feb 16 13:52:43 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 12:52:43 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297860763.34.0.258416362219.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a first version of this doc for Python 3.2.
It would be great if someone could proof read it since I am not a native english speaker (though it is not high level literature...).

----------
Added file: http://bugs.python.org/file20770/AIX-NOTES

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Wed Feb 16 14:51:28 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 13:51:28 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297864288.16.0.400090948968.issue11221@psf.upfronthosting.co.za>


Jonathan Livni <jonathan.livni at gmail.com> added the comment:

The script I used is a single file single threaded code - but - It uses django's ORM to get the data from a MySQL database.

I've reduced the code path to this:

import sys,os
sys.path.append(os.path.dirname(os.getcwdu()))
os.environ['DJANGO_SETTINGS_MODULE']='my_app.settings'
from django.core.management import setup_environ
from my_app import settings
setup_environ(settings)

from my_app.convert.models import SomeModel
from operator import itemgetter
from decimal import Decimal

def non_decreasing(L):
    return all(x<=y for x, y in zip(L, L[1:]))    

raw_data =  SomeModel.objects.filter(the_date=the_date,col1__gt=Decimal('0.2'),col2__gt=Decimal('0.2'),col3__gt=0,col4__gt=0,col5__gte=2).order_by('col6','col7','col8').values_list('col6','col7','col8','col1','col3','col2','col4')
data=defaultdict(list)

for d in raw_data:
	data[d[0],d[1]].append(d[2:])

for (exp,t),d in data.iteritems():
	col8s = map(itemgetter(0),d)
	mids = [(x[3]+x[4])/Decimal('2.0') for x in d]
	if not non_decreasing(mids):
		raise Exception

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 15:25:41 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 14:25:41 +0000
Subject: [issue11223] test_threadsignals.py hanging on AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>


New submission from S?bastien Sabl? <sable at users.sourceforge.net>:

The test test_lock_acquire_interruption in test_threadsignals.py will lock forever on AIX 5.3.
It works fine on 6.1.

truss shows it is stuck in thread_tsleep:
$ truss -p 1404986
thread_tsleep(0, 0x00000000, 0x00000000, 0x00000000) (sleeping...)

----------
messages: 128668
nosy: sable
priority: normal
severity: normal
status: open
title: test_threadsignals.py hanging on AIX
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 15:51:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 14:51:19 +0000
Subject: [issue11223] test_threadsignals.py hanging on AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297867879.55.0.837996354298.issue11223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We have the same issue on our FreeBSD 6.4 buildbot:
http://python.org/dev/buildbot/all/builders/x86%20FreeBSD%203.x/builds/1216/steps/test/logs/stdio
(FreeBSD 7.2 is fine)

Can you tell me what the values of _POSIX_SEMAPHORES and HAVE_SEM_TIMEDWAIT are (or whether they are undefined)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 15:58:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 14:58:27 +0000
Subject: [issue11223] test_threadsignals.py hanging on AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297868307.62.0.216493158916.issue11223@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:02:29 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Feb 2011 15:02:29 +0000
Subject: [issue4566] 2.6.1 breaks many applications that embed Python on
	Windows
In-Reply-To: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
Message-ID: <1297868549.04.0.946100512091.issue4566@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:03:39 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 15:03:39 +0000
Subject: [issue11223] test_threadsignals.py hanging on AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297868619.15.0.0669469848514.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

$ grep SEM pyconfig.h
#define HAVE_BROKEN_POSIX_SEMAPHORES 1
/* #undef HAVE_BROKEN_SEM_GETVALUE */
#define HAVE_SEM_GETVALUE 1
#define HAVE_SEM_OPEN 1
#define HAVE_SEM_TIMEDWAIT 1
#define HAVE_SEM_UNLINK 1
/* #undef POSIX_SEMAPHORES_NOT_ENABLED */
#ifndef _POSIX_PTHREAD_SEMANTICS
# define _POSIX_PTHREAD_SEMANTICS 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:06:36 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 15:06:36 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1297868796.28.0.198926103495.issue11192@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I am not sure this is directly related, but test_socket.py will hang forever on AIX 6.1 when this script is run as part of "make buildbottest".

It won't hang when running the script alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:16:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:16:36 +0000
Subject: [issue11223] test_threadsignals.py hanging on AIX
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297869396.53.0.941791964774.issue11223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, the problem is when the condition variable-based implementation is chosen in Python/thread_pthread.h.
It is actually reproduceable under Linux by adding `#undef USE_SEMAPHORES` just after `#define USE_SEMAPHORES`.
The problem is that, contrary to sem_timedwait(), pthread_cond_wait() doesn't have well-defined behaviour with signals. POSIX simply says:

?If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup.?

So, on those OSes where the semaphore API can't be used, the test can succeed or not depending on how pthread_cond_wait() behaves in the face of signals. It would be better if it didn't hang, though.

(This is not a regression, by the way. Locks were totally uninterruptible under POSIX until 3.2, and the tests weren't there. The new tests were introduced in r87292 (see issue8844))

----------
components: +Interpreter Core, Tests
nosy: +gregory.p.smith, rnk
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:21:16 2011
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 16 Feb 2011 15:21:16 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297869676.97.0.504408428312.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks!

Here is my updated patch:
1, Now the dbm view objects are the same as dict view objects, which are in conformity with collections.KeysView, ValuesView and ItemsView.
2, I register all these abcs explicitly because these abcs have not __subclasshook__() method so they can't check api conformance(at lease exist) through isinstance(). I could not make sure api conformance except testing each method I find in abc explicitly. And my test_abc() is just to test the registering.
3, Other updates which are from comments I wrote newly on codereview: http://codereview.appspot.com/4185044/

----------
Added file: http://bugs.python.org/file20771/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:21:32 2011
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 16 Feb 2011 15:21:32 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297869692.23.0.163992881432.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20751/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:27:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:27:29 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297870049.45.0.212714325269.issue11223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch that makes the test fail rather than hang. S?bastien, can you try it out?

----------
keywords: +patch
title: test_threadsignals.py hanging on AIX -> interruption of locks by signals not guaranteed when the semaphore implementation is not used
Added file: http://bugs.python.org/file20772/test_threadsignals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:40:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:40:23 +0000
Subject: [issue8844] Condition.wait() doesn't raise KeyboardInterrupt
In-Reply-To: <1275065292.27.0.238026363438.issue8844@psf.upfronthosting.co.za>
Message-ID: <1297870823.7.0.790381253352.issue8844@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8844>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:40:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:40:47 +0000
Subject: [issue10720] test_threadsignals hang on FreeBSD 6.4
In-Reply-To: <1292522526.66.0.947822056177.issue10720@psf.upfronthosting.co.za>
Message-ID: <1297870847.12.0.257983033213.issue10720@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> interruption of locks by signals not guaranteed when the semaphore implementation is not used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10720>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:41:04 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 15:41:04 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297870864.47.0.28020851596.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks Antoine, the patch solved the problem.

I have other tests locking semi-randomly on AIX 5.3 and/or AIX 6.1, like test_socket and test_io. That may be related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:41:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:41:37 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297870897.93.0.177045742675.issue11223@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:43:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:43:11 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297870864.47.0.28020851596.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297870986.3726.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I have other tests locking semi-randomly on AIX 5.3 and/or AIX 6.1,
> like test_socket and test_io. That may be related.

Which test cases exactly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 16:49:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 15:49:27 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297871367.82.0.31530893343.issue11184@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:24:11 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 16:24:11 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297873451.52.0.539569284841.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Well I don't know precisely:

* when running make buildbottest, test_socket will systematically hang on AIX 5.3 and 6.1.

* but when running ./python -Wd -E -bb Lib/test/test_socket.py, the tests complete rather quickly (with one failure cf 11192).

Ran 158 tests in 16.867s

FAILED (failures=1, skipped=4)

I will try with pdb or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:27:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 16:27:56 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297873451.52.0.539569284841.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297873673.3726.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well I don't know precisely:
> 
> * when running make buildbottest, test_socket will systematically hang
> on AIX 5.3 and 6.1.
> 
> * but when running ./python -Wd -E -bb Lib/test/test_socket.py, the
> tests complete rather quickly (with one failure cf 11192).

You can run the whole test suite in verbose mode. This will pollute your
terminal a lot, but you'll see exactly where it hangs.

Try something like "./python -E -bb -m test.regrtest -uall -v"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:35:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 16:35:03 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1297874103.83.0.593890703113.issue9523@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Here is my updated patch:
You don?t have to attach a file here, just update the codereview page instead.  Or maybe you can?t because I created the page?

> 1, Now the dbm view objects are the same as dict view objects, which
> are in conformity with collections.KeysView, ValuesView and ItemsView.
Great!  Just to make sure: How do you know that the view objects are compliant?  Do you test all the methods documented for the ABCs?

> 2, I register all these abcs explicitly because these abcs have not
> __subclasshook__() method so they can't check api conformance(at
> lease exist) through isinstance(). I could not make sure api
> conformance except testing each method I find in abc explicitly. And
> my test_abc() is just to test the registering.

Thank you for repeating that many times and politely: I was indeed wrong.  I went back to  PEP 3119 to read again about __instancecheck__ and __subclasscheck__, then experimented in a shell and was surprised.  I have been misunderstanding one thing: issubclass(cls, abc) does not return true automatically if cls provides the methods, it?s entirely up to the ABC to check methods or do something else in its __subclasscheck__ or __instancecheck__ methods.  (I should have known better, I was in a discussion about adding that very feature on python-ideas and #9731!)  After another bit of experimentation with dict views and collections ABCs, I finally understand that you have to register your view classes.  Thanks for letting me correct my misunderstanding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:48:07 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Feb 2011 16:48:07 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297874887.28.0.816745370548.issue11222@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:55:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 16:55:10 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297873451.52.0.539569284841.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297875297.18444.14.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I will try with pdb or something.

You can also try to attach gdb to the running process: with
python-gdb.py, you have nice py-* commands.

Or if you don't have gdb7, you may try my faulthandler module: you will
have to modify the source code (eg. Lib/test/regrtest.py) to add at the
top:

   import faulthandler, signal; faulthandler.register(signal.SIGUSR1)

Then you can display the current Python backtrace by sending a SIGUSR1
signal to the running Python process (eg. killall -USR1 python).

https://github.com/haypo/faulthandler/wiki

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 17:55:37 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Wed, 16 Feb 2011 16:55:37 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297875337.09.0.164618601315.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

test_socket didnot lock this time (I will retry next).

But test_subprocess.ProcessTestCasePOSIXPurePython.test_leaking_fds_on_error did.

Looping forever on the following syscall:

pipe(0x2FF1FD88)                                = 0
kfcntl(15, F_GETFD, 0x00000000)                 = 0
kfcntl(15, F_SETFD, 0x00000001)                 = 0
kfcntl(17, F_GETFD, 0x00000000)                 = 0
kfcntl(17, F_SETFD, 0x00000001)                 = 0
pipe(0x2FF1FD88)                                = 0
kfcntl(18, F_GETFD, 0x00000000)                 = 0
kfcntl(18, F_SETFD, 0x00000001)                 = 0
kfcntl(19, F_GETFD, 0x00000000)                 = 0
kfcntl(19, F_SETFD, 0x00000001)                 = 0
fstatx(15, 0x2FF1FAEC, 76, 0)                   = 0
kioctl(15, 22528, 0x00000000, 0x00000000)       Err#25 ENOTTY
fstatx(15, 0x2FF1FD7C, 76, 0)                   = 0
lseek(15, 0, 1)                                 Err#29 ESPIPE
fstatx(18, 0x2FF1FAEC, 76, 0)                   = 0
kioctl(18, 22528, 0x00000000, 0x00000000)       Err#25 ENOTTY
fstatx(18, 0x2FF1FD7C, 76, 0)                   = 0
lseek(18, 0, 1)                                 Err#29 ESPIPE
pipe(0x2FF1FD08)                                = 0
kfcntl(20, F_GETFD, 0x00000000)                 = 0
kfcntl(20, F_SETFD, 0x00000001)                 = 0
kfcntl(21, F_GETFD, 0x00000000)                 = 0
kfcntl(21, F_SETFD, 0x00000001)                 = 0
sigprocmask(0, 0xF029C148, 0xF029C150)          = 0
kfork()                                         = 2011158
thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0xD0504100, 0x00000000, 0x1216F00B, 0x1216F00B, 0x00000000) = 0x00000000
close(21)                                       = 0
close(17)                                       = 0
close(19)                                       = 0
kread(20, " O S E r r o r : 2 :\0 i".., 50000)  = 10
kread(20, 0x33041C38, 50000)                    = 0
close(20)                                       = 0
kwaitpid(0x2FF1FB50, 2011158, 4, 0x00000000, 0x00000000) = 2011158
close(15)                                       = 0
close(18)                                       = 0
close(15)                                       Err#9  EBADF
close(18)                                       Err#9  EBADF
pipe(0x2FF1FD88)                                = 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:42:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Feb 2011 17:42:10 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297878130.39.0.249689847779.issue11222@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:43:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Feb 2011 17:43:17 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297878197.86.0.689848141208.issue11184@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Antoine, do you agree?  I don't want waves of AIX changes going into 3.2 now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:49:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 17:49:53 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297878593.42.0.624689550182.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Assuming it doesn't break other platforms, I'm fine with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Wed Feb 16 18:52:48 2011
From: report at bugs.python.org (Ian Wetherbee)
Date: Wed, 16 Feb 2011 17:52:48 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297878768.39.0.631417984824.issue11220@psf.upfronthosting.co.za>


Ian Wetherbee <ian.wetherbee at gmail.com> added the comment:

Any solution for 2.x? I'm using this with twisted.

----------
resolution: rejected -> 
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:12:27 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 16 Feb 2011 18:12:27 +0000
Subject: [issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

tarfile.getmembers has become extremely slow on Windows. This was triggered in r85916 by Lars Gustaebel on Oct 29, 2010 to "add read support for all missing variants of the GNU sparse extensions".

To reproduce, use this "tgz" file:

  http://pypm-free.activestate.com/3.2/win32-x86/pool/a/as/as.mklruntime-1.2_win32-x86_3.2_1.pypm

It contains another tgz file called "data.tar.gz". Run `.getmembers()` on data.tar.gz.

...

This invokes tarfile._FileInFile.read(...) that seems to be cause of slowness (or rather a hang). 

I had to workaround this issue by monkey-patching the above `read` function to revert the change:

+if sys.version_info[:2] >= (3,2):
+    import tarfile
+    class _FileInFileNoSparse(tarfile._FileInFile):
+        def read(self, size):
+            if size is None:
+                size = self.size - self.position
+            else:
+                size = min(size, self.size - self.position)
+            self.fileobj.seek(self.offset + self.position)
+            self.position += size
+            return self.fileobj.read(size)
+    tarfile._FileInFile = _FileInFileNoSparse
+    LOG.info('Monkey patching `tarfile.py` to disable part of r85916 (py3k)')

We caught this bug as part of testing ActiveState PyPM on Python 3.2
http://bugs.activestate.com/show_bug.cgi?id=89376#c3

If you want the easiest way to reproduce this, I can send you (in private) an internal build of ActivePython-3.2 containing PyPM. Running "pypm install numpy" (with breakpoints in tarfile.py) is all that is required to reproduce.

----------
components: Library (Lib), Windows
messages: 128685
nosy: lars.gustaebel, srid
priority: normal
severity: normal
status: open
title: 3.2: tarfile.getmembers causes 100% cpu usage on Windows
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11224>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:17:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 18:17:04 +0000
Subject: [issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1297880224.2.0.0603274318558.issue11224@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: resource usage -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11224>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:23:20 2011
From: report at bugs.python.org (Ian Wetherbee)
Date: Wed, 16 Feb 2011 18:23:20 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1297880600.05.0.920770508457.issue11220@psf.upfronthosting.co.za>


Ian Wetherbee <ian.wetherbee at gmail.com> added the comment:

This works for 2.x, I'm closing this issue:

# custom HTTPS opener, banner's oracle 10g server supports SSLv3 only
import httplib, ssl, urllib2, socket
class HTTPSConnectionV3(httplib.HTTPSConnection):
    def __init__(self, *args, **kwargs):
        httplib.HTTPSConnection.__init__(self, *args, **kwargs)
        
    def connect(self):
        sock = socket.create_connection((self.host, self.port), self.timeout)
        if self._tunnel_host:
            self.sock = sock
            self._tunnel()
        try:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_SSLv3)
        except ssl.SSLError, e:
            print("Trying SSLv3.")
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file, ssl_version=ssl.PROTOCOL_SSLv23)
            
class HTTPSHandlerV3(urllib2.HTTPSHandler):
    def https_open(self, req):
        return self.do_open(HTTPSConnectionV3, req)
# install opener
urllib2.install_opener(urllib2.build_opener(HTTPSHandlerV3()))

if __name__ == "__main__":
    r = urllib2.urlopen("https://ui2web1.apps.uillinois.edu/BANPROD1/bwskfcls.P_GetCrse")
    print(r.read())

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:43:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Feb 2011 18:43:46 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297881826.75.0.393419483988.issue11221@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Are you positive that your 'all' is the builtin Python 'all'?  NumPy's 'all' function would behave the way you describe:

>>> all(x < 3 for x in range(5))
False
>>> from numpy import all
>>> all(x < 3 for x in range(5))
True

What does all.__module__ give?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:50:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Feb 2011 18:50:00 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297882200.36.0.484067538414.issue11221@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

And voila:

>>> from numpy import bool_
>>> bool_
<type 'numpy.bool_'>

Case closed, I guess :)

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 19:57:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Feb 2011 18:57:10 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1297882630.95.0.993850534583.issue1726687@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Backported in r88425 (3.1) and r88427 (2.7).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:43:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Feb 2011 19:43:39 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297885419.32.0.182122991741.issue11221@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Numpy tried to frame Python's innocent all() function.  The crime was almost perfect, but the forensic evidence showed that the real culprit had left behind a telltale underscore after the bool.

Another lurid bug report brought to justice :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 20:57:10 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 16 Feb 2011 19:57:10 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297886230.11.0.78597024712.issue11135@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's the same as the current tp_doc parameter for static type objects, and essentially like any other doc string in the C API. It's owned by the extension module, which must make sure it lives at least as long as the type object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11135>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:04:16 2011
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Wed, 16 Feb 2011 20:04:16 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1297886656.42.0.962179804562.issue1649329@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

The more I think about this, the more I think we should just drop it.

 * The easiest way around my original problem was to not install the eggs in zipped format.  That's easy.  Just mark the egg as not zip safe.
 * I don't currently need this functionality.
 * No one else is clamoring about it.

I think the increase in complexity just isn't warranted.  If someone is really stuck, they can just hack their own version of gettext.  It's not that big a deal, and it's fairly unlikely anyway.

Sorry for taking so long to respond; have 6 kids really makes keeping up with extracurricular activities difficult!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:34:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 20:34:05 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1297888445.56.0.266042285979.issue1649329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fine, let?s close this then.  Don?t hesitate to propose a patch for another bug report or feature request if you get enough free time someday :)

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:39:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Feb 2011 20:39:35 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297888775.02.0.255741037349.issue11219@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> That's almost what the PEP says, or at least what I understand of it.
I?ve probably misused ?not quite?; I meant ?not exactly?.  Allow me to try to translate the PEP text to pseudo-code:

> Platform (multiple use)
> A Platform specification describing an operating system supported by
> the distribution which is not listed in the "Operating System" Trove
> classifiers.

if 'platform' in meta:
    if 'Operating System' in meta['classifiers']:
        warnings.append('the "platform" keyword duplicates the "Platform" classifier')
    else:
        warnings.append('using a "platform" keyword instead of a classifier, please make sure there is no classifier for this platform')

> License (optional)
> Text indicating the license covering the distribution where the
> license is not a selection from the "License" Trove classifiers. See
> "Classifier" below. This field may also be used to specify a
> particular version of a licencse which is named via the Classifier
> field, or to indicate a variation or exception to such a license.

if 'license' in meta:
    if 'License' in meta['classifiers']:
        warnings.append('using a "license" keyword with a "License" classifier, please make sure the keyword does not duplicate the classifier but precises it')
    else:
        warnings.append('using a "license" keyword instead of a classifier, please make sure there is no classifier for this license')


My pseudo-code assumes that meta['classifiers'].__contains__ can get all matching classifiers (for example all classifiers of the 'Operating System' category), not just perform exact matching against a list of strings.  I?ve just sent a message to the fellowship ML to brainstorm about a better data structure to model and work with classifiers; if we reach agreement, I?ll open another bug about that and make this one depend on the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:40:12 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Wed, 16 Feb 2011 20:40:12 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297888812.81.0.612033439927.issue11221@psf.upfronthosting.co.za>


Jonathan Livni <jonathan.livni at gmail.com> added the comment:

from pylab import *

There lies the rub?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Wed Feb 16 21:58:07 2011
From: report at bugs.python.org (Egon Smiwa)
Date: Wed, 16 Feb 2011 20:58:07 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297889887.88.0.949282415141.issue11135@psf.upfronthosting.co.za>


Egon Smiwa <smiwa.egon at googlemail.com> added the comment:

Hello, I'm just a app developer which is embedding the python32.dll
and I assumed (and wished) python would simply copy my allocated parameter-string into the type object (( spec->name) is copied too). I looked in the source and see this ownership confirmed:

static void 
type_dealloc(PyTypeObject *type)
.... PyObject_Free((char *)type->tp_doc);

The typeobject owns tp_doc and even requires a special allocation (pyobject_malloc), which is no problem if the type creates its own copy; the hosting app is not connected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11135>
_______________________________________

From report at bugs.python.org  Wed Feb 16 22:05:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 16 Feb 2011 21:05:55 +0000
Subject: [issue11135] Redundant doc field in TypeSpec
In-Reply-To: <1297022526.69.0.942677467531.issue11135@psf.upfronthosting.co.za>
Message-ID: <1297890355.42.0.333334382543.issue11135@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. This is an issue independent of the issue discussed here, though, please open a new issue for that. I agree that either tp_dealloc should not release the string, or should make a copy that it can release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11135>
_______________________________________

From report at bugs.python.org  Wed Feb 16 23:18:09 2011
From: report at bugs.python.org (Nicolas Joly)
Date: Wed, 16 Feb 2011 22:18:09 +0000
Subject: [issue11225] getcwd fix for NetBSD to handle ERANGE errno
In-Reply-To: <1297894688.76.0.163416819421.issue11225@psf.upfronthosting.co.za>
Message-ID: <1297894688.76.0.163416819421.issue11225@psf.upfronthosting.co.za>


New submission from Nicolas Joly <njoly at pasteur.fr>:

NetBSD do require the very same fix from issue 9185, to handle ERANGE errno returned when the size argument is greater than zero but smaller
than the length of the pathname plus 1.

Without it, the testsuite do indeed loops indefinitely.

Thanks.

----------
components: Interpreter Core
files: python-getcwd.diff
keywords: patch
messages: 128698
nosy: njoly
priority: normal
severity: normal
status: open
title: getcwd fix for NetBSD to handle ERANGE errno
versions: Python 2.7
Added file: http://bugs.python.org/file20773/python-getcwd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11225>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:04:12 2011
From: report at bugs.python.org (Yang Zhang)
Date: Wed, 16 Feb 2011 23:04:12 +0000
Subject: [issue11226] subprocesses experience mysterious delay in receiving
	stdin EOF
In-Reply-To: <1297897452.24.0.902821859924.issue11226@psf.upfronthosting.co.za>
Message-ID: <1297897452.24.0.902821859924.issue11226@psf.upfronthosting.co.za>


New submission from Yang Zhang <yang.pythonbugs at mailnull.com>:

I'm seeing this issue on all the multiple Ubuntu 10.04 boxes I've tried.

I reduced a problem I was seeing in my application down into the following test case. In this code, a parent process concurrently spawns 2 (you can spawn more) subprocesses that read a big message from the parent over stdin, sleep for 5 seconds, and write something back. However, there's unexpected waiting happening somewhere, causing the code to complete in 10 seconds instead of the expected 5.

If you set verbose=True, you can see that the straggling subprocess is receiving most of the messages, then waiting for the last chunk of 3 chars---it's not detecting that the pipe has been closed. Furthermore, if I simply don't do anything with the second process (doreturn=True), the first process will never see the EOF.

Further down is some example output. When trying this out, you may need to increase the message size to see the behavior occur.

from subprocess import *
from threading import *
from time import *
from traceback import *
import sys
verbose = False
doreturn = False
msg = (20*4096+3)*'a'
def elapsed(): return '%7.3f' % (time() - start)
if sys.argv[1:]:
  start = float(sys.argv[2])
  if verbose:
    for chunk in iter(lambda: sys.stdin.read(4096), ''):
      print >> sys.stderr, '..', time(), sys.argv[1], 'read', len(chunk)
  else:
    sys.stdin.read()
  print >> sys.stderr, elapsed(), '..', sys.argv[1], 'done reading'
  sleep(5)
  print msg
else:
  start = time()
  def go(i):
    print elapsed(), i, 'starting'
    p = Popen(['python','stuckproc.py',str(i), str(start)], stdin=PIPE, stdout=PIPE)
    if doreturn and i == 1: return
    print elapsed(), i, 'writing'
    p.stdin.write(msg)
    print elapsed(), i, 'closing'
    p.stdin.close()
    print elapsed(), i, 'reading'
    p.stdout.read()
    print elapsed(), i, 'done'
  ts = [Thread(target=go, args=(i,)) for i in xrange(2)]
  for t in ts: t.start()
  for t in ts: t.join()

Example output:

  0.001 0 starting
  0.003 1 starting
  0.005 0 writing
  0.016 1 writing
  0.093 0 closing
  0.093 0 reading
  0.094 1 closing
  0.094 1 reading
  0.098 .. 1 done reading
  5.103 1 done
  5.108 .. 0 done reading
 10.113 0 done

----------
components: Library (Lib)
messages: 128699
nosy: yaaang
priority: normal
severity: normal
status: open
title: subprocesses experience mysterious delay in receiving stdin EOF
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11226>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:26:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 16 Feb 2011 23:26:29 +0000
Subject: [issue11227] [DOC] asyncore - use 'Host' header in HTTP example
In-Reply-To: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>
Message-ID: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003096.html I wrote a patch to introduce the 'Host' header in the HTTP example of asyncore doc. I've also fixed an indentation error with the last 2 lines of the same example (simple cut&paste would fail with "unexpected intentantion").

Given it's a doc issue, and it quite easy, I think it should be backported to the current on-maintainence releases (the example fails on all of them).

----------
assignee: sandro.tosi
components: Documentation
files: asyncore-use-host-header-py3k.patch
keywords: patch
messages: 128700
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: [DOC] asyncore - use 'Host' header in HTTP example
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20774/asyncore-use-host-header-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11227>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:29:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 23:29:26 +0000
Subject: [issue11228] raw unicode strings interpret \u and \U (but not \n, \xHH,
	...)
In-Reply-To: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>
Message-ID: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

len(ur'\u0000') == len(u'\u0000') == 1
len(ur'\U0010FFFF') == len(u'\U0010FFFF') == 1

but

>>> len(ur'\n'), len(u'\n')
(2, 1)
>>> len(ur'\x00'), len(u'\x00')
(4, 1)

\u and \U should not be interpreted in raw Unicode strings.

----------
messages: 128701
nosy: haypo
priority: normal
severity: normal
status: open
title: raw unicode strings interpret \u and \U (but not \n, \xHH, ...)
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11228>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:34:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 16 Feb 2011 23:34:42 +0000
Subject: [issue11229] Make the Mac installer more like the Windows installer
In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>
Message-ID: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The Windows installer gives a choice of two install locations, for all users and for the current user; the latter does not require admin rights.  

It lists optional components, giving the size of each:
- Register Extensions 2kb
- Tcl/Tk 13mb (includes IDLE)
- Documentation 5Mb
- Utility Scripts 632kb
- Test Suite 9.7Mb.  
The default is to install all of those.

The installer removes any previous versions before installing (including wiping their __pycache__ directories).

With the full install, the listing in All Programs (the windows parallel to the Application Folder) includes five entries:
- IDLE (gui)
- Module Docs (via pydoc)
- Python (command-line terminal)
- Python Manuals (points to a chm file)
- Uninstall Python.

In addition to what is offered on Windows, I think there should be an addition entry in the Application Folder for running the test suite so that some one can validate their install without going to the command-line.

----------
components: Installation
messages: 128702
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make the Mac installer more like the Windows installer
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11229>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:46:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Feb 2011 23:46:10 +0000
Subject: [issue11227] [DOC] asyncore - use 'Host' header in HTTP example
In-Reply-To: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>
Message-ID: <1297899970.16.0.839171582264.issue11227@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11227>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:55:19 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 16 Feb 2011 23:55:19 +0000
Subject: [issue11228] raw unicode strings interpret \u and \U (but not \n, \xHH,
	...)
In-Reply-To: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>
Message-ID: <1297900519.49.0.725045114906.issue11228@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This has changed in python 3, and is even documented: http://docs.python.org/dev/py3k/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit (6th bullet)

Python 2.x could not be changed, for compatibility reasons.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11228>
_______________________________________

From report at bugs.python.org  Thu Feb 17 00:57:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Feb 2011 23:57:02 +0000
Subject: [issue11228] raw unicode strings interpret \u and \U (but not \n, \xHH,
	...)
In-Reply-To: <1297898966.02.0.67619650585.issue11228@psf.upfronthosting.co.za>
Message-ID: <1297900622.27.0.569570870428.issue11228@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Python 2.x could not be changed, for compatibility reasons.

Well, it is not a bug because it is documented!

<< When an 'r' or 'R' prefix is used in conjunction with a 'u' or 'U' prefix, then the \uXXXX and \UXXXXXXXX escape sequences are processed while all other backslashes are left in the string. >>

I agree that Python2 cannot be changed, but this behaviour is a little bit surprising :-) Let's move to Python3!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11228>
_______________________________________

From report at bugs.python.org  Thu Feb 17 01:20:39 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 17 Feb 2011 00:20:39 +0000
Subject: [issue11229] Make the Mac installer more like the Windows installer
In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>
Message-ID: <1297902039.74.0.397630128593.issue11229@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11229>
_______________________________________

From report at bugs.python.org  Thu Feb 17 01:37:58 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Feb 2011 00:37:58 +0000
Subject: [issue11227] [DOC] asyncore - use 'Host' header in HTTP example
In-Reply-To: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>
Message-ID: <1297903078.01.0.904618636711.issue11227@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11227>
_______________________________________

From report at bugs.python.org  Thu Feb 17 01:53:58 2011
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 17 Feb 2011 00:53:58 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297904038.17.0.561477896766.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

The patch definitely helps.  However, once I get it installed, there seems to be no time module:
   >>> import time
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   ImportError: No module named time

So I think there's probably still something not quite right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 02:03:14 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 17 Feb 2011 01:03:14 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297904594.84.0.494142619734.issue11222@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"import time" works for me with the patched build.  There should have been a warning message during the build if the time module failed to build.  Perhaps you have a file permissions problem?  Check your lib/python3.2/lib-dynload/ for file time.so 

BTW, Victor's supplied patch is fine for fixing the shared lib target but should not include the framework build changes - that's an unrelated issue.  I will upload a revised patch for review after completing some more tests.  This should be included in 3.2final. And we have a hole in building and testing shared library configurations on OS X, even though that configuration isn't used as much as the OS X framework one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 02:47:03 2011
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 17 Feb 2011 01:47:03 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297907223.16.0.160097111182.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Looks like the time module is being built:
    ./build/lib.macosx-10.4-x86_64-3.2/time.so

But none of the shared modules are being installed, as lib/python3.2/lib-dynload is completely empty.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 02:59:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2011 01:59:04 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1297907944.84.0.142196552032.issue11184@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This looks to be a low risk fix-up (confined to an "if $use_lfs" block in configure.in and further guarded with a case statement restricting it to AIX builds).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Thu Feb 17 04:21:40 2011
From: report at bugs.python.org (Kelsey)
Date: Thu, 17 Feb 2011 03:21:40 +0000
Subject: [issue11219] Produce a warning when the license is specified in both
	the License and Classifier metadata fields
In-Reply-To: <1297826569.81.0.596233570494.issue11219@psf.upfronthosting.co.za>
Message-ID: <1297912900.57.0.0227588593189.issue11219@psf.upfronthosting.co.za>


Kelsey <kelsey.hightower at gmail.com> added the comment:

Eric, thanks for the example. This clarifies things.

+1 on the new data structure for the classifiers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11219>
_______________________________________

From report at bugs.python.org  Thu Feb 17 08:10:36 2011
From: report at bugs.python.org (John)
Date: Thu, 17 Feb 2011 07:10:36 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>


New submission from John <jh45dev at gmail.com>:

A few months ago I read that in 3.2 it will be possible to import modules that are located on paths containing any unicode character. (more precisely, with chars not in the local code page)

After an hour or two trying to get this to work in 3.2rc3, I went looking for clues, and found these 2 messages in which Victor Stinner says this feature is delayed until Python 3.3:
http://bugs.python.org/issue3080#msg126514
http://bugs.python.org/issue10828#msg125787

Could you please make it clear in documentation and web pages, that this feature is not working yet. 

The Python 3.2 download page includes this:
"countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables)"
and I guessed this must cover importing from any unicode path, as there was no mention that such importing had been abandoned for this version.

-- jh

----------
assignee: docs at python
components: Documentation
messages: 128711
nosy: docs at python, jh45
priority: normal
severity: normal
status: open
title: "Full unicode import system" not in 3.2
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11230>
_______________________________________

From report at bugs.python.org  Thu Feb 17 09:18:02 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 17 Feb 2011 08:18:02 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297930682.43.0.42832026352.issue11222@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

You did run "sudo make install"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 09:36:14 2011
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 17 Feb 2011 08:36:14 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297931774.19.0.32665023485.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

I'm installing into an area that I own ($HOME/.local/python3), so no need for sudo.  I just ran make install.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:07:08 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 17 Feb 2011 09:07:08 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297933628.05.0.904575447618.issue11222@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

'make install' works for me as well (OSX 10.6, configure --prefix=/tmp/python32).

Could you attach the output of "make install", with some luck there will be a clear indication of why the install doesn't work on your machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:14:54 2011
From: report at bugs.python.org (Jonathan Livni)
Date: Thu, 17 Feb 2011 09:14:54 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297934094.87.0.0391730111344.issue11221@psf.upfronthosting.co.za>


Jonathan Livni <jonathan.livni at gmail.com> added the comment:

Let my foolishness be a reminder to all not to use "from [module] import *"

After saying that - I believe overloading a built in Python function in a popular package\module is a mistake!

I still don't know if pylab's all() is erroneous or if it's correct functionality. I'll open a ticket there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:21:29 2011
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 17 Feb 2011 09:21:29 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297934489.15.0.359243056776.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

Attached the output.

----------
Added file: http://bugs.python.org/file20775/make-install-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 10:32:35 2011
From: report at bugs.python.org (John Szakmeister)
Date: Thu, 17 Feb 2011 09:32:35 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297935155.24.0.412003174024.issue11222@psf.upfronthosting.co.za>


John Szakmeister <john at szakmeister.net> added the comment:

This one is my fault.  I have a .pydistutils.cfg that was causing them to be installed somewhere else or not at all. :-(  Moving my custom config out of the way, I'm good.  I'm not sure what's happening there, but that's a different problem. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:44:48 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 10:44:48 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297939488.23.0.100766018668.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is what faulthandler reports when I trigger it as Python is locked in test_socket:

"""
[108/349] test_socket
Traceback (most recent call first):
  File "/san_cis/home/cis/.buildbot/python-aix6/3.x.phenix.xlc/build/Lib/test/fork_wait.py", line 30 in f
""" (sic)

It is coherent with what truss tells:
_getpid()                                       = 1474634
_select(0, 0x00000000, 0x00000000, 0x00000000, 0x317535F0) = 0
_getpid()                                       = 1474634
_select(0, 0x00000000, 0x00000000, 0x00000000, 0x315E35F0) = 0
....

And we can find this comment in the file:
# waitpid() shouldn't hang, but some of the buildbots seem to hang
# in the forking tests.  This is an attempt to fix the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:47:16 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 10:47:16 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297939636.31.0.703649575235.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

faulthandler is great by the way! I will use that in my application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:55:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 10:55:14 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297940114.36.0.174119480095.issue11223@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here is what faulthandler reports when I trigger it as Python
> is locked in test_socket:
> ...
>  File ".../Lib/test/fork_wait.py", line 30 in f

faulthandler doesn't print the source code line (yet?). Here is the code:

class ForkWait(unittest.TestCase):
    ...
    def f(self, id):
        while not self.stop:
            self.alive[id] = os.getpid()
            try:
                time.sleep(SHORTSLEEP) <~~~ here
            except IOError:
                pass

ForkWait.f() is used by ForkWait.test_wait() which creates 4 threads. You may use all_threads=True option of faulthandler to get the backtrace of all threads.

Because ForkWait.test_wait() uses fork, you may also need to dump the backtrace of two processes.

Debug threads+multiple processes is something horrible :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 11:59:32 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 10:59:32 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297940372.0.0.867634319157.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

At the time of the lock, there is only one python process running. So I guess the other processes have already left but this is not correctly detected.

I will try again with all_threads=True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:07:31 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 11:07:31 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297940851.0.0.616179420697.issue11223@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I kinda feel this is related to issue 11185 which I reported earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:17:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 11:17:50 +0000
Subject: [issue11223] interruption of locks by signals not guaranteed when the
	semaphore implementation is not used
In-Reply-To: <1297866341.73.0.301134351964.issue11223@psf.upfronthosting.co.za>
Message-ID: <1297941470.87.0.996984784143.issue11223@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you open another issue? (or post in issue 11185 above)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11223>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:18:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 11:18:48 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1297941528.26.0.629531637017.issue11230@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11230>
_______________________________________

From report at bugs.python.org  Thu Feb 17 12:29:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 11:29:46 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1297942186.17.0.881583604641.issue11230@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Short answer:

In Python 3.2, ??import h?h? ??doesn't work on Windows, but you can have non-ASCII paths in sys.path.

Longer answer:

I fixed the import machinery to handle correctly non-ASCII characters in module *paths*. But the import machinery is unable to handle non-ASCII characters in module *names*: it fails if the filesystem encoding is not UTF-8 (eg. it fails on Windows). There is another exception: Python doesn't support (yet) non encodable module paths on Windows. On Windows, you can use any character in directory names, but Python 3.2 encodes paths to the filesystem encoding (ANSI code page) which is a smaller charset. In practical, this Windows specific limitation on module paths doesn't really matter.

I plan to fix all these issues in Python 3.3: see #3080.

--

> Could you please make it clear in documentation and web pages,
> that this feature is not working yet. 

What's New in Python 3.2 documentation has this sentence: "Python?s import mechanism can now load modules installed in directories with non-ASCII characters in the path name. This solved an aggravating problem with home directories for users with non-ASCII characters in their usernames." which is correct.

Which web page should updated/fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11230>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:07:12 2011
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 17 Feb 2011 14:07:12 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297951632.53.0.32370830023.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks hyapo! 

> It looks like your patch fixes #10829: you should add tests for that, you can just reuse the tests of my patch (attached to #10829).

Sorry, but I think my patch doesn't fix #10829. It seems link another issue. And by applying my patch and add tests from #10829's patch, the tests cannot passed. Or did I missed something?


> You should also avoid the creation of a temporary unicode object (it can be slow if precision is large) using PySequence_GetSlice(). Py_UNICODE_COPY() does already truncate the string because you can pass an arbitrary length.

In order to use Py_UNICODE_COPY, I have to create a unicode object with required length first. I feel this have the same cost as using PySequence_GetSlice(). If I understand correctly?


> With your patch, "%.200s" truncates the input string to 200 *characters*, but I think that it should truncate to 200 *bytes*, as printf does.

Sorry, I don't understand. The result of PyUnicode_FromFormatV() is a unicode object. Then how to truncate to 200 *bytes*? I think the %s formatter just indicate that the argument is c-style chars, the result is always unicode string, and the width and precision formatters are to applied after converting c-style chars to string. 


> I don't like this change because I hate having to compute manually strings length. It should that it would be easier if you format directly strings with width and precision at step 3, instead of doing it at step 4: so you can just read the length of the formatted string, and it avoids having to handle width/precision in two steps (which may be inconsistent :-/).

Do you mean combine step 3 and step 4 together? Currently step 3 is just to compute the biggest width value and step 4 is to compute exact width and do the real format work. Only by doing real format we can get the exact width of a string. So I have to compute each width twice in both step 3 and step 4. Is combining the two steps in to one a good idea?


> In my opinion, the patch is a little bit too big. We may first commit the fix on the code parsing the width and precision: fix #10829?

Again, I guess #10829 need another its own patch to fix. 


> Can you add tests for "%.s"? I would like to know if "%.s" is different than "%s" :-)

Err, '%.s' causes unexpected result both with and without my patch. Maybe it's still another bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Thu Feb 17 15:57:57 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 14:57:57 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297954677.49.0.0928335929671.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Could this doc be added before the 3.2 release?
I think it is convenient for the (few) AIX users and harmless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:05:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 15:05:06 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297955106.73.0.908755427415.issue10709@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:19:37 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 15:19:37 +0000
Subject: [issue11185] test_wait4 error on AIX
In-Reply-To: <1297424402.38.0.348928652961.issue11185@psf.upfronthosting.co.za>
Message-ID: <1297955977.94.0.123892289065.issue11185@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

This issue already existed on Python 2.5.2 with AIX 5.2:

http://www.mail-archive.com/python-list at python.org/msg192219.html

The documentation for WNOHANG says:
http://docs.python.org/library/os.html#os.WNOHANG
"""
The option for waitpid() to return immediately if no child process status is available immediately. The function returns (0, 0) in this case.
"""

It seems wait4 always returns 0 on AIX when WNOHANG is specified.

Removing WNOHANG will make the test succeed.

waitpid does not have the same limitation.

I suppose this is a bug of AIX, though there is not even a man page to describe wait4 on this platform.

Here is a proposition for a patch that will workaround this bug...

Index: Lib/test/test_wait4.py
===================================================================
--- Lib/test/test_wait4.py      (revision 88430)
+++ Lib/test/test_wait4.py      (working copy)
@@ -3,6 +3,7 @@
 
 import os
 import time
+import sys
 from test.fork_wait import ForkWait
 from test.support import run_unittest, reap_children, get_attribute
 
@@ -13,10 +14,14 @@
 
 class Wait4Test(ForkWait):
     def wait_impl(self, cpid):
+        option = os.WNOHANG
+        if sys.platform.startswith('aix'):
+            # wait4 is broken on AIX and will always return 0 with WNOHANG
+            option = 0
         for i in range(10):
             # wait4() shouldn't hang, but some of the buildbots seem to hang
             # in the forking tests.  This is an attempt to fix the problem.
-            spid, status, rusage = os.wait4(cpid, os.WNOHANG)
+            spid, status, rusage = os.wait4(cpid, option)
             if spid == cpid:
                 break
             time.sleep(1.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11185>
_______________________________________

From report at bugs.python.org  Thu Feb 17 16:52:07 2011
From: report at bugs.python.org (Eric Smith)
Date: Thu, 17 Feb 2011 15:52:07 +0000
Subject: [issue9334] argparse does not accept options taking arguments
	beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1297957927.4.0.0624155163789.issue9334@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

[I doubt my terminology is exactly correct in this post, but I've tried my best to make it so.)

The more I think about this the more I realize we can't implement a parser that doesn't make guesses about '-' prefixed args and that works with arparse's existing behavior with respect to optional arguments.

For example:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs='?')
parser.add_argument('--bar', nargs='?')
print parser.parse_args(['--foo', '--bar', 'a'])
print parser.parse_args(['--foo', 'x', '--bar', 'a'])

Unless the parser tries to guess that --bar is an optional argument by itself, it can't know that --foo has an argument or not.

I guess it could look and say that if you called this with '--foo --baz', then '--baz' must be an argument for '--foo', but then you could never have an argument to '--foo' named '--bar', plus it all seems fragile.

Maybe this new parser (as Steven described it) wouldn't allow a variable number of arguments to optional arguments? That is, nargs couldn't be '?', '*', or '+', only a number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:07:30 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 16:07:30 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297958850.48.0.448211779328.issue11212@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a proofread diff.  I did make one substantive change: I added a comment about the test suite not running with the default maxdata and not raising memory errors with 512MB.  Is that correct?

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file20776/aix-notes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:07:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 17 Feb 2011 16:07:54 +0000
Subject: [issue11221] all() returns wrong result when the parameters are
	non-encapsulated list-comprehension
In-Reply-To: <1297845099.14.0.722609580039.issue11221@psf.upfronthosting.co.za>
Message-ID: <1297958874.96.0.849915120859.issue11221@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> After saying that - I believe overloading a built in Python function in
> a popular package\module is a mistake!

I believe NumPy had 'any' and 'all' *before* Python did. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11221>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:12:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Feb 2011 16:12:34 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297959154.25.0.62189724586.issue11071@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here are couple of Review Comments on What's new document.

1. The logging dictConfig example fails if you try directly out-of-text.

The conf file is opened as a 'rb' and json module throws an error as "TypeError: can't use a string pattern on a bytes-like object".  Suggestion - Just reading it as string is fine.
Also, this example throws another error from json, when you read it as string.

ValueError: Expecting property name: line 4 column 17 (char 204)

I was able to fix it by simplifying the conf.json, but I think the current one itself should be fixed and made to work.

Related suggestion - I see another section on logging further down. It would be better to combine the sections.

2.Issue number for functools.lru_cache is not mentioned. If no tracker id/ discussion is available, checkin link can be mentioned.

3. There is section for Popen which says, subprocess.Popen() functions now support with statements for auto-closing of the file descriptors. Not really. Only os.popen() function supports it.

4. In the concurrent.futures example, it is given as:

import threading, shutil
with threading.ThreadPoolExecutor(max_workers=4) as e:

It should be:
import concurrent.futures, shutil
with concurrent.futures.ThreadPoolExector(max_workers=4) as e:


Please correct these before the release on 19th.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:17:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 16:17:21 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297959441.24.0.530605461963.issue11212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

David, I think you attached your patch to the wrong issue.

S?bastien, according to the IBM docs, the memory limit can be changed using the LDR_CNTRL variable, so running the test suite shouldn't need special linker flags, or?
(also, wouldn't it be simpler to use large pages?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:34:01 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 16:34:01 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297960441.62.0.491694004445.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

The AIX documentation says:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame3.doc_5.1/am51_perftune113.htm
"""It is a good idea to unset the LDR_CNTRL environment variable, so that it does not unintentionally affect other processes."""

I think people may be more interested in setting permanently the maximum memory that can be allocated by python rather than using an environment variable that may be lost and which impacts all the applications.

Another way to increase the memory available for an application is to use the ldedit command on the python executable:

ldedit -b maxdata:0x20000000 ./python

That may be easier than passing it directly to the linker.

Concerning large pages, I found that in an IBM documentation:
"""
Users are advised to be cautious in their use of the environment
variable to specify large page usage. Performance tests have shown there
can be a significant performance loss in environments where a number of
shell scripts or small, short running applications are invoked. One
example saw a shell script's execution time increase over 10 times when
the large page environment variable was specified. Customers are advised
to only set the large page environment variable around specific
applications which can benefit from large page usage.
"""
Also large pages must be activated on the system by root. This does not seem to be available by default according to the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:36:57 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 16:36:57 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297960617.26.0.724167709939.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

The doc would become:

"""
To allocate more segment registers to Python, you must use the linker option -bmaxdata or ldedit to specify the number of bytes you need in the data
 segment.
 
For example, if you want to allow 512MB of memory for Python (this
is enough for the test suite to run without MemroyErrors), you should
run the following command at the end of compilation:

 ldedit -b maxdata:0x20000000 ./python
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:39:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 16:39:56 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297960796.74.0.153129364476.issue11212@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

oops.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:40:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 16:40:04 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297960804.11.0.670791913856.issue11212@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file20776/aix-notes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:40:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 16:40:38 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297960838.18.0.680577176041.issue10709@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a proofread diff.  I did make one substantive change: I added a comment about the test suite not running with the default maxdata and not raising memory errors with 512MB.  Is that correct?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:41:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 16:41:03 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297960863.34.0.0261914983188.issue10709@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20777/aix-notes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:42:50 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 17 Feb 2011 16:42:50 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1297960970.0.0.762300891777.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Yes it is correct. And thank you for proof reading it too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:45:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 16:45:51 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297960441.62.0.491694004445.issue11212@psf.upfronthosting.co.za>
Message-ID: <1297961145.3752.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think people may be more interested in setting permanently the
> maximum memory that can be allocated by python rather than using an
> environment variable that may be lost and which impacts all the
> applications.

Agreed, but it's impossible to standardize the configure script on a
"good enough" value. Some people might need 512MB, others 2GB...

> Another way to increase the memory available for an application is to
> use the ldedit command on the python executable:
> 
> ldedit -b maxdata:0x20000000 ./python
> 
> That may be easier than passing it directly to the linker.

Sounds better. That means that it can be decoupled from the build
process.
(although for a hypothetical buildbot, I think passing LDR_CNTRL would
be the most practical solution)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:46:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 16:46:44 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

There are 5 different usages of the bytes() constructor:

1) bytes(iterable_of_ints) -> bytes
2) bytes(string, encoding[, errors]) -> bytes
3) bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer
4) bytes(memory_view) -> bytes
5) bytes(int) <=> b'\0' * size

The docstring describes the four first usages, the documentation only (3).
http://docs.python.org/dev/library/functions.html#bytes

Note: bytes(3) accepts 2 other arguments, but I don't think that they are used: bytes(3, 'unused encoding', 'unused errors').

----------
assignee: docs at python
components: Documentation
messages: 128739
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: bytes() constructor is not correctly documented
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:52:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 16:52:18 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1297961538.52.0.983933962197.issue11231@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 3) bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer
> 4) bytes(memory_view) -> bytes

These are AFAIR the same.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Thu Feb 17 17:55:39 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 16:55:39 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1297961739.93.0.395063422111.issue11231@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> These are AFAIR the same.

So the docstring should also maybe be updated too:

$ python
>>> help(bytes)
Help on class bytes in module builtins:

class bytes(object)
 |  bytes(iterable_of_ints) -> bytes
 |  bytes(string, encoding[, errors]) -> bytes
 |  bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer
 |  bytes(memory_view) -> bytes
 |  
 |  Construct an immutable array of bytes from:
 |    - an iterable yielding integers in range(256)
 |    - a text string encoded using the specified encoding
 |    - a bytes or a buffer object
 |    - any object implementing the buffer API.
 |  
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:18:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 17 Feb 2011 18:18:02 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297966682.97.0.54838214121.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> 2.Issue number for functools.lru_cache is not mentioned. If no tracker
> id/ discussion is available, checkin link can be mentioned.
There was no tracker issue for that; the checkin is r83327, but I don?t think it would be useful to mention it in whatsnew.

> 3. There is section for Popen which says, subprocess.Popen() functions
> now support with statements for auto-closing of the file descriptors.
> Not really. Only os.popen() function supports it.
You must have missed line 752 and following of Lib/functools.py.  Brian did add context management support to Popen in response to my request in #10554.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:19:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 17 Feb 2011 18:19:03 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1297966743.46.0.123247040999.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I meant Lib/subprocess.py, of course :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:22:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 18:22:42 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003095.html I'm attaching a simple patch to avoid a traceback similar to this when a client disconnects:

error: uncaptured python exception, closing channel <__main__.EchoHandler 127.0.0.1:41884 at 0x150ae60> (<class 'socket.error'>:[Errno 9] Bad file descriptor [/home/morph/python-dev/py3k/Lib/asyncore.py|read|81] [/home/morph/python-dev/py3k/Lib/asyncore.py|handle_read_event|440] [<stdin>|handle_read|4] [/home/morph/python-dev/py3k/Lib/asyncore.py|send|550] [/home/morph/python-dev/py3k/Lib/asyncore.py|initiate_send|537] [/home/morph/python-dev/py3k/Lib/asyncore.py|send|367])

----------
assignee: sandro.tosi
files: asyncore-notraceback-py3k.patch
keywords: patch
messages: 128744
nosy: giampaolo.rodola, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: asyncore - don't throw a traceback when a client disconnects in echo server example
Added file: http://bugs.python.org/file20778/asyncore-notraceback-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:23:00 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 18:23:00 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1297966980.97.0.365396569777.issue11232@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Thu Feb 17 19:47:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Feb 2011 18:47:25 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1297968445.81.0.595248905314.issue11232@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Thu Feb 17 20:03:19 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 19:03:19 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003083.html we have a chat on #python-dev on the topic, the situation is

- all started with os.lchmod() and as.lchflags() methods not available on a Debian system
- that's because POSIX does not require those functions and then Linux systems don't provide them 
- so we then thought about clarifying, only for those 2 methods, that they might not be available with a format like "availability: some unix systems"
- then we noticed that on top of os doc there's a notice "An ?Availability: Unix? note means that this function is commonly found on Unix systems. It does not make any claims about its existence on a specific operating system." and so we thought about linking every 'Availability: Unix' to that note
- or transform that not in a footnote and link every 'Availability: Unix' for functions that might not be present to that footnote.

It's enough for the conversation dump: ideas/suggestions? :)

----------
assignee: docs at python
components: Documentation
messages: 128746
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
status: open
title: clarifying Availability: Unix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Thu Feb 17 20:22:35 2011
From: report at bugs.python.org (Carl Chenet)
Date: Thu, 17 Feb 2011 19:22:35 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>


New submission from Carl Chenet <chaica at ohmytux.com>:

Hi,

It seems a mistake could be in the "What's new in Python 3.2" (rc3) documentation in the sysconfig.get_config_var('SO') example :

>>> sysconfig.get_config_var('SO')       # find the full filename extension
'cpython-32mu.so'

On my system (Debian GNU/Linux, Python3.2rc3), the same command gives :
 
>>> sysconfig.get_config_var('SO')
'.cpython-32m.so'

A dot at the beginning of the string could be missing in the example of the current documentation. This dot also appears in the example of the PEP 3149.

Regards,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 128747
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: Possible error in What's new Python3.2(rc3) documentation (sysconfig.get_config_var)
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Thu Feb 17 20:26:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 19:26:29 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <AANLkTinmSW1cHnLhc75UXnyKaV0+UxKM5NjXT5yEJWVA@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Thu, Feb 17, 2011 at 20:22, Carl Chenet <report at bugs.python.org> wrote:
>>>> sysconfig.get_config_var('SO')
> '.cpython-32m.so'
>
> A dot at the beginning of the string could be missing in the example of the current documentation. This dot also appears in the example of the PEP 3149.

and also in a freshly built python from last checkout.

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Thu Feb 17 20:27:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 17 Feb 2011 19:27:46 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1297970866.46.0.96990645334.issue11234@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:00:55 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 17 Feb 2011 20:00:55 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297972855.54.0.0501482470824.issue11222@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Here's a minimal patch (a subset of Victor's original) that fixes the release blocker issue.  It has been tested in both a shared library build (which now works) and a framework build (which is not affected as expected).  I recommend that it be applied before 3.2final.

----------
components: +Macintosh
stage:  -> commit review
Added file: http://bugs.python.org/file20779/issue11222_osx_shared_build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:05:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 20:05:09 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1297973109.03.0.0386501107431.issue11233@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like the footnote idea.

I wonder if it would also be worth marking which functions are Posix (Availability: posix) and therefore likely to be available on all unix systems.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:09:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 20:09:50 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1297973390.61.0.651689820186.issue11233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I like the footnote idea.

Me too.

> I wonder if it would also be worth marking which functions are Posix
> (Availability: posix) and therefore likely to be available on all unix 
> systems.

POSIX has optional APIs, hasn't it?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:19:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 17 Feb 2011 20:19:57 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1297973997.73.0.658767424037.issue11233@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Good point :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:20:58 2011
From: report at bugs.python.org (Guy Kisel)
Date: Thu, 17 Feb 2011 20:20:58 +0000
Subject: [issue11235] Source files with date modifed in 2106 cause
	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>


New submission from Guy Kisel <guy.kisel at gmail.com>:

Tested in Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32

Exception thrown: OverflowError: modification time overflows a 4 byte field

Steps to reproduce:
1. Set system time to 2/8/2106 or later and modify a .py file (or use a utility to change the date modified directly).
2. Try to run or import the .py file.

This date is 2^32 seconds after the Unix epoch.

----------
components: None
messages: 128753
nosy: Guy.Kisel
priority: normal
severity: normal
status: open
title: Source files with date modifed in 2106 cause OverflowError
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11235>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:32:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 20:32:40 +0000
Subject: [issue11235] Source files with date modifed in 2106 cause
	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297974761.0.0.261402259574.issue11235@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11235>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:50:49 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 17 Feb 2011 20:50:49 +0000
Subject: [issue11235] Source files with date modifed in 2106 cause
	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297975849.14.0.799074454519.issue11235@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11235>
_______________________________________

From report at bugs.python.org  Thu Feb 17 21:56:28 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Thu, 17 Feb 2011 20:56:28 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

In python 2.5, entering ^C in a getpass prompt yields a KeyboardInterrupt. In later versions, nothing happens, and '\x03' is returned after pressing return.
In python 2.5, entering ^Z in a getpass prompt suspends the process. In later versions, nothing happens, and '\x1a' is returned after pressing return.

Pressing ctrl-C or ctrl-Z multiple times returns '\x03'/'\x1a' multiple times.

Tested versions:
Python 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.3.3] on linux2 (OK)
  getpass.py is http://svn.python.org/view/python/trunk/Lib/getpass.py?revision=43495&view=markup
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 (BAD)
  getpass.py is r76000 with the following diff:
54c54
<         except (AttributeError, ValueError):
---
>         except:
 (so it doesn't implement r74860)
Python 2.7.1 (r271:86832, Jan  4 2011, 13:57:14) [GCC 4.5.2] on sunos5 (BAD)
Python 3.1.2 (r312:79147, Sep 27 2010, 09:45:41) [GCC 4.4.3] on linux2 (BAD)
Python 3.1.3 (r313:86834, Dec  1 2010, 20:16:39) [GCC 4.5.1] on sunos5 (BAD)

Steps to reproduce:
1) import getpass
2) getpass.getpass('-> ')
3) press ctrl-C or ctrl-Z
- nothing happens
4) press return
- '\x03'/'\x1a' is returned

----------
components: Library (Lib)
messages: 128754
nosy: valhallasw
priority: normal
severity: normal
status: open
title: getpass.getpass does not respond to ctrl-c or ctrl-z
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:09:13 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Thu, 17 Feb 2011 21:09:13 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1297976953.26.0.247983730565.issue11236@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

To allow people to cancel at the password prompt, we added a manual post-check. Although this check runs after return is pressed, it's better than nothing.

Index: branches/rewrite/pywikibot/userinterfaces/terminal_interface.py
===================================================================
--- branches/rewrite/pywikibot/userinterfaces/terminal_interface.py	(revision 8977)
+++ branches/rewrite/pywikibot/userinterfaces/terminal_interface.py	(revision 8978)
@@ -175,6 +175,11 @@
             if password:
                 import getpass
                 text = getpass.getpass('')
+                # See PYWP-13 / http://bugs.python.org/issue11236
+                # getpass does not always raise an KeyboardInterrupt when ^C
+                # is pressed.
+                if '\x03' in text:
+                    raise KeyboardInterrupt()
             else:
                 text = raw_input()
         finally:

http://www.mediawiki.org/wiki/Special:Code/pywikipedia/8978

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:25:59 2011
From: report at bugs.python.org (Maurice Maneschi)
Date: Thu, 17 Feb 2011 21:25:59 +0000
Subject: [issue11237] odbc module crashes Python interpretter
In-Reply-To: <1297977959.44.0.182816269103.issue11237@psf.upfronthosting.co.za>
Message-ID: <1297977959.44.0.182816269103.issue11237@psf.upfronthosting.co.za>


New submission from Maurice Maneschi <mamaneschi at gmail.com>:

In Python 3.1.3 under Windows XP sp3, I enter the following under the interpretter:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\MauriceM>c:\Python31\python.exe
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import odbc
>>> c = odbc.odbc('Quantum/Quantum/Quantum3')
>>> dir(c)

C:\Documents and Settings\MauriceM>

At that point, Windows pops up a crash notification and asked if MS should be informed.

Questions
=========
1) Is ODBC no longer supported?

----------
components: Windows
messages: 128756
nosy: Maurice.Maneschi
priority: normal
severity: normal
status: open
title: odbc module crashes Python interpretter
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11237>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:27:35 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 21:27:35 +0000
Subject: [issue11238] sets - refer to sets/frozenset in stdtypes
In-Reply-To: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>
Message-ID: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hi, following up http://mail.python.org/pipermail/docs/2011-February/003088.html, here's a patch to make sets.html big red notice :) refer to set/frozenset into stdtypes page with a couple of links.

----------
assignee: sandro.tosi
components: Documentation
files: sets_refers_to_stdtypes-rel2.7.patch
keywords: patch
messages: 128757
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: sets - refer to sets/frozenset in stdtypes
versions: Python 2.7
Added file: http://bugs.python.org/file20780/sets_refers_to_stdtypes-rel2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11238>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:38:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 21:38:26 +0000
Subject: [issue11235] Source files with date modifed in 2106 cause
	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297978706.31.0.865475762639.issue11235@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The problem occurs on import (import bla reads bla.py), when Python tries to create bla.pyc. The problem is that Python stores the timestamp as 4 bytes in .pyc files, whereas time_t is 64 bits on Windows (at least on Windows XP with Visual Studio).

To support bigger timestamps, we have to change the file format of .pyc files. It cannot be done in Python 2.7, I propose to do it in Python 3.3

See also #5537 and #4379: other issues with 64 bits => 32 bits timestamps.

----------
nosy: +belopolsky, haypo
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11235>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:41:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Feb 2011 21:41:38 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1297978898.0.0.129379914393.issue11222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me. I guess it needs Georg's approval, though.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Thu Feb 17 22:55:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Feb 2011 21:55:43 +0000
Subject: [issue11238] sets - refer to sets/frozenset in stdtypes
In-Reply-To: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>
Message-ID: <1297979743.7.0.907487800697.issue11238@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11238>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:00:04 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 22:00:04 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1297980004.13.0.698694552397.issue11232@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

well, since we are at it, sed 's/abasic/a basic/' in the first line of echo server example; I'm too lazy to regenerate the patch tho :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:08:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 22:08:52 +0000
Subject: [issue11235] Source files with date modifed in 2106 cause
	OverflowError
In-Reply-To: <1297974058.91.0.622548974342.issue11235@psf.upfronthosting.co.za>
Message-ID: <1297980532.49.0.0691746281849.issue11235@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> To support bigger timestamps, we have to change the file format 
> of .pyc files.

write_compiled_module(), check_compiled_module() and other functions use the marshal module to read/write binary file, but marshal has no function for int64_t, only for long (which may be 32 bits, especially on Windows).

I don't know if Python has a builtin 64 bits integer type. There is PY_LONG_LONG, but this type is optional. A possible solution is to always store timestamp as 64 bits signed integer, but reject timestamp > 2^32 (as currently) if we don't have 64 bits integer type (like PY_LONG_LONG). Something like:

#ifdef PY_LONG_LONG
   write_timestamp64(t);
#else
   if (t << 32) { error; }
   write_timestamp32(t);
   write_long32(0); /* emulate 64 bits in big endian */
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11235>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:13:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 22:13:02 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1297980782.29.0.16186193259.issue4379@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, this issue was already fixed by r87666 to fix the duplicate issue #8278.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:13:57 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 22:13:57 +0000
Subject: [issue4379] Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing
In-Reply-To: <1227288006.53.0.353699707167.issue4379@psf.upfronthosting.co.za>
Message-ID: <1297980837.28.0.0658852019579.issue4379@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Oh, this issue was already fixed by r87666

... in py3k, and then merged into release31-maint (r87668) and release27-maint (r87669).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4379>
_______________________________________

From orsenthil at gmail.com  Thu Feb 17 23:19:52 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 18 Feb 2011 06:19:52 +0800
Subject: [issue11071] What's New review comments
In-Reply-To: <1297966682.97.0.54838214121.issue11071@psf.upfronthosting.co.za>
References: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
	<1297966682.97.0.54838214121.issue11071@psf.upfronthosting.co.za>
Message-ID: <AANLkTik=39sv2wKpwf3309Y9ZSTYCcNHLcXB+s19boG8@mail.gmail.com>

On Fri, Feb 18, 2011 at 2:18 AM, ?ric Araujo <report at bugs.python.org> wrote:

> You must have missed line 752 and following of Lib/functools.py. ?Brian did add context management support to Popen in response to my request in #10554.

Yes, I did miss it because the What's new document referenced only
issue 7461 and I saw that checkin had changes for os.popen only.
Thanks for pointing this out. I think #10554 should be referenced
where the claim for subprocess.Popen Context Manager support is
mentioned.
Other comments have been care of.

-- 
Senthil

From report at bugs.python.org  Thu Feb 17 23:20:14 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Feb 2011 22:20:14 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1297966682.97.0.54838214121.issue11071@psf.upfronthosting.co.za>
Message-ID: <AANLkTik=39sv2wKpwf3309Y9ZSTYCcNHLcXB+s19boG8@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Feb 18, 2011 at 2:18 AM, ?ric Araujo <report at bugs.python.org> wrote:

> You must have missed line 752 and following of Lib/functools.py. ?Brian did add context management support to Popen in response to my request in #10554.

Yes, I did miss it because the What's new document referenced only
issue 7461 and I saw that checkin had changes for os.popen only.
Thanks for pointing this out. I think #10554 should be referenced
where the claim for subprocess.Popen Context Manager support is
mentioned.
Other comments have been care of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:26:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Feb 2011 22:26:47 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1297981607.99.0.00126515491545.issue5537@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Shouldn't module time be changed to use a cross-platform implementation
> that uses a 64 bit time_t-like type? Apparently Perl 6 has made the
> equivalent change.

The error occurs on time.gmtime(t): even if we use 64 bits time_t type, we have to downcast it to system time_t later, because we would like to call gmtime() function at the end.

To workaround gmtime() limitation: we can simply use datetime instead. Attached patch replaces gmtime() by datetime.utcfromtimestamp(), and use its .strftime() method which has no such limitation.

----------
nosy: +belopolsky, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:35:07 2011
From: report at bugs.python.org (Ron Adam)
Date: Thu, 17 Feb 2011 22:35:07 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1297982107.6.0.624212747913.issue2571@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Thu Feb 17 23:49:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 17 Feb 2011 22:49:13 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1297982953.23.0.561093724174.issue11236@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From chris.parker1 at ml.com  Thu Feb 17 17:53:39 2011
From: chris.parker1 at ml.com (Parker, Chris)
Date: Thu, 17 Feb 2011 11:53:39 -0500
Subject: Initialization scope bug?
Message-ID: <E67BA688A48EF742A338539384EAD28E0969A3FB@MLNYC20MB053.amrs.win.ml.com>

The following code does not work for some reason in Python 2.6.5
(r265:79063, Jun  9 2010, 16:26:11) [MSC v.1500 32 bit (Intel)] on win32

Apparently, the class's function definition is accepted just fine by
Python, however when the function is called during the initialization
that follows, the function cannot see the class attribute defined before
it and an error is returned!

class MyClass:
    START=10
    def getStart(): return START
    x = START # OK
    y = getStart () # Error!


The error I get is:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in MyClass
  File "<stdin>", line 3, in getStart
NameError: global name 'START' is not defined


Is this a bug?

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

From report at bugs.python.org  Fri Feb 18 00:07:34 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Feb 2011 23:07:34 +0000
Subject: [issue11237] odbc module crashes Python interpretter
In-Reply-To: <1297977959.44.0.182816269103.issue11237@psf.upfronthosting.co.za>
Message-ID: <1297984054.59.0.842284775922.issue11237@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

odbc is not a module provided by Python.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11237>
_______________________________________

From report at bugs.python.org  Fri Feb 18 00:08:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 17 Feb 2011 23:08:31 +0000
Subject: [issue11239] regexp-howto - add missing } to metachars
In-Reply-To: <1297984111.53.0.588454087377.issue11239@psf.upfronthosting.co.za>
Message-ID: <1297984111.53.0.588454087377.issue11239@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

hi, following up http://mail.python.org/pipermail/docs/2011-February/003099.html, here's a patch to add '}' to metachars, currently missing.

----------
assignee: sandro.tosi
components: Documentation
files: regex-howto-add-missin-metachar-py3k.patch
keywords: patch
messages: 128767
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: regexp-howto - add missing } to metachars
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20781/regex-howto-add-missin-metachar-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11239>
_______________________________________

From report at bugs.python.org  Fri Feb 18 00:57:00 2011
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 17 Feb 2011 23:57:00 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>


New submission from Matt Chaput <matt at whoosh.ca>:

If you start unit tests with a command line such as "python setup.py test" or "nosetests", if the tested code starts a multiprocessing.Process on Windows, each new process will act as if it was started as "python setup.py test"/"nosetests", leading to an infinite explosion of processes that eventually locks up the entire machine.

----------
components: Windows
messages: 128768
nosy: mattchaput
priority: normal
severity: normal
status: open
title: Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 00:59:27 2011
From: report at bugs.python.org (Steve Thompson)
Date: Thu, 17 Feb 2011 23:59:27 +0000
Subject: [issue11241] ctypes: subclassing an already subclassed ArrayType
	generates AttributeError
In-Reply-To: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>
Message-ID: <1297987167.42.0.900007110424.issue11241@psf.upfronthosting.co.za>


New submission from Steve Thompson <steve.f.thompson at gmail.com>:

Consider the following:
python code:
class my_array( ctypes.Array ):
    _type_    = ctypes.c_uint8
    _length_  = 256

class my_array2( my_array ):
    pass

Output:
class my_array2( my_array ):
AttributeError: class must define a '_length_' attribute, which must be a positive integer


This is analogous to the C code
typedef char my_array[ 256 ];
typedef my_array my_array2;

However, the python code raises exceptions claiming _type_ and _length_ have not been defined.  This seems like a bug.  I shouldn't need to redefine _type_ and _length_, otherwise there was no point in subclassing my_array.

I tried to step into this using pdb but didn't have any luck.

----------
assignee: theller
components: ctypes
messages: 128769
nosy: Steve.Thompson, theller
priority: normal
severity: normal
status: open
title: ctypes: subclassing an already subclassed ArrayType generates AttributeError
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11241>
_______________________________________

From report at bugs.python.org  Fri Feb 18 01:28:51 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Feb 2011 00:28:51 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1297988931.44.0.34189517798.issue11240@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Using multiprocessing on Windows can be different; please read http://docs.python.org/library/multiprocessing.html#windows especially the part named "Safe importing of main module".

On Windows, fork() does not exist, so a new interpreter must be started, which will import the current module; this must not start the test suite again!
Adding "if __name__ == '__main__'" somewhere is probably the solution.
If not, you should move the target function to another module.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 01:34:05 2011
From: report at bugs.python.org (Matt Chaput)
Date: Fri, 18 Feb 2011 00:34:05 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1297989245.97.0.102854483995.issue11240@psf.upfronthosting.co.za>


Matt Chaput <matt at whoosh.ca> added the comment:

Thank you, I understand all that, but I don't think you understand the issue. My code is not __main__. I am not starting the test suite. It's the distutils/nose code that's doing that.

It seems as if the multiprocessing module is starting new Windows processes by duplicating the command line of the original process. That doesn't seem to work very well, given the example of running test suites, hence the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 01:51:56 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Feb 2011 00:51:56 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1297990316.17.0.685588693563.issue11240@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> It seems as if the multiprocessing module is starting new Windows
> processes by duplicating the command line of the original process.
It does not. The spawned processes use the command::

  python.exe -c 'from multiprocessing.forking import main; main()' --multiprocessing-fork [handle#]

And only after, the multiprocessing machinery overrides sys.argv with the same value as the initial process.
There is certainly some code in one of your modules that starts running the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:01:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Feb 2011 02:01:58 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1297994518.73.0.432990355711.issue11236@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:25:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Feb 2011 02:25:52 +0000
Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin
	be improved?
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1297995952.26.0.60785561165.issue2571@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: cmd.py always uses raw_input, even when another stdin is specified -> can cmd.py's API/docs for the use of an alternate stdin be improved?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:26:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Feb 2011 02:26:01 +0000
Subject: [issue2571] can cmd.py's API/docs for the use of an alternate stdin
	be improved?
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1297995961.66.0.918399029146.issue2571@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Fri Feb 18 03:56:26 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 18 Feb 2011 02:56:26 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1297997786.5.0.84025129549.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> Do you mean combine step 3 and step 4 together? Currently step 3 is just to compute the biggest width value and step 4 is to compute exact width and do the real format work. Only by doing real format we can get the exact width of a string. So I have to compute each width twice in both step 3 and step 4. Is combining the two steps in to one a good idea?

Sorry, Here I mean:

Do you mean combine step 3 and step 4 together? Currently step 3 is just to compute the biggest width value and step 4 is to compute exact width and do the convert work(by calling PyObject_Str()/PyObject_Repr()/PyObject_ASCII()/PyUnicode_DecodeUTF8() for %S/%R/%A/%s). Only by doing convert we can get the exact width of a string. So I have to compute each width twice in both step 3 and step 4. Is combining the two steps in to one a good idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 18 05:45:49 2011
From: report at bugs.python.org (John)
Date: Fri, 18 Feb 2011 04:45:49 +0000
Subject: [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1298004349.6.0.0419339272787.issue11230@psf.upfronthosting.co.za>


John <jh45dev at gmail.com> added the comment:

Victor asked "Which web page should updated/fixed?"

Answer: The Python 3.2 download page.

But what should it say?

The main point is that people like me, who remember seeing a statement about this a few months ago, may expect unicode to work in every conceivable situation, and a prominent warning that it's not *all* fixed yet, with a link to details in the documentation, would save them from trying things that don't work.

By the way, I hadn't grasped a simple point from issue 3080: I tested on *English* Windows by putting a Greek character in the path to some python modules. But the usual situation is where a *Greek* version of Windows has some Greek characters in the path, and from what you just wrote, that's OK now.

-- jh

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11230>
_______________________________________

From report at bugs.python.org  Fri Feb 18 07:06:44 2011
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 18 Feb 2011 06:06:44 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1298009204.0.0.334096212116.issue7833@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I'm failing to get a new pywin32 out of the door due to this issue.  I've spent a few hours playing with this and I think the analysis is generally correct here.  The key thing is that when using distutils, the extensions end up with a manifest (albeit one without a reference to the CRT) whereas the extensions shipped with Python have no manifest at all.

I agree with Martin that it seems strange the CRT fails to be used even though the CRT is obviously already loaded, but it seems to be a fact.  I can't find much on this, but suspect it relates to the different "activation contexts" in use and how the activation contexts are designed to allow side-by-side loading of DLLs; Windows doesn't know if the version of the DLL already loaded is suitable.  I also guess that the fact the DLL has *any* manifest means they use a more strict interpretation of things (ie, refuse to use already loaded ones) whereas a dll with no manifest gets given a little more slack.

I can confirm that with the attached patch, pywin32 builds and installs fine on a machine without the CRT installed globally - so I'm +1 on this patch with one caveat:  The check for '.pyd' should either be expanded to include '.dll', or else the check should just use the 'target_desc == CCompiler.EXECUTABLE' condition already used.

I'm happy to make the change once I get some feedback and/or guidance about where I should check this in - I believe it is too late for python 2.6 which is a shame...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Fri Feb 18 08:36:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 07:36:12 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1297951632.53.0.32370830023.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298014565.16462.7.camel@marge>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > It looks like your patch fixes #10829: you should add tests for that, you can just reuse the tests of my patch (attached to #10829).
> 
> Sorry, but I think my patch doesn't fix #10829.

Ah ok, so don't add failing tests :-)

> > You should also avoid the creation of a temporary unicode object (it can be slow if precision is large) using PySequence_GetSlice(). Py_UNICODE_COPY() does already truncate the string because you can pass an arbitrary length.
> 
> In order to use Py_UNICODE_COPY, I have to create a unicode object with required length first.

No you don't. You can copy a substring of the input string with
Py_UNICODE_COPY: just pass a smaller length.

> > With your patch, "%.200s" truncates the input string to 200 *characters*, but I think that it should truncate to 200 *bytes*, as printf does.
> 
> Sorry, I don't understand. The result of PyUnicode_FromFormatV() is a unicode object. Then how to truncate to 200 *bytes*?

You can truncate the input char* on the call to PyUnicode_DecodeUTF8:
pass a size smaller than strlen(s).

case 's':
{
    /* UTF-8 */
    const char *s = va_arg(count, const char*);
    PyObject *str = PyUnicode_DecodeUTF8(s, strlen(s), "replace");
    if (!str)
        goto fail;
    n += PyUnicode_GET_SIZE(str);
    /* Remember the str and switch to the next slot */
    *callresult++ = str;
    break;
}

I don't know if we should truncate to a number of bytes, or a number of
characters.

> > I don't like this change because I hate having to compute manually strings length. It should that it would be easier if you format directly strings with width and precision at step 3, instead of doing it at step 4: so you can just read the length of the formatted string, and it avoids having to handle width/precision in two steps (which may be inconsistent :-/).
> 
> Do you mean combine step 3 and step 4 together? Currently step 3 is just to compute the biggest width value and step 4 is to compute exact width and do the real format work. Only by doing real format we can get the exact width of a string. So I have to compute each width twice in both step 3 and step 4. Is combining the two steps in to one a good idea?

"Do you mean combine step 3 and step 4 together?"

Yes, but I am no more sure that it is the right thing to do.

> > Can you add tests for "%.s"? I would like to know if "%.s" is different than "%s" :-)
> 
> Err, '%.s' causes unexpected result both with and without my patch. Maybe it's still another bug?

If the fix (always have the same behaviour) is short, it would be nice
to include it in your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 18 10:59:21 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 18 Feb 2011 09:59:21 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1298023161.92.0.201809784755.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Here is a new version of the file:
It integrates the corrections by R. David, and I also modified the "memory limitations" section in order to use ldedit rather than some flags for the linker.

----------
Added file: http://bugs.python.org/file20782/AIX-NOTES

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Fri Feb 18 11:05:20 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Fri, 18 Feb 2011 10:05:20 +0000
Subject: [issue11212] Python memory limit on AIX
In-Reply-To: <1297697475.44.0.286339686291.issue11212@psf.upfronthosting.co.za>
Message-ID: <1298023520.41.0.0622045474284.issue11212@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I updated the documentation in issue 10709 so that it mentions ldedit rather than the linker flags (more convenient to activate support for more memory).

Once Python 3.2 is released, we may add LDR_CNTRL or ldedit in the Makefile when running buildbottest.

I will ask IBM if there is any reason not to activate support for 2GB in an application by default (impact on performances or something).
If there is none, we may systematically call "ldedit -b maxdata:0x80000000 ${srcdir}/python" when compiling python on AIX...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11212>
_______________________________________

From report at bugs.python.org  Fri Feb 18 12:41:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 11:41:58 +0000
Subject: [issue11242] urllib.request.url_open() doesn't support SSLContext
In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>
Message-ID: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Issue?#9003 added cafile and capath arguments to url_open(), but it is not possible to reuse a SSLContext object (which would avoid to reload certificates, CRL, etc.).

----------
components: Library (Lib)
messages: 128779
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: urllib.request.url_open() doesn't support SSLContext
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11242>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:13:28 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 18 Feb 2011 13:13:28 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1298034808.51.0.727585311173.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

An updated patch, based on latest several reviews on http://codereview.appspot.com/4185044/

update:
1, Refactoring the common tests between test_dbm_gnu and test_dbm_ndbm.
2, Move the abc registering in Lib/dbm/ndbm.py and Lib/dbm/gnu.py.
3, Other changes pointed out in review comments.

----------
Added file: http://bugs.python.org/file20783/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:13:39 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 18 Feb 2011 13:13:39 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1298034819.14.0.505561412433.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20771/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Fri Feb 18 14:31:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 13:31:45 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1298035905.95.0.868417140149.issue5537@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, my patch is incomplete: time2netscape() has the same issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:28:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 18 Feb 2011 14:28:52 +0000
Subject: [issue11242] urllib.request.url_open() doesn't support SSLContext
In-Reply-To: <1298029318.21.0.486512384779.issue11242@psf.upfronthosting.co.za>
Message-ID: <1298039332.56.0.153698109995.issue11242@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11242>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:53:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 18 Feb 2011 14:53:20 +0000
Subject: [issue11243] email/message.py str conversion [patch]
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Hy David, while hacking a bit on my thing i've found two places where header.Header needs to be explicitely converted via str().
Have a nice weekend.

----------
files: email_message.patch
keywords: patch
messages: 128782
nosy: r.david.murray, sdaoden
priority: normal
severity: normal
status: open
title: email/message.py str conversion [patch]
Added file: http://bugs.python.org/file20784/email_message.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:54:23 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 18 Feb 2011 14:54:23 +0000
Subject: [issue11243] email/message.py str conversion [patch]
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298040863.81.0.172056193041.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Will get that tracker right as time goes by.)

----------
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Fri Feb 18 15:58:58 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Feb 2011 14:58:58 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298041138.76.0.20917637782.issue11243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  I probably won't have time to look at this for a bit.

----------
assignee:  -> r.david.murray
stage:  -> patch review
title: email/message.py str conversion [patch] -> email/message.py str conversion
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:02:37 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 18 Feb 2011 15:02:37 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298041357.84.0.352337402226.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> No you don't. You can copy a substring of the input string with
Py_UNICODE_COPY: just pass a smaller length.

Oh, yes, I got your meaning now. I'll follow this.


> You can truncate the input char* on the call to PyUnicode_DecodeUTF8:

Oh, what if the trunked char* cannot be decoded correctly? e.g. a tow-bytes character is divided in the middle? 


> Yes, but I am no more sure that it is the right thing to do.

If I understand correctly(my English ability is limited), your suggestion is to combine, right? I'm afraid that combine may bring us too complicated code to write. The currently 4 steps just divide the process into smaller and simpler pieces. I'm not sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:05:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 15:05:33 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298041533.87.0.990211455284.issue7330@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Oh, what if the trunked char* cannot be decoded correctly?
> e.g. a tow-bytes character is divided in the middle? 

Yes, but PyUnicode_FromFormatV() uses UTF-8 decoder with replace error handler, and so the incomplete byte sequence will be replaced by ? (it doesn't fail with an error). Example:

>>> "abc?".encode("utf-8")[:-1].decode("utf-8", "replace")
'abc?'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:13:37 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 18 Feb 2011 15:13:37 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298042017.17.0.938185991615.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

We all know EMail 6.0 will blow them off the streets in the end.

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:29:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Feb 2011 15:29:59 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1298042999.08.0.772548760608.issue5537@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Victor,

I don't see your patch.  Did you remove it?

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:31:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 15:31:02 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1298043062.25.0.42838649885.issue5537@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

No, I forgot to upload it...

----------
keywords: +patch
Added file: http://bugs.python.org/file20785/cookiejar_datetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:38:53 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 18 Feb 2011 15:38:53 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298043533.94.0.788213366537.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> Can you add tests for "%.s"? I would like to know if "%.s" is different than "%s" :-)

Oh sorry~~  I made an mistake. There is no bug here. I have attached tests that show that '%.s' is the same as '%s'.


Here is the updated patch:
1, changed the function name unicode_format() to 
1, remove
"""
-                                 "must be a sequence, not %200s",
+                                 "must be a sequence, not %.200s",
"""
in Python/ceval.c

2, Removing using PySequence_GetSlice() in unicode_format_align() and do a refactor to optimize the process.

3, Add tests for '%.s' and '%s', as haypo wanted.


This is obviously not the final patch just convenient for other to do a  review. Something more need to be discussed.

----------
Added file: http://bugs.python.org/file20786/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Fri Feb 18 16:43:53 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Feb 2011 15:43:53 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1298043062.25.0.42838649885.issue5537@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=u4eNYpH+SxFwLC10h6g6UJhrcfJL00n4km=Vm@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While it is unlikely that a purely numeric format such as "%Y-%m-%d
%H:%M:%S" will be locale dependent, it is possible that some pre-C99
systems would format dates using exotic digits is some locales.  Given
that format is so simple, I would just use explicit formatting of dt
components instead of datetime.strftime.  Doing so will also eliminate
a call to system strftime which is known to be quirky on popular
platforms even in C locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:04:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 16:04:30 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1298045070.48.0.123794167538.issue5537@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

If datetime.strftime() is not reliable, we should maybe fix it instead of using a workaround?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:12:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 18 Feb 2011 16:12:30 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
	2038 or greater on 32-bit platforms
In-Reply-To: <1298045070.48.0.123794167538.issue5537@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=MwWTiiHGGQL2xkN7tSDMSn64r+4XUzpA5-8+U@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Feb 18, 2011 at 11:04 AM, STINNER Victor <report at bugs.python.org> wrote:
..
> If datetime.strftime() is not reliable, we should maybe fix it instead of using a workaround?

The real fix would be to rewrite strftime so that it does not call
system strftime.  See issue3173.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Fri Feb 18 17:49:31 2011
From: report at bugs.python.org (Matt Chaput)
Date: Fri, 18 Feb 2011 16:49:31 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1298047771.27.0.397318087415.issue11240@psf.upfronthosting.co.za>


Matt Chaput <matt at whoosh.ca> added the comment:

I don't know what to tell you... to the best of my knowledge there's absolutely no way for my code to kick off the entire test suite -- I always do that through PyDev (which doesn't cause the bug, by the way). The closest thing is the boilerplate at the bottom of every test file:

if __name__ == "__main__":
    unittest.main()

...but even that would only start the tests in that file, not the entire suite.

Another thing that makes me think multiprocessing is re-running the original command line is that if I use "python setup.py test" to start the tests, when it gets to the MP tests it seems to run that command for each Process that gets started, but if I use "nosetests", it seems to run "nosetests" for each started Process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:41:05 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Fri, 18 Feb 2011 17:41:05 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>


New submission from Jeffrey Harper <jharper at yapdc.com>:

In Python 3.2, a tuple like (1,-2,3) will not be optimized into a constants at compile time.  The tuple is built at run-time.  Earlier versions of Python optimized these tuples at compile time.

Here's an example program.

# test.py
from dis import dis

def x(): return (1,2,3)
def y(): return (1,-2,3)

print ("dis x:")
dis(x)
print()

print("dis y:")
dis(y)

The compiler in 3.2rc3 produces code for function y() that builds the tuple at run-time while the tuple in x() is optimized at compile time.

C:\tmp>c:\python32\python --version
Python 3.2rc3

C:\tmp>c:\python32\python test.py
dis x:
  3           0 LOAD_CONST               4 ((1, 2, 3))
              3 RETURN_VALUE

dis y:
  4           0 LOAD_CONST               1 (1)
              3 LOAD_CONST               4 (-2)
              6 LOAD_CONST               3 (3)
              9 BUILD_TUPLE              3
             12 RETURN_VALUE

However, under 3.1.3, the tuples in both functions are optimized at compile time.

C:\tmp>c:\python31\python test.py
dis x:
  3           0 LOAD_CONST               4 ((1, 2, 3))
              3 RETURN_VALUE

dis y:
  4           0 LOAD_CONST               4 ((1, -2, 3))
              3 RETURN_VALUE

Although the compiled code produced 3.2rc3 is correct, it is much slower than the code generated by 3.1.3.

----------
messages: 128795
nosy: jdharper
priority: normal
severity: normal
status: open
title: Negative tuple elements produce inefficient code.
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:49:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 17:49:09 +0000
Subject: [issue11238] sets - refer to sets/frozenset in stdtypes
In-Reply-To: <1297978055.74.0.115599030243.issue11238@psf.upfronthosting.co.za>
Message-ID: <1298051349.63.0.270169062791.issue11238@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good catch, done in r88436.   Thanks Sandro and Davide, if you?re subscribed to the docs at python mailing-list and can read this.

----------
assignee: sandro.tosi -> eric.araujo
nosy: +docs at python, eric.araujo
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11238>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:51:15 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Feb 2011 17:51:15 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1298051475.32.0.970619369745.issue11240@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Nose works correctly for me with multiprocessing. In a directory, I have:

== run_nose.py =================
from nose import main
if __name__ == '__main__':
    main()
================================

== test_me.py ==================
from multiprocessing import Pool
import os, time

def foo(x):
    time.sleep(0.1)
    return (x, os.getpid())

def test_me():
    pool = Pool(processes=4)
    x = pool.map(foo, range(10))
    a, b = zip(*x)
    print a, b
    assert list(a) == range(10)
    assert 1 < len(set(b)) <= 4
================================

Now when I do: "c:\python27\python run_nose.py" the test runs correctly.

Can you try this test in your environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:56:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 17:56:52 +0000
Subject: [issue7284] argparse - display version in usage by default
In-Reply-To: <1257641781.98.0.415542584092.issue7284@psf.upfronthosting.co.za>
Message-ID: <1298051812.45.0.077823335889.issue7284@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard -aronacher
resolution: wont fix -> 
stage: committed/rejected -> 
title: optparse - display version in usage by default -> argparse - display version in usage by default

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7284>
_______________________________________

From report at bugs.python.org  Fri Feb 18 18:58:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 17:58:51 +0000
Subject: [issue11203] gzip doc is behind
In-Reply-To: <1297539632.81.0.320134391105.issue11203@psf.upfronthosting.co.za>
Message-ID: <1298051931.66.0.943600917224.issue11203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Would you like to propose a patch?

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11203>
_______________________________________

From report at bugs.python.org  Fri Feb 18 19:55:55 2011
From: report at bugs.python.org (Matt Chaput)
Date: Fri, 18 Feb 2011 18:55:55 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1298055355.24.0.477600776494.issue11240@psf.upfronthosting.co.za>


Matt Chaput <matt at whoosh.ca> added the comment:

If I do "c:\python27\python run_nose.py" it works correctly. If I do "nosetests" I get the process explosion. Maybe the bug is in how distutils and nose work from the command line? I'm confused.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:01:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 19:01:06 +0000
Subject: [issue10887] Add link to development ML
In-Reply-To: <1294745681.16.0.799239354624.issue10887@psf.upfronthosting.co.za>
Message-ID: <1298055666.05.0.0391919899125.issue10887@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10887>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:05:20 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Fri, 18 Feb 2011 19:05:20 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298055920.33.0.647090399072.issue11244@psf.upfronthosting.co.za>


Jeffrey Harper <jharper at yapdc.com> added the comment:

I have also determined that negative elements interfere with the frozenset optimization described in issue6690.  http://bugs.python.org/issue6690.

Here's an example program:

# test.py
from dis import dis

def x(var): return var in {1,2,3} # Note curly braces.  These are sets.
def y(var): return var in {1,-2,3}

print ("dis x:")
dis(x)
print()

print("dis y:")
dis(y)

Running this produces:

C:\tmp>c:\Python32\python.exe test.py
dis x:
  3           0 LOAD_FAST                0 (var)
              3 LOAD_CONST               4 (frozenset({1, 2, 3}))
              6 COMPARE_OP               6 (in)
              9 RETURN_VALUE

dis y:
  4           0 LOAD_FAST                0 (var)
              3 LOAD_CONST               1 (1)
              6 LOAD_CONST               4 (-2)
              9 LOAD_CONST               3 (3)
             12 BUILD_SET                3
             15 COMPARE_OP               6 (in)
             18 RETURN_VALUE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:06:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 19:06:00 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298055960.43.0.893729291472.issue11060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think Version should be strict, then Metadata could have an option for strictness (defaulting to true), so that mkcfg, sdist and other would strict mode but users could get more flexibility when needed.

----------
nosy: +swamiyeswanth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:14:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 19:14:22 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298056462.26.0.111283285739.issue11244@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:17:22 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Feb 2011 19:17:22 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1298056642.69.0.975612905649.issue11240@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Ah, is 'nosetests' a .exe file? A frozen executable?
In this case, can you try the solution proposed at http://docs.python.org/library/multiprocessing.html#multiprocessing.freeze_support

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:19:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 19:19:14 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
	reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1298056754.26.0.774056203064.issue11205@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:23:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 19:23:32 +0000
Subject: [issue11240] Running unit tests in a command line tool leads to
	infinite loop with multiprocessing on Windows
In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za>
Message-ID: <1298057012.29.0.919224634547.issue11240@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If I do "c:\python27\python run_nose.py" it works correctly. If I do
> "nosetests" I get the process explosion. Maybe the bug is in how
> distutils and nose work from the command line? I'm confused.

The bug is in nose itself. You should report a bug there.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11240>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:25:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Feb 2011 19:25:06 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298057106.26.0.537585469596.issue11244@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I wonder if this has anything to do with issue 9011?

----------
nosy: +mark.dickinson, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:34:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 19:34:22 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298057662.31.0.0347955707054.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The culprit is r82043: "Issue #9011: Remove buggy and unnecessary ST->AST compilation code".

----------
assignee:  -> mark.dickinson
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:35:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 19:35:25 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1298057725.05.0.120012061675.issue11231@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:39:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 19:39:24 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298057964.93.0.198385933958.issue11236@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Would you like to contribute a patch?  If so, guidelines are found at http://docs.python.org/devguide/

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:55:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2011 19:55:44 +0000
Subject: [issue11204] re module: strange behaviour of space inside {m, n}
In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>
Message-ID: <1298058944.35.0.67935428952.issue11204@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11204>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:58:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 18 Feb 2011 19:58:08 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298059088.33.0.398953301149.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.S.: maybe this completes the byte.
Have a nice weekend nevertheless - if you can.

  Traceback (most recent call last):
    File "/Users/steffen/usr/bin/s-postman.py", line 1419, in _walk
      self._tickets.extend(Ticket.process_message(msg))
    File "/Users/steffen/usr/bin/s-postman.py", line 1275, in process_message
      splitter = splitter(msg)
    File "/Users/steffen/usr/bin/s-postman.py", line 401, in _openbsd_text
      charset = msg.get_content_charset('iso-8859-1')
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 820, in get_content_charset
      charset = self.get_param('charset', missing)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 628, in get_param
      for k, v in self._get_params_preserve(failobj, header):
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 565, in _get_params_preserve
      for p in _parseparam(';' + value):
  Exception: TypeError: Can't convert 'Header' object to str implicitly


  Traceback (most recent call last):
    File "/Users/steffen/usr/bin/s-postman.py", line 1419, in _walk
      self._tickets.extend(Ticket.process_message(msg))
    File "/Users/steffen/usr/bin/s-postman.py", line 1275, in process_message
      splitter = splitter(msg)
    File "/Users/steffen/usr/bin/s-postman.py", line 402, in _openbsd_text
      lines = msg.get_payload().splitlines()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 244, in get_payload
      cte = self.get('content-transfer-encoding', '').lower()
  Exception: AttributeError: 'Header' object has no attribute 'lower'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Fri Feb 18 20:58:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 19:58:31 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298059111.42.0.748317659699.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The problem is that the "UNARY_NEGATIVE + LOAD_CONST" optimization, which occurs first in bytecode order, inserts a NOP and prevents the tuple optimization to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:00:24 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Fri, 18 Feb 2011 20:00:24 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298059224.93.0.747271840968.issue11244@psf.upfronthosting.co.za>


Jeffrey Harper <jharper at yapdc.com> added the comment:

I think r82043 may also explain why 3.1.3 can fold the expression 2 * -3 into -6 while 3.2rc3 cannot.

# test.py
from dis import dis

def y(): 2 * -3

print("dis y:")
dis(y)



C:\tmp>c:\Python32\python.exe --version
Python 3.2rc3

C:\tmp>c:\Python32\python.exe test.py
dis y:
  3           0 LOAD_CONST               1 (2)
              3 LOAD_CONST               3 (-3)
              6 BINARY_MULTIPLY
              7 POP_TOP
              8 LOAD_CONST               0 (None)
             11 RETURN_VALUE

C:\tmp>c:\Python31\python.exe --version
Python 3.1.3

C:\tmp>c:\Python31\python.exe test.py
dis y:
  3           0 LOAD_CONST               3 (-6)
              3 POP_TOP
              4 LOAD_CONST               0 (None)
              7 RETURN_VALUE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:00:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Feb 2011 20:00:33 +0000
Subject: [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1298059233.24.0.62042808043.issue11231@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You sort of left out bytes() == bytes(0) == b''.
I did not know about case 5 -- not surprisingly ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11231>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:02:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 20:02:05 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298059325.21.0.940656570045.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ouch. Obviously test_peephole doesn't have enough tests...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:24:35 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Fri, 18 Feb 2011 20:24:35 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1298060675.95.0.40295674226.issue11216@psf.upfronthosting.co.za>


Shay Rojansky <roji at roji.org> added the comment:

Sorry for disappearing, will be following this closer from now on.

Thanks for the responses (and the acknowledgement of a problem), David and Steffen.

I understand the API design philosophy and the need to allow the production of invalid messages. The main problem point to me is what seems to be an inconsistency in the API:
* When constructing a new message/part (i.e. in the constructor), management of the Content-Transfer-Encoding header and responsibility for doing base64 is done by the API.
* But when using mutators (set_payload, set_charset), these become the responsibility of the caller, etc.

So one aspect of the API is high-level, another low-level. I have no idea whether this was a planned thing in some way, and have a hard time estimating whether modifying the behavior (i.e. making set_payload/set_charset high-level like the constructor) would break apps that depend on the current low-level behavior...

One thought though... Another part of the API already allows the user to indicate whether they want low or high level behavior: get_payload accepts the boolean decode flag. Would it not make sense to add a similar "encode" flag to set_payload? To be complete such a flag could also be added to the constructor.

Apart from that, I guess a good doc patch would run along the lines of appending the following to set_charset's description:
"Note that if a Content-Transfer-Encoding header is already present on the message, it is kept as is and no content transfer encoding is applied to the payload."



This can

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Fri Feb 18 21:36:11 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Fri, 18 Feb 2011 20:36:11 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>


New submission from Shay Rojansky <roji at roji.org>:

IMAP IDLE support is not implemented in the current imaplib. A "drop-in" replacement called imaplib2 exists (), but uses internally managed threads - a heavy solution that is not always appropriate (e.g. when handling many IMAP accounts an asynchronous approach would be more efficient)

I am about to start implementation of an asynchronous select()-compatible approach, and was wondering if there has been any discussion over IDLE, any specific reasons it hasn't been implemented and if eventual integration into imaplib would be a desirable thing.

Proposed approach:
* Addition of a new state 'IDLE'
* Addition of an idle() method to class IMAP4, which issues the IDLE command to the server and returns immediately. At this point we enter the IDLE state, in which no normal IMAP commands may be issued.
* Users can now select() or poll() the socket as they wish
* A method can be called to retrieve any untagged responses (e.g. EXISTS) that have arrived since entering the IDLE state. The function returns immediately and does not modify the state.
* To end the IDLE state, the user calls a method (done()?) which resumes the previous state.

Would appreciate any sort of feedback...

----------
components: Library (Lib)
messages: 128814
nosy: Shay.Rojansky
priority: normal
severity: normal
status: open
title: Implementation of IMAP IDLE in imaplib?
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11245>
_______________________________________

From report at bugs.python.org  Fri Feb 18 22:17:23 2011
From: report at bugs.python.org (dholth)
Date: Fri, 18 Feb 2011 21:17:23 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1298063843.2.0.816933382266.issue10740@psf.upfronthosting.co.za>


dholth <dholth at fastmail.fm> added the comment:

I want transactional DDL too. I was tremendously surprised that I could not duplicate the way sqlite3 behaves on the command line from witin pysqlite.

Instead of this patch, I would rather be able to instruct pysqlite to always begin a transaction for any kind of statement (I hear this is a requirement for DB-API compliance) and never perform an implicit commit for any reason. For example, someone on the google code project had a complaint that 'SAVEPOINT' (create a subtransaction) automatically commits because pysqlite doesn't know about it.

I tried to trick pysqlite into doing what I wanted by prepending /* update */ to every CREATE TABLE statement but it didn't seem to quite work. Instead, I would prefer a pysqlite that does not strcmp(statement) at all.

----------
nosy: +dholth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Fri Feb 18 22:19:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 21:19:09 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298063949.19.0.883889405534.issue11234@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> rhettinger
nosy: +georg.brandl
priority: normal -> release blocker
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:12:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 22:12:14 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

While testing a patch fixing issue #7330, I found a bug in PyUnicode_FromFormat() in the %V format: it decodes the byte string from ISO-8859-1, whereas I would expect that the string is decodes from UTF-8, as the "%s" format.

----------
messages: 128816
nosy: haypo, ysj.ray
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormat("%V") decodes the byte string from ISO-8859-1
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:12:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Feb 2011 22:12:30 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298067150.66.0.132953757815.issue11246@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:22:57 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Feb 2011 22:22:57 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298067777.27.0.929824083223.issue11244@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:25:24 2011
From: report at bugs.python.org (Jeffrey Harper)
Date: Fri, 18 Feb 2011 22:25:24 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298067924.89.0.289846776211.issue11244@psf.upfronthosting.co.za>


Jeffrey Harper <jharper at yapdc.com> added the comment:

Here's a patch against the version of test_peepholer.py in 3.2rc3.  It verifies that expressions like the following are optimized:

3*-4
(1,-2,3)
a in {1,-2,3)

----------
keywords: +patch
Added file: http://bugs.python.org/file20787/test_peepholer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:27:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Feb 2011 22:27:49 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298068069.69.0.24366747714.issue11234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll look at this later tonight.

Eric, no marking "accepted" for tracker items without a patch.  "Accepted" means that a patch has been reviewed and is okay to apply.

----------
priority: release blocker -> high
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:32:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 22:32:42 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298068362.31.0.787651144455.issue11234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In this case, I thought that the suggested addition of one dot in one place was equivalent to a patch, and maybe more useful (we don?t know if you have local edits in your file that would make the diff fuzzy).  Anyway, I?m attaching the same fix in a diff form, for your convenience.

----------
keywords: +patch
nosy: +eric.araujo
Added file: http://bugs.python.org/file20788/fix-11234.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:43:44 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 18 Feb 2011 22:43:44 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298069024.24.0.224086301061.issue11236@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Sorry, I'm not going to run my patch through the entire test suite, I've got better things to do with my time than setting up a working python-development-test-bench. Especially for a one-line-revert.

The result now is:

valhallasw at dorthonion:~/src/pythonpatch$ python -c "import getpass; print getpass.getpass().__repr__()"
Password: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "getpass.py", line 71, in unix_getpass
    passwd = _raw_input(prompt, stream, input=input)
  File "getpass.py", line 133, in _raw_input
    line = input.readline()
KeyboardInterrupt


As for a patch - see attachment. It reverts one change from r76000
http://svn.python.org/view/python/trunk/Lib/getpass.py?r1=74860&r2=76000&pathrev=76000 line 65

The ISIG flag is copied from getpass.c (http://www.koders.com/c/fid3C9D79A0C31256E7875CB8930CF8B9E49BDA8C12.aspx line 122). According to the r76000 commit message:

"This change also incorporates some additional getpass implementation
suggestions for security based on an analysis of getpass.c linked to from the issue."
'The issue' should probably be issue7208, but I cannot find any reference to getpass.c there.

----------
keywords: +patch
Added file: http://bugs.python.org/file20789/issue11236.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:49:19 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 22:49:19 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298069359.18.0.936148896727.issue11236@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Someone will write a test and we?ll check that it works correctly on all supported platforms.

----------
keywords: +needs review
nosy: +belopolsky, gregory.p.smith, pajs at fodder.org.uk, pitrou
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:50:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 22:50:22 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298069422.95.0.216554851233.issue11236@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, on which platforms did you notice the bug?  (python -m platform)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:52:31 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 18 Feb 2011 22:52:31 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298069551.95.0.171517214449.issue11236@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Linux-2.6.22.18-co-0.7.4-i686-with-Ubuntu-10.04-lucid (the 'on linux2' versions) and Solaris-2.10-i86pc-i386-32bit-ELF (the 'on sunos5').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Fri Feb 18 23:55:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 18 Feb 2011 22:55:10 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298069710.58.0.023928475326.issue11236@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch fixes the bug for 3.2 on my Debian (Linux-2.6.32-5-amd64-x86_64-with-debian-wheezy-sid).  getpass currently has no unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Sat Feb 19 00:09:25 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Feb 2011 23:09:25 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298070565.25.0.371901806068.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch that enables advanced (recursive) constant folding.
Example:

python -c "import dis; f=lambda x: x in {(3*-5)+(-1-6),(1,-2,3)*2,None};dis.dis(f)"

With 3.1:
  1           0 LOAD_FAST                0 (x) 
              3 LOAD_CONST               7 (-15) 
              6 LOAD_CONST               8 (-7) 
              9 BINARY_ADD           
             10 LOAD_CONST              10 ((1, -2, 3, 1, -2, 3)) 
             13 LOAD_CONST              11 (None) 
             16 BUILD_SET                3 
             19 COMPARE_OP               6 (in) 
             22 RETURN_VALUE         

With 3.2+patch:
  1           0 LOAD_FAST                0 (x) 
              3 LOAD_CONST              14 (frozenset({None, -22, (1, -2, 3, 1, -2, 3)})) 
              6 COMPARE_OP               6 (in) 
              9 RETURN_VALUE

----------
Added file: http://bugs.python.org/file20790/constfold.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Sat Feb 19 04:54:41 2011
From: report at bugs.python.org (Dan Mahn)
Date: Sat, 19 Feb 2011 03:54:41 +0000
Subject: [issue11166] No exit when daemon thread is running.
In-Reply-To: <1297309203.91.0.996465848565.issue11166@psf.upfronthosting.co.za>
Message-ID: <1298087681.6.0.089455288958.issue11166@psf.upfronthosting.co.za>


Dan Mahn <dan.mahn at digidescorp.com> added the comment:

Seems to be fixed in RC3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11166>
_______________________________________

From report at bugs.python.org  Sat Feb 19 04:54:55 2011
From: report at bugs.python.org (Dan Mahn)
Date: Sat, 19 Feb 2011 03:54:55 +0000
Subject: [issue11247] e
Message-ID: <1298087695.27.0.0995068900859.issue11247@psf.upfronthosting.co.za>


Changes by Dan Mahn <dan.mahn at digidescorp.com>:


----------
nosy: dmahn
priority: normal
severity: normal
status: open
title: e

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Sat Feb 19 04:57:03 2011
From: report at bugs.python.org (Dan Mahn)
Date: Sat, 19 Feb 2011 03:57:03 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>


New submission from Dan Mahn <dan.mahn at digidescorp.com>:

Can't send UDP packet to multicast address.  See traceback.

    s.sendto( bytearray, ("227.5.6.7", 6543))
socket.error: [Errno 10065] A socket operation was attempted to an unreachable host

----------
components: +None
title: e -> Error sending packets to multicast IPV4 address
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Sat Feb 19 04:57:28 2011
From: report at bugs.python.org (Dan Mahn)
Date: Sat, 19 Feb 2011 03:57:28 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1298087848.56.0.347475674298.issue11247@psf.upfronthosting.co.za>


Dan Mahn <dan.mahn at digidescorp.com> added the comment:

This has occurred in RC3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Sat Feb 19 05:53:26 2011
From: report at bugs.python.org (Tom Loredo)
Date: Sat, 19 Feb 2011 04:53:26 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1298091206.07.0.0645793207498.issue11217@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

I believe this is a bug.

The -32 part of Mac/Makefile.in builds and links the -32 versions here:


ifneq ($(LIPO_32BIT_FLAGS),)
	lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/python$(VERSION)-32 pythonw
	lipo $(LIPO_32BIT_FLAGS) -output $(DESTDIR)$(prefix)/bin/pythonw$(VERSION)-32 pythonw
	ln -sf python$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/python-32"
	ln -sf pythonw$(VERSION)-32 "$(DESTDIR)$(prefix)/bin/pythonw-32"
endif

For a framework build, the destinations are the framework location, and indeed the brew install does put them there.

Right after in Makefile.in is the unix tools part (which is run by default):

installunixtools:
	if [ ! -d "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ]; then  \
		$(INSTALL) -d -m $(DIRMODE) "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin" ;\
	fi
	for fn in python pythonw idle pydoc python-config smtpd.py 2to3 \
		  python$(VERSION) pythonw$(VERSION) idle$(VERSION) \
		  pydoc$(VERSION) python$(VERSION)-config smtpd$(VERSION).py \
		  2to3-$(VERSION) ;\
	do \
		ln -fs "$(prefix)/bin/$${fn}" "$(DESTDIR)$(FRAMEWORKUNIXTOOLSPREFIX)/bin/$${fn}" ;\
	done

I believe this needs an "ifneq ($(LIPO_32BIT_FLAGS),)" block that explicitly handles $(VERSION)-32, just like the pythonw section before it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Sat Feb 19 06:40:26 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Feb 2011 05:40:26 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298094026.0.0.0180510857577.issue11234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Antoine, I'm traveling and don't have immediate access to my svn checkout.  Can you fix this please?

----------
assignee: rhettinger -> pitrou
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:17:48 2011
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 19 Feb 2011 06:17:48 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1298096268.66.0.928290318145.issue11247@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I tested multicast without any issues using the attached script. I used RC3 on both Windows 7 and Linux. I did need to disable the firewall on my Windows system before multicast would work.

Start one or more clients using: "python mtest1.py client"

Send data using: "python mtest1.py server hello 10"

----------
nosy: +casevh
Added file: http://bugs.python.org/file20791/mtest1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Sat Feb 19 07:35:39 2011
From: report at bugs.python.org (Tom Loredo)
Date: Sat, 19 Feb 2011 06:35:39 +0000
Subject: [issue11217] python-32 not linked in /usr/local/bin in framework
	builds
In-Reply-To: <1297749549.77.0.923570440201.issue11217@psf.upfronthosting.co.za>
Message-ID: <1298097339.05.0.820443219246.issue11217@psf.upfronthosting.co.za>


Tom Loredo <loredo at astro.cornell.edu> added the comment:

The attached patch does the trick.

----------
Added file: http://bugs.python.org/file20792/Python-2.7.1-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11217>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:40:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 08:40:27 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1298104827.83.0.122171966958.issue11233@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The "Notes on availability" bullet list at the top of docs.python.org/library/os should already say everything that there is to say here...

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:45:12 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 08:45:12 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1298105112.02.0.384734508367.issue10709@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r88438.  Thanks!

Please indicate how much of this needs to be backported to 2.7 and 3.1.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:53:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 08:53:55 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1298105635.23.0.00463590448834.issue11222@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r88439 in py3k.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Sat Feb 19 09:58:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 08:58:34 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1298105914.77.0.641444037877.issue11184@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, committed to py3k in r88440.  Does this need backporting?

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Sat Feb 19 10:16:28 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 19 Feb 2011 09:16:28 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1298106988.16.0.584954330783.issue11222@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:00:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 10:00:29 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1298109629.69.0.385705587008.issue11184@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Okay, committed to py3k in r88440.  Does this need backporting?

Certainly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:07:07 2011
From: report at bugs.python.org (yeswanth)
Date: Sat, 19 Feb 2011 10:07:07 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298110027.12.0.0122928203924.issue11060@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

I have gone through the source of mkcfg.py and though of implementing version check by calling distutils2.is_valid_version() and then if it results false , call suggest_normalized_version() to ask the user if he would like the suggested version or enter a new version ...if it returns none, prompting the version again . For this i need to create a new function say "check_version()" and call it just after version is asked for in the query_user() function call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:36:14 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 19 Feb 2011 10:36:14 +0000
Subject: [issue11247] Error sending packets to multicast IPV4 address
In-Reply-To: <1298087823.89.0.505533825955.issue11247@psf.upfronthosting.co.za>
Message-ID: <1298111774.92.0.413705084966.issue11247@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Are you using a default gateway ?
Are you sure this gateway supports multicast ?
See for example http://www.sockets.com/err_lst1.htm#WSAENETUNREACH :
"""
WSAENETUNREACH (10051) Network is unreachable. 

Berkeley description: A socket operation was attempted to an unreachable network. 

WinSock description: Almost same as Berkeley. For WinSock, this error is equivalent to Berkeley's EHOSTUNREACH error, the catch-all error for unreachable hosts. "You can't get there from here." 

TCP/IP scenario: The local network system could generate this error if there isn't a default route configured. Typically, though, WinSock generates this error when it receives a "host unreachable" ICMP message from a router. The ICMP message means that a router can't forward the IP datagram, possibly because it didn't get a response to the ARP request (which might mean the destination host is down). Note: this error may also result if you are trying to send a multicast packet and the default gateway does not support multicast (check your interface configuration). 
"""

By the way, when you submit this kind of issue, it's a lot easier to analyse if you provide a sample code.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11247>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:42:22 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 19 Feb 2011 10:42:22 +0000
Subject: [issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1298112142.84.0.233051038389.issue11224@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

_FileInFile.read() does lots of unnecessary seeking and reads the same block again and again. The attached patch fixes that. Please try if it works for you.

----------
assignee:  -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file20793/tarfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11224>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:45:37 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Feb 2011 10:45:37 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298112337.11.0.0847516563791.issue11244@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Unassigning.  I don't think that r82043 is the *real* culprit here;  that bugfix just happened to expose a deficiency in the peepholer;  one that's already present in other situations:

>>> dis.dis(lambda: 2*(3*4))
  1           0 LOAD_CONST               1 (2)
              3 LOAD_CONST               4 (12)
              6 BINARY_MULTIPLY     
              7 RETURN_VALUE        
>>> dis.dis(lambda: (2*3)*4)
  1           0 LOAD_CONST               5 (24)
              3 RETURN_VALUE        

Antoine, does your patch take care of this case too?

----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:50:45 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 19 Feb 2011 10:50:45 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>


New submission from Greg Kochanski <gpk at kochanski.org>:

When you have a generator as an argument to zip(), code after the last yield statement may not get executed.  The problem is that zip() stops after it gets _one_ exception, i.e. when just one of the generators has finished.

As a result, if there were any important clean-up code at the end of a generator, it will not be executed.   Caches may not get flushed, et cetera.

At the least, this is a documentation bug that needs to be pointed out in both zip() and the definition of a generator().  More realistically, it is a severe wart on the language, because it violates the programmer's reasonable expectation that a generator executes until it falls off the end of the function.  It means that a generator becomes conceptually nasty: you cannot predict what it will do based just on an inspection of the code and the code it calls.

Likely, the same behavior happens in itertools, too.

----------
components: None
files: bug312.py
messages: 128842
nosy: gpk-kochanski
priority: normal
severity: normal
status: open
title: Tails of generator get lost under zip()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20794/bug312.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 11:55:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Feb 2011 10:55:26 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298112926.28.0.9727814531.issue11248@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This behavior is documented[0]:
"""The returned list is truncated in length to the length of the shortest argument sequence."""

You can use izip_longest instead[1].

[0]: http://docs.python.org/library/functions.html#zip
[1]: http://docs.python.org/library/itertools.html#itertools.izip_longest

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 12:04:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 11:04:57 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298112337.11.0.0847516563791.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298113493.3793.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 19 f?vrier 2011 ? 10:45 +0000, Mark Dickinson a ?crit :
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Unassigning.  I don't think that r82043 is the *real* culprit here;  that bugfix just happened to expose a deficiency in the peepholer;  one that's already present in other situations:
> 
> >>> dis.dis(lambda: 2*(3*4))
>   1           0 LOAD_CONST               1 (2)
>               3 LOAD_CONST               4 (12)
>               6 BINARY_MULTIPLY     
>               7 RETURN_VALUE        
> >>> dis.dis(lambda: (2*3)*4)
>   1           0 LOAD_CONST               5 (24)
>               3 RETURN_VALUE        
> 
> Antoine, does your patch take care of this case too?

It should. Can you test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Sat Feb 19 12:44:25 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 19 Feb 2011 11:44:25 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298115865.47.0.509954339791.issue11248@psf.upfronthosting.co.za>


Greg Kochanski <gpk at kochanski.org> added the comment:

(a) It is not documented for the symmetric (4, 4) case where the two generators are of equal length.

(b) Even for the asymmetric case, it is not documented in such a way that people are likely to see the implications.

(c) Documented or not, it's still a wart.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 14:56:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 13:56:08 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298123768.77.0.300479872349.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I also got this now, it happens with and without the str() patch stuff.  (Note that message.py line numbers are off by 1-2 lines ..).  I don't know more about that in the moment, but the only thing that's changed is that i do:

   alln = self._msg.items()[:] # In fact -> ensure all are header.Header
       # If any converted (str->Header) header names exist ...
       if len(alln):
            # Delete *all* occurrences of h (doesn't throw)
            for (n, b) in alln:
                del self._msg[n]
            # And append in order
            for (n, b) in alln:
                self._msg[n] = b


  Traceback (most recent call last):
    File "/Users/steffen/usr/bin/s-postman.py", line 953, in save_ticket
      mb.add(ticket.message())
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 595, in add
      self._toc[self._next_key] = self._append_message(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 733, in _append_message
      offsets = self._install_message(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 805, in _install_message
      self._dump_message(message, self._file, self._mangle_from_)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 215, in _dump_message
      gen.flatten(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 134, in _write
      self._dispatch(msg)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 151, in _dispatch
      main = msg.get_content_maintype()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 528, in get_content_maintype
      ctype = self.get_content_type()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 516, in get_content_type
      ctype = _splitparam(value)[0].lower()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 53, in _splitparam
      a, sep, b = param.partition(';')
  Exception: AttributeError: 'NoneType' object has no attribute 'partition'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:04:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 15:04:45 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298127885.63.0.884718682796.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

The latter one was my fault, i did LIST.append(name, HEADER.append(xy)), assuming that HEADER.append() returns self though it doesn't.  Sorry.  However - shouldn't Message.__setitem__ check for valid arguments (see msg128846 code snippet)?  It would have saved some anger...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:15:04 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 15:15:04 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298128504.06.0.984208021917.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

However, maybe that 5.1 message.py thing doesn't like header.Header instances.  Also extending msg128846, this one is related to the str() issue - added an extended email_message.2.patch.

  Traceback (most recent call last):
    File "/Users/steffen/usr/bin/s-postman.py", line 953, in save_ticket
      mb.add(ticket.message())
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 595, in add
      self._toc[self._next_key] = self._append_message(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 733, in _append_message
      offsets = self._install_message(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 805, in _install_message
      self._dump_message(message, self._file, self._mangle_from_)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/mailbox.py", line 215, in _dump_message
      gen.flatten(message)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 88, in flatten
      self._write(msg)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 134, in _write
      self._dispatch(msg)
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/generator.py", line 151, in _dispatch
      main = msg.get_content_maintype()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 530, in get_content_maintype
      ctype = self.get_content_type()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 518, in get_content_type
      ctype = _splitparam(value)[0].lower()
    File "/Users/steffen/usr/opt/py3k/lib/python3.2/email/message.py", line 53, in _splitparam
      a, sep, b = param.partition(';')
  Exception: AttributeError: 'Header' object has no attribute 'partition'

P.S.: i'm hard to take, and 'programming is an iterative task'...

----------
Added file: http://bugs.python.org/file20795/email_message.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:29:11 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 19 Feb 2011 15:29:11 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298129351.46.0.919311459666.issue11244@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:30:01 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sat, 19 Feb 2011 15:30:01 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1298129401.49.0.75821506292.issue8300@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Why isn't this implemented to work with __int__ as well?

----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8300>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:40:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 15:40:28 +0000
Subject: [issue11234] Possible error in What's new Python3.2(rc3)
	documentation (sysconfig.get_config_var)
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298130028.05.0.441280355957.issue11234@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, it's up to Georg to decide if it goes before 3.2. But I don't see the hurry: the online docs are rebuilt daily anyway.

----------
assignee: pitrou -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:49:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Feb 2011 15:49:48 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298130588.37.0.566711742321.issue11248@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

a) that's true, even if the behavior makes sense (when the first generator ends there's no reason to see what's next in the second). Georg, do you think it should be documented?

b) if you want to be sure that some clean-up is executed you should use a try/finally in the generator. Relying on the number of elements of another generator used together with zip() seems very fragile to determine when/if a clean-up should be done (what if the other generator has a different number of elements? what if an exception is raised before it's fully consumed? what if you use the generator in for/while loop and break the loop before reaching the end? ...).

c) even if you consider it as a wart, changing it for zip() will break compatibility and it's against the language moratorium. This behavior is also useful if e.g. you have the generators g1 that yields 1 2 3, g2 that yields 4 5 6, and g3 that yields a b c d e f and you want to first zip(g1, g3) and get 1a 2b 3c and then continue with zip(g2, g3) and get 4d 5e 6f. Checking in the first zip() if g3 reached its end or not would mean consuming the 'd', and that would be a worse wart imho.

----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:51:00 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Sat, 19 Feb 2011 15:51:00 +0000
Subject: [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1298130660.64.0.969020685761.issue10709@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Great!

I intend to check that branch 2.7 works fine on AIX once I will have finished with 3.x (which should be soon).
I will then update this file for Python 2.7 (there shouldn't be much changes hopefully).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10709>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:57:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 15:57:45 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1298131065.27.0.553614031398.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch adds a missing attribution, a missing bug number, fixes one typo (?content manager?) and five grammar issues.

I haven?t had time to make a full read-through during the last weeks, but here are a few comments about the overall structure of the file:
- The introduction is a bit scarce (compare that of 2.6);
- ?Other Language Changes? sounds strange, given that the previous sections (PEPs) are language as well as library changes ? name it something like ?Small Language Changes?;
- ?New, Improved, and Deprecated Modules? are not sorted nor grouped;
- Ditto for the bits of advice in the Porting section;
- The small sections about Unicode and codecs could be merged;
- What Antoine said about ?Code repository?.

----------
keywords: +patch
Added file: http://bugs.python.org/file20796/whatsnew-fixes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 19 16:59:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Feb 2011 15:59:21 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1298131161.61.0.167681859681.issue11233@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, but when you jump directly to one of the functions, you don't see that bullet list.  Whereas if it were a footnote on the 'avaiability: unix" statement, the natural thing would be to follow the footnote and thus learn the limitations on that statement.  Thus I think the footnote would be better than the bullet list at the top.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:02:03 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 16:02:03 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298131323.19.0.565794277224.issue11243@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20784/email_message.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:19:10 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 16:19:10 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298132350.94.0.819548919587.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

David, i'm going down now.  I'll raise the type to 'crash', because, in fact, EMail 5.1 doesn't really take care of header.Header objects in message.Message headers, which doesn't sound pretty useful to me!  The patch is sufficient for my broken thing (it doesn't produce a traceback at the moment - time to go for a sunday!), but since i don't really have a glue of mailbox.py / email/* it may not cover all places where a header.Header may occur but the code in fact assumes a str (and implicit conversion of Header to str doesn't work).

----------
type: behavior -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:35:46 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 19 Feb 2011 16:35:46 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298133346.27.0.780262775264.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

... as a last though of mine, here is a header of the well known spam mail:


>From MAILER-DAEMON Sat Feb 19 15:58:47 2011
Date: =?latin1?q?Tue=2C_4_Jan_2011_17=3A37=3A26_+0100_=28CET=29?=
From: =?latin1?q?=22SAJATNAPTAR=2ECOM=22_=3Cinfo=40sajatnaptar=2Ecom=3E?=
To: =?latin1?q?source-changes=40cvs=2Eopenbsd=2Eorg?=
Subject: =?latin1?q?Falinapt=3Fr_ingyenes_h=3Fzhozsz=3Fll=3Ft=3Fssal=2E_M=3Fr_rendelt=3Fl=3F_Olvass_el!?=
Message-ID: =?latin1?q?=3C20110104053726system=40sajatnaptar=2Ecom=3E?=
Content-Type: =?latin1?q?text/plain=3B_charset=3Diso-8859-1?=


Shouldn't email/* be smart enough to know that Date:, Content-Type:, Message-ID:, plus some other well-known, RFC-documented header names need *not* be converted, whatever type of object is used to represent them?  This could be implemented with a simple {}.

Bye.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:38:32 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 16:38:32 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Currently, memory management for the Py_tp_doc slot in PyType_FromSpec is ill-defined. The doc string being passed is stored in the type object as-is, but later released with PyObject_Free. To make this consistent, PyType_FromSpec should copy the string, so that it's guaranteed that relasing the memory matches allocation.

Without this patch, users will have to hold onto the type objects they get from PyType_FromSpec "forever".

----------
files: tp_doc.diff
keywords: patch
messages: 128857
nosy: loewis
priority: release blocker
severity: normal
status: open
title: Memory mismanagement with Py_tp_doc
Added file: http://bugs.python.org/file20797/tp_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:44:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 16:44:40 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298133880.05.0.87395941491.issue11249@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sure it should be a blocker?

----------
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 17:48:34 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 16:48:34 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298134114.91.0.0601141969303.issue11249@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If this isn't added, people using the API might see crashes. If they then work around crashes, they will see memory leaks in future releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:00:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 17:00:38 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298134838.65.0.0727679279485.issue11249@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, isn't Py_tp_doc characteristically bound to a constant char *, so that the problem doesn't manifest itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:23:27 2011
From: report at bugs.python.org (Mike Beachy)
Date: Sat, 19 Feb 2011 17:23:27 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298136207.07.0.221157091575.issue7291@psf.upfronthosting.co.za>


Mike Beachy <mbeachy at gmail.com> added the comment:

I've been in contact w/ Barry Scott offline re: the monkey patch previously mentioned. I'm attaching a 2.7 maintenance branch patch that he has needed to extend, and plans to follow up on.

----------
Added file: http://bugs.python.org/file20798/2_7_x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:25:19 2011
From: report at bugs.python.org (Mike Beachy)
Date: Sat, 19 Feb 2011 17:25:19 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298136319.24.0.740622071687.issue7291@psf.upfronthosting.co.za>


Mike Beachy <mbeachy at gmail.com> added the comment:

Attached to this comment (can you attach multiple files at once?) is the somewhat moldy 2.6.4 monkey patch, mercilessly ripped from my own code and probably not good for much.

----------
Added file: http://bugs.python.org/file20799/monkey_2_6_4.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:26:35 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 17:26:35 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298136395.91.0.659414317466.issue11249@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds like a blocker to me.  Martin, will you be able to provide a patch before final?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:27:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 17:27:03 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1298136423.49.0.444001490977.issue11233@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's a good point, indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:29:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Feb 2011 17:29:37 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1298136577.42.0.0462855538619.issue11071@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

?ric, go ahead an apply this patch except for the insertion of "the" in the codecs section.

I'm not making regrouping, reordering, merging or other stylistic changes at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:39:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 19 Feb 2011 17:39:34 +0000
Subject: [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1298137174.01.0.660299905475.issue11233@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11233>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:51:30 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 19 Feb 2011 17:51:30 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298137890.92.0.757774767154.issue11248@psf.upfronthosting.co.za>


Greg Kochanski <gpk at kochanski.org> added the comment:

Yes, the current behaviour makes sense from a language designer's viewpoint, and maybe even from the user's viewpoint (if the user thinks about it a carefully).

But, that's not the point of a computer language.   The whole reason we program in languages like python instead of asm is to match the behaviour of the silicon to human capabilities and expectations.   So, documentation needs to go beyond the minimum from which an expert could deduce the system behaviour.  It needs to point out unexpected things that a competent programmer might miss, even if they could potentially have deduced that unexpected behaviour.

The trouble here is that the syntax of a generator is so much like a function that it's easy to think of it as being as safe and simple as a function.  It's not: the "yield" statement lets a lot of external complexity leak in that's not relevant to a function (unless you're writing multithreaded code).  So, the documentation needs to help the user avoid such problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 18:55:36 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sat, 19 Feb 2011 17:55:36 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298138136.3.0.590710824161.issue11248@psf.upfronthosting.co.za>


Changes by Greg Kochanski <gpk at kochanski.org>:


----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:08:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 18:08:37 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1298136577.42.0.0462855538619.issue11071@psf.upfronthosting.co.za>
Message-ID: <4D600722.30401@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Applied in r88441.

I checked again that the issue numbers were right, and discovered that
the functions in site related to PEP 370 were actually new in 2.6, not
3.2, so you may want to remove that section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:11:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 18:11:34 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <4D600722.30401@netwok.org>
Message-ID: <4D6007D4.4010301@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

> I checked again that the issue numbers were right, and discovered that
> the functions in site related to PEP 370 were actually new in 2.6, not
> 3.2, so you may want to remove that section.

Sorry: The functions are indeed new in 2.7/3.2, it?s the command-line
functionality (python -m site --user-base) that was already here in
previous versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:15:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 18:15:21 +0000
Subject: [issue11234] Error in What's new 3.2rc3 with
	sysconfig.get_config_var('SO')
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298139321.45.0.838917959323.issue11234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The online docs are rebuilt, but people may read the version bundled with a tarball or installer and wonder at the discrepancy, if they notice it.

----------
title: Possible error in What's new Python3.2(rc3) documentation (sysconfig.get_config_var) -> Error in What's new 3.2rc3 with sysconfig.get_config_var('SO')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:18:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 18:18:48 +0000
Subject: [issue11234] Error in What's new 3.2rc3 with
	sysconfig.get_config_var('SO')
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298139528.02.0.642219113776.issue11234@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:22:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 18:22:10 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1298139730.68.0.250956017335.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1 section, among other strange differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:25:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 18:25:49 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298134838.65.0.0727679279485.issue11249@psf.upfronthosting.co.za>
Message-ID: <4D600B2B.3060505@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, isn't Py_tp_doc characteristically bound to a constant char *

That's exactly the problem: PyType_FromSpec puts in this string literal.
When the type is later released, PyObject_Free is called in
type_dealloc, which segfaults.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:26:18 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 18:26:18 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298136395.91.0.659414317466.issue11249@psf.upfronthosting.co.za>
Message-ID: <4D600B49.9060403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Sounds like a blocker to me.  Martin, will you be able to provide a patch before final?

The attached patch works fine for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:34:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 18:34:37 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <4D600B49.9060403@v.loewis.de>
Message-ID: <1298140473.3793.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Sounds like a blocker to me.  Martin, will you be able to provide a patch before final?
> 
> The attached patch works fine for me.

Is there some documentation somewhere for all this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:38:38 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Feb 2011 18:38:38 +0000
Subject: [issue11234] Error in What's new 3.2rc3 with
	sysconfig.get_config_var('SO')
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298140718.14.0.643369553317.issue11234@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

?ric, go ahead and fix this please.

----------
assignee: georg.brandl -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 19:47:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 18:47:15 +0000
Subject: [issue11234] Error in What's new 3.2rc3 with
	sysconfig.get_config_var('SO')
In-Reply-To: <1298140718.14.0.643369553317.issue11234@psf.upfronthosting.co.za>
Message-ID: <4D601031.6040607@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Done in r88442.  I found a missing closing quote and fixed it too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:01:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Feb 2011 19:01:46 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298142106.3.0.776820844034.issue11244@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It should. Can you test?

Ah, you're asking me to actually do some (minimal) work instead of just complaining?

Yep, the patch tests fine over here (OS X 10.6), and fixes the 2*(3*4) case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:07:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Feb 2011 19:07:52 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1298142472.54.0.0581386664288.issue8300@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Because (arguably) we don't want to be able to pack non-integral floats (or Decimal instances, or ...) using integer formats:

>>> import struct
[56090 refs]
>>> struct.pack('L', 2.3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: required argument is not an integer
[56125 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8300>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:14:27 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Feb 2011 19:14:27 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1298142867.47.0.217148394827.issue10181@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry, I'm unassigning myself from this;  I'm still following the issue, but just don't forsee having time to work on it at all.

----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:16:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 19:16:44 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298143004.09.0.697126173856.issue11248@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python
stage: committed/rejected -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:39:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 19:39:45 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298140473.3793.12.camel@localhost.localdomain>
Message-ID: <4D601C7F.3010009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>>> Sounds like a blocker to me.  Martin, will you be able to provide a patch before final?
>>
>> The attached patch works fine for me.
> 
> Is there some documentation somewhere for all this?

Can you please be more specific? What's "all this"?

That tp_doc will be copied is currently undocumented. PyType_FromSpec
is documented in the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:41:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 19:41:29 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <4D601C7F.3010009@v.loewis.de>
Message-ID: <1298144485.3793.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >>> Sounds like a blocker to me.  Martin, will you be able to provide a patch before final?
> >>
> >> The attached patch works fine for me.
> > 
> > Is there some documentation somewhere for all this?
> 
> Can you please be more specific? What's "all this"?
> 
> That tp_doc will be copied is currently undocumented. PyType_FromSpec
> is documented in the PEP.

I meant all of py_tp_doc, "limited api", "restricted api" show almost
zero hits in the API docs. A PEP is nice but I'm not sure many people
spontaneously read PEPs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 20:48:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 19 Feb 2011 19:48:53 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298144485.3793.13.camel@localhost.localdomain>
Message-ID: <4D601EA3.9080907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> That tp_doc will be copied is currently undocumented. PyType_FromSpec
>> is documented in the PEP.
> 
> I meant all of py_tp_doc, "limited api", "restricted api" show almost
> zero hits in the API docs. A PEP is nice but I'm not sure many people
> spontaneously read PEPs.

No, there is no documentation in the Doc directory. I *would* expect
that people interested in using the stable ABI do find the PEP and
read it. With the exception of this issue, I consider the PEP to be
complete and correct documentation (of course, it probably contains
errors that I'm unaware of).

However, documentation for the PEP 384 changes seems to be an
unrelated issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 22:34:37 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 19 Feb 2011 21:34:37 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298151277.53.0.0323879898372.issue11248@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sat Feb 19 22:47:52 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Feb 2011 21:47:52 +0000
Subject: [issue11249] Memory mismanagement with Py_tp_doc
In-Reply-To: <1298133512.09.0.818351697222.issue11249@psf.upfronthosting.co.za>
Message-ID: <1298152072.1.0.383073998036.issue11249@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, committed in r88443 (with error handling made more consistent).

BTW, the return from PyType_GenericAlloc isn't NULL-checked, which looks like a potential crasher to me.  Not release-critical though.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11249>
_______________________________________

From report at bugs.python.org  Sat Feb 19 22:50:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Feb 2011 21:50:43 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298152243.96.0.329258564119.issue11060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You don?t need a new function (and certainly not in the __init__ submodule, the right place would be the version module), just do something like this:

try:
    NormalizedVersion(text)
except IrrationalVersionError:
    # version is invalid

Alternative: use suggest_normalized_version, which returns a string or None, then display according text to prompt the user to accept the suggested version or type another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 00:26:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Feb 2011 23:26:13 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298157973.87.0.475325053153.issue11248@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This is not a bug.  It is an implementation specific detail and is not guaranteed behavior.  The submitted "example bug" is horrible code that makes unwarranted assumptions about the implementation -- it is an anti-pattern to write generators that assume that their consumers will run them to exhaustion so that cleanup code will be executed -- a number of tools violate this assumption.  If you're relying on this technique for cleanup, you're doing it wrong.

I'll look at this again after the 3.2 release.  When it was discussed before, the outcome was to introduce itertools.zip_longest() and to not over-document non-guaranteed implementation specific details (lest people rely on them and write code even worse than the OP's example).

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sun Feb 20 00:57:25 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 19 Feb 2011 23:57:25 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>


New submission from Christoph Gohlke <cgohlke at uci.edu>:

Running Tools/Scripts/2to3.py on Python 3.2rc3 or 2.7.1 for Windows on a file that contains a formfeed character (0x0C, <FF>) results in a truncated file. 

E.g. a file (attached) with the content

print 1
<FF>
print 2

is incorrectly refactored:

@@ -1,4 +1,1 @@
-print 1
-
-
-print 2
+print(1)


Python 2.6.6 and 3.1.3 correctly refactor the file:

-print 1
+print(1)
 <FF>
-print 2
+print(2)

----------
files: formfeedbug.py
messages: 128885
nosy: cgohlke
priority: normal
severity: normal
status: open
title: 2to3 truncates files at formfeed character
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20800/formfeedbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Sun Feb 20 00:57:36 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 19 Feb 2011 23:57:36 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1298159856.49.0.340274486201.issue11250@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
components: +2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Sun Feb 20 00:58:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Feb 2011 23:58:09 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1298159889.82.0.177445439042.issue11250@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Sun Feb 20 01:26:28 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Feb 2011 00:26:28 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1298139730.68.0.250956017335.issue11071@psf.upfronthosting.co.za>
Message-ID: <AANLkTikgKpfh1-j6vrYBiJuUskpJLy=LghN=GEDWqOA-@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Sun, Feb 20, 2011 at 4:22 AM, ?ric Araujo <report at bugs.python.org> wrote:
> It appears that Misc/NEWS in 3.2 lists the new functions under the 3.1 section, among other strange differences.

"new in 3.2" changes are relative to 3.1, while 2.7 is relative to
2.6. They're treated as separate streams of development. Since 3.1
came out well after 2.6, there are some things that were new in 2.7
that 3.1 already included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Feb 20 01:29:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Feb 2011 00:29:28 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1298161768.51.0.549622284682.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the message, but I already knew that.  What I meant is that in the 3.2 version of Misc/NEWS, the addition of the functions is listed under the 3.1 section instead of 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sun Feb 20 01:37:08 2011
From: report at bugs.python.org (Jon McKenzie)
Date: Sun, 20 Feb 2011 00:37:08 +0000
Subject: [issue11251] cmd.Cmd tab completion treats dashes as spaces
In-Reply-To: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>
Message-ID: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>


New submission from Jon McKenzie <jcmcken at gmail.com>:

I'm writing a cmd.Cmd module that operates on filenames. As such, I'm attempting to write tab completions that operate similar to bash. However, files that contain dashes (hyphens) appear to exhibit unexpected behavior.

It appears that somewhere along the line, dashes are converted into spaces for the purposes of tab completion.

So, for example..

(Cmd) edit blah-<tab><tab>

Should print..

blah-1.0.0.txt  blah-2.0.0.txt

And..

(Cmd) edit blah-1<tab><tab>

Should autocomplete to..

(Cmd) edit blah-1.0.0.txt

Instead, the following behavior occurs:

(Cmd) edit blah-<tab><tab>

..becomes...

(Cmd) edit blah-blah

..and thus..

(Cmd) edit blah-blah-<tab><tab>

..becomes, in turn..

(Cmd) edit blah-blah-blah

My completion function is absolutely standard, as far as I'm able to tell from looking at other examples (see attached)

----------
files: completion.snip
messages: 128888
nosy: Jon.McKenzie
priority: normal
severity: normal
status: open
title: cmd.Cmd tab completion treats dashes as spaces
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file20801/completion.snip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11251>
_______________________________________

From report at bugs.python.org  Sun Feb 20 02:41:44 2011
From: report at bugs.python.org (Greg Kochanski)
Date: Sun, 20 Feb 2011 01:41:44 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298166104.1.0.316331314972.issue11248@psf.upfronthosting.co.za>


Greg Kochanski <gpk at kochanski.org> added the comment:

The code (bug312.py) was not submitted as a "pattern", but rather as an example of a trap into which it is easy to fall, at least for the 99% of programmers who are users of the language rather than its implementers.  


The basic difference is that while one can write a function that is guaranteed to execute to the end of its body[*]; one cannot do that with a generator function.   This point ought to be made in the documentation.
[* Neglecting SIGKILL and perhaps a few abnormal cases.]

The current documentation emphasizes the analogy to functions (which can be misleading) and (in section 6.8) explictly says that the normal behaviour of a generator function is to run all the way to completion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sun Feb 20 04:40:07 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Sun, 20 Feb 2011 03:40:07 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>


New submission from Suresh Kalkunte <sskalkunte at gmail.com>:

Referring to URL for files used to build the Apache Portable Runtime Utilities library using Python 2.7.1(AMD64) or 2.6.5(Cygwin) on a Win32 system (Windows 7), when apr/build/gen-build.py (http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/build/gen-build.py?revision=886996&view=markup) parses '\' on line 96 and 97 in apr-util/build.conf (http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/build.conf?revision=886996&view=markup), it recognizes them as separate tokens causing the script to fail on line 168 "assert file[-2:] == '.c'". If the line continuation notation ('\') is removed from build.conf, gen-build.py performs without errors. 

On a Redhat Linux, I have verified Python 2.5.5 (and trust 2.7.1 to provide the same behavior on Linux) handles '\' without errors leading me to believe that if this is a bug, it is only on Win32 platform (and instances where '\' is used for directory path separation).

I am new to Python, from searching the python bug database, I have not been able to find the above condition covered. If this bug has already been identified, please disregard.

----------
components: Interpreter Core, Windows
messages: 128890
nosy: Suresh.Kalkunte
priority: normal
severity: normal
status: open
title: Handling statement OR assignment continuation '\' on Win32 platform
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 05:14:39 2011
From: report at bugs.python.org (Matt Joiner)
Date: Sun, 20 Feb 2011 04:14:39 +0000
Subject: [issue8300] Allow struct.pack to handle objects with an __index__
	method.
In-Reply-To: <1270295507.67.0.95768179333.issue8300@psf.upfronthosting.co.za>
Message-ID: <1298175279.73.0.828731231945.issue8300@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Thanks Mark for clearing that up. I found this link to be useful in explaining the purpose of __index__: http://docs.python.org/release/2.5.1/whatsnew/pep-357.html

I think the choice of allowing only __index__ was the right choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8300>
_______________________________________

From report at bugs.python.org  Sun Feb 20 06:32:54 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Feb 2011 05:32:54 +0000
Subject: [issue11248] Tails of generator get lost under zip()
In-Reply-To: <1298112645.15.0.0904865308119.issue11248@psf.upfronthosting.co.za>
Message-ID: <1298179974.42.0.254926794123.issue11248@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've looked at the docs again and think they're fine.  And in the 3.x docs, the iterator version of zip() specifies its implementation with a pure python equivalent that makes it clear that the iterator is not run to exhaustion.  

Note that zip() has existed since 2.0 and iterators/generators since 2.2.  The docs for them have worked just fine, so I wouldn't worry too much about their being a "trap for 99% of programmers who aren't implementers."

GPK, I can see that you're wound-up about this, but you seem to have a profound misunderstanding about iterators/generators and have incorrectly assumed an implied contract for consumer functions to completely consume their inputs.  Sorry, but I'm going to close this one.  For further discussion, I recommend the python tutor mailing list.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11248>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:13:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Feb 2011 06:13:46 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
Message-ID: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I've just noticed that my application is incompatible with Python 2.5, because ctypes.wintypes is missing SHORT constants. However, I can't find the information when these symbols were introduced first. To prevent such confusion in future it would be nice to extract symbol information for each Python release and automatically include the version of the first appearance in documentation.

----------
assignee: docs at python
components: Documentation
messages: 128893
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: autodocument first appearance of ctypes.wintypes constants
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11253>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:27:57 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Feb 2011 06:27:57 +0000
Subject: [issue2405] Drop w9xpopen and all dependencies
In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za>
Message-ID: <1298183277.97.0.796936514274.issue2405@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I still see w9xpopen.exe in my Python 3.2 installation, which is kind of strange to me.

----------
nosy: +techtonik
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2405>
_______________________________________

From report at bugs.python.org  Sun Feb 20 07:43:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Feb 2011 06:43:12 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298184192.25.0.610811638788.issue11243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, it's not a crash, a crash is when the interpreter segfaults.

I'm not clear on why you are having problems, actually, since if you treat the messages as binary (which they are), then you shouldn't be getting Headers introduced into the mix.  But like I said I don't have time to look at this right now.

The problem with Header not being handled properly does need to be addressed, though.

----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sun Feb 20 08:13:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Feb 2011 07:13:14 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298185994.56.0.588104301363.issue11243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I think I see what is going on.  If I'm right, then you are right, this is a serious problem for actually processing spam emails using email 5.1.  Unfortunately it's too late to do anything for 3.2.0.  But email 5.1 is still worlds better at handling well formed binary emails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Sun Feb 20 10:54:58 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Feb 2011 09:54:58 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

During installation of Python packages (setup.py install or bdist), distutils puts .pyc files into the installed source directory, instead of moving them into __pycache__. This may mean that they are not getting used after installation (with potentially no way of getting updated due to lack of write access by users), and that source files that get imported during installation may end up with .pyc files in both the source directory and the __pycache__ directory in the installed package.

The relevant python-dev thread is here:

http://thread.gmane.org/gmane.comp.python.devel/121248/

----------
assignee: tarek
components: Distutils
messages: 128897
nosy: eric.araujo, scoder, tarek
priority: normal
severity: normal
status: open
title: distutils doesn't byte-compile .py files to __pycache__ during installation
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:12:33 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Feb 2011 10:12:33 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298196753.95.0.416236918902.issue11252@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why do you think this is a bug in Python as opposed to one in the script parsing the .conf file?

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:21:24 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Feb 2011 10:21:24 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1298197284.56.0.702982438511.issue11254@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Here's a patch. I basically copied over the way py_compile determines the .pyc file name.

It works for me for a "normal" installation. However, I couldn't test it with "-O", as 2to3 crashes for me when I enable it during installation. I guess that's a separate issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file20802/issue11254.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Feb 20 11:28:07 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 20 Feb 2011 10:28:07 +0000
Subject: [issue11255] 2to3 throws AttributeError during distutils installation
	with -O
In-Reply-To: <1298197687.53.0.332108526066.issue11255@psf.upfronthosting.co.za>
Message-ID: <1298197687.53.0.332108526066.issue11255@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

When running a distutils installation of Cython (which uses lib2to3) as "python3.2 -O setup.py bdist", I get this:

Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "setup.py", line 319, in <module>
    **setup_args
  File "/opt/python3.2-opt/lib/python3.2/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/bdist.py", line 132, in run
    self.run_command(cmd_name)
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/bdist_dumb.py", line 74, in run
    self.run_command('build')
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/build.py", line 128, in run
    self.run_command(cmd_name)
  File "/opt/python3.2-opt/lib/python3.2/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/opt/python3.2-opt/lib/python3.2/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/opt/python3.2-opt/lib/python3.2/distutils/command/build_py.py", line 404, in run
    self.run_2to3(self.updated_files)
  File "/opt/python3.2-opt/lib/python3.2/distutils/util.py", line 649, in run_2to3
    return run_2to3(files, self.fixer_names, self.options, self.explicit)
  File "/opt/python3.2-opt/lib/python3.2/distutils/util.py", line 597, in run_2to3
    r.refactor(files, write=True)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 296, in refactor
    self.refactor_file(dir_or_file, write, doctests_only)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 349, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 381, in refactor_string
    self.refactor_tree(tree, name)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/refactor.py", line 442, in refactor_tree
    find_root(node)
  File "/opt/python3.2-opt/lib/python3.2/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128900
nosy: scoder
priority: normal
severity: normal
status: open
title: 2to3 throws AttributeError during distutils installation with -O
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11255>
_______________________________________

From report at bugs.python.org  Sun Feb 20 12:32:24 2011
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 20 Feb 2011 11:32:24 +0000
Subject: [issue11127] sockets should not be pickleable
In-Reply-To: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>
Message-ID: <1298201544.53.0.214284145371.issue11127@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

the correct way is to provide a __getstate__ method for socket right? I have implemented that in the attached patch.

----------
keywords: +patch
nosy: +xuanji
Added file: http://bugs.python.org/file20803/issue11127.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11127>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:11:10 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 20 Feb 2011 12:11:10 +0000
Subject: [issue11256] inspect.getcallargs raises TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

inspect.getcallargs raises TypeError if given a function with only **kwargs, and some keyword arguments:

Python 3.3a0 (py3k:88451, Feb 20 2011, 12:37:22) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> from inspect import getcallargs
>>> 
>>> def f(**kwargs): pass
... 
>>> f(a=1, b=2)
>>> 
>>> getcallargs(f, a=1, b=2)
Traceback (most recent call last):
    ...
TypeError: f() takes no arguments (2 given)


In line 946 of inspect.py the "num_args == 0 and num_total" condition is true: the function expects 0 positional arguments and got more than zero arguments, but in this case these are keyword arguments, so it shouldn't raise TypeError.

----------
components: Library (Lib)
messages: 128902
nosy: benjamin.peterson, durban, gsakkis
priority: normal
severity: normal
status: open
title: inspect.getcallargs raises TypeError on valid arguments
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11256>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:47:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Feb 2011 12:47:23 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1298206043.08.0.432270578302.issue11254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  Regarding the problem with 2to3 and -O, maybe you can run 2to3 manually, copy the setup.py and run python3.2 -0.  disutils.util.byte_compile is not tested, so this patch requires at least careful manual testing, and if possible a unit test.

In distutils2, it may be possible to replace this function with a compileall call.

----------
components: +Distutils2
nosy: +alexis, barry
stage:  -> patch review
versions: +3rd party, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:48:25 2011
From: report at bugs.python.org (Florian Mayer)
Date: Sun, 20 Feb 2011 12:48:25 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1298206105.45.0.63301802165.issue11133@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

Apparently another way to get getattr_static to execute code in Python 2.3rc3 is simply the following.

>>> class Foo:
...     @property
...     def __dict__(self):
...         print("Hello, World.")
...         return {}
... 
>>> import inspect
>>> inspect.getattr_static(Foo(), 'a')
Hello, World.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/name/opt/lib/python3.2/inspect.py", line 1130, in getattr_static
    raise AttributeError(attr)
AttributeError: a
>>>

----------
nosy: +segfaulthunter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11133>
_______________________________________

From report at bugs.python.org  Sun Feb 20 13:59:45 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 20 Feb 2011 12:59:45 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298206785.62.0.166973087904.issue11060@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

I guess this needs to be reviewed . Added support for checking version in mkcfg.py by making use of suggest_normalized_version .. (didnt not an error  for non matching suggestion , though it will prompt for the version  it again )

----------
Added file: http://bugs.python.org/file20804/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:03:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 20 Feb 2011 13:03:49 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298207029.18.0.402704852703.issue11060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not bad!  You need to test the script, at least manually, if possible with unit tests.  This typo slipped in:

+		    self.data.get['version']=suggested_version
Remove ?.get? (also add spaces around operators).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 14:32:20 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 20 Feb 2011 13:32:20 +0000
Subject: [issue11256] inspect.getcallargs raises TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298208740.05.0.236548558161.issue11256@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Here is a patch. It also includes tests that would have detected this bug. It also corrects a case when getcallargs raised an exception with a different message (there are tests also for this):

>>> def f(**kwargs): pass
... 
>>> f(1, a=2)
Traceback (most recent call last):
    ...
TypeError: f() takes exactly 0 positional arguments (2 given)
>>> 
>>> getcallargs(f, 1, a=2)
Traceback (most recent call last):
    ...
TypeError: f() takes no arguments (2 given)

There is a comment in the patch about this case: the message given by Python is also incorrect, because it says that 2 positional arguments are given, but there was only 1 positional argument (the other was a keyword argument).  The patch currently handles this case by producing the same (incorrect) message as Python.

----------
keywords: +patch
Added file: http://bugs.python.org/file20805/issue11256.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11256>
_______________________________________

From report at bugs.python.org  Sun Feb 20 15:00:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 14:00:36 +0000
Subject: [issue11254] distutils doesn't byte-compile .py files to __pycache__
	during installation
In-Reply-To: <1298195698.48.0.330644441328.issue11254@psf.upfronthosting.co.za>
Message-ID: <1298210436.37.0.553292898128.issue11254@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11254>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:22:11 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 20 Feb 2011 15:22:11 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298215331.76.0.286747820328.issue11060@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Removed file: http://bugs.python.org/file20804/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:24:26 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 20 Feb 2011 15:24:26 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298215466.68.0.229940646773.issue11060@psf.upfronthosting.co.za>


yeswanth <swamiyeswanth at yahoo.com> added the comment:

Sorry for the typo. I ran the code though and it worked fine. I guess might have patched a wrong file :( . Made the changes as you asked. Will try for the unit tests :)

----------
Added file: http://bugs.python.org/file20806/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:24:46 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 20 Feb 2011 15:24:46 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298215486.98.0.733396363894.issue11060@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Removed file: http://bugs.python.org/file20806/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:25:07 2011
From: report at bugs.python.org (yeswanth)
Date: Sun, 20 Feb 2011 15:25:07 +0000
Subject: [issue11060] distutils2 sdist does not complain about version that is
	not PEP 386 compliant
In-Reply-To: <1296312944.75.0.70099754625.issue11060@psf.upfronthosting.co.za>
Message-ID: <1298215507.81.0.184618270551.issue11060@psf.upfronthosting.co.za>


Changes by yeswanth <swamiyeswanth at yahoo.com>:


Added file: http://bugs.python.org/file20807/diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11060>
_______________________________________

From report at bugs.python.org  Sun Feb 20 16:44:07 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 20 Feb 2011 15:44:07 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asyncore.py:
-----------
    def add_channel(self, map=None):
        #self.log_info('adding channel %s' % self)
        if map is None:
            map = self._map
        map[self._fileno] = self
---------

As we see, it add itself to a map, creating unnecessary refences to 'self'.

Such code should be rewritten via weakref. Now it's unknown when object will garbage collected. For example, if someone forget to call close(), object will stuck, eating file descriptor and memory... 

When using weakref, we may guarantee (via callback fcuntion), that we call close() when last reference to object has been lost. Also, such behaviour guarantee, that object will be garbage collected when last user's reference has gone.

To approve my thoughts, see code:
------------------------------
class MyServer(asyncore.dispatcher):
    def __init__(self, listenaddr):
        asyncore.dispatcher.__init__(self)
        self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
        self.set_reuse_addr()
        self.bind(listenaddr)
        self.listen(5)
    def handle_accept(self):
        while 1:
            r=self.accept()
            if r is None:
                break
            my_conn_handler(r[0])
------------
As we see, we create a new instance via my_conn_handler(), and we do not store reference to it, but object will not be garbage collected. It's unexpected behaviour.

----------
components: Library (Lib)
messages: 128909
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore stores unnecessary object references
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:03:59 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 20 Feb 2011 16:03:59 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

(This applies to all versions of Python I investigated, although the attached patch is for Python 2.7)

I wondered why `import uuid` took so long, so I did some profiling.

It turns out that `find_library` wastes at lot of time because of this crazy regular expression in `_findSoname_ldconfig`.

A quick look at the ldconfig source (namely, the print_cache routine which is invoked when you call `ldconfig -p`, http://sourceware.org/git/?p=glibc.git;a=blob;f=elf/cache.c#l127) confirmed my suspicion that the ldconfig's output could easily be parsed without such a regex monster.

I attached two patches that fix this problem. Choose one! ;-)

The ctypes tests pass with my fixes, and here comes some benchmarking:

$ cat benchmark_ctypes.py 
from ctypes.util import find_library
for i in xrange(10):
  for lib in ['mm', 'c', 'bz2', 'uuid']:
    find_library(lib)

# Current implementation
$ time python benchmark_ctypes.py 
real    0m11.813s
...
$ time python -c 'import uuid'
real    0m0.625s
...

# With my patch applied
$ cp /tmp/ctypesutil.py ctypes/util.py
$ time python benchmark_ctypes.py 
real    0m1.785s
...
$ time python -c 'import uuid'
real    0m0.182s
...

----------
assignee: theller
components: ctypes
files: faster-find-library1.diff
keywords: patch
messages: 128910
nosy: jonash, theller
priority: normal
severity: normal
status: open
title: ctypes: Speed up find_library() on Linux by 500%
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20808/faster-find-library1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:04:57 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 20 Feb 2011 16:04:57 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298217897.99.0.0141032553774.issue11258@psf.upfronthosting.co.za>


Changes by Jonas H. <jonas at lophus.org>:


Added file: http://bugs.python.org/file20809/faster-find-library2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:06:25 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 20 Feb 2011 16:06:25 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298217985.9.0.381637023457.issue11258@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

(might also be related to http://bugs.python.org/issue11063)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:10:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 16:10:43 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298218243.58.0.521794403567.issue11258@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:35:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 16:35:29 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298219729.93.0.0841258968673.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the first patch adapted for py3k.

----------
Added file: http://bugs.python.org/file20810/faster-find-library1-py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:36:36 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 16:36:36 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298219796.54.0.391061004391.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, re.escape is probably still needed around name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:40:02 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 20 Feb 2011 16:40:02 +0000
Subject: [issue11259] asynchat
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asynchat does not check if terminator is negative integer. so constructions like self.ac_in_buffer[:n] will lead to misbehaviour.

When that integer goes from net, attack can be crafted. For example, on Content-Length field.

----------
components: Library (Lib)
messages: 128914
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asynchat
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:40:47 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 20 Feb 2011 16:40:47 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298220047.72.0.565840006662.issue11259@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
title: asynchat -> asynchat does not check if terminator is negative integer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sun Feb 20 17:44:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 16:44:59 +0000
Subject: [issue11127] sockets should not be pickleable
In-Reply-To: <1296894626.58.0.23469074371.issue11127@psf.upfronthosting.co.za>
Message-ID: <1298220299.64.0.319207073387.issue11127@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You also need to a test to Lib/test/test_socket.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11127>
_______________________________________

From report at bugs.python.org  Sun Feb 20 18:52:26 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 20 Feb 2011 17:52:26 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1298224346.98.0.270187343251.issue11133@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Attached is a patch that fixes the issue: The dict methods are now used directly and before every access to an instance's "__dict__" attribute, it is checked that that attribute is really the instance's attribute and not a class attribute of the instance's type.

----------
keywords: +patch
nosy: +Trundle
Added file: http://bugs.python.org/file20811/inspect_issue_11133.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11133>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:03:51 2011
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 20 Feb 2011 20:03:51 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>


New submission from Xavier Morel <xavier.morel at masklinn.net>:

argparse has been merged to the standard library in 3.2, and (tell me if I'm wrong) would therefore be the "best-practices" way to parse command-line arguments.

Numerous stdlib modules can be used as scripts, but they tend to have ad-hoc documentation (if they are at all documented) and arguments parsing (using any of the 4 available methods in Python: straight from sys.argv, getopt, optparse and argparse).

I picked smtpd as a first shot since it does something useful (SMTP proxy) and has a pretty good (if ad-hoc) command-line documentation.

smtpd is currently using getopt for its options parsing and the argument parsing is very cleanly factored: the port only had to replace the implementation of the `parseargs` function (and add and remove some helpers).

* The port keeps the existing arguments semantics (including the mandatory host:port syntax for the local and remote specs if overridden)

* The port tries to maintain the old error messages, but due to the way argparse works (or the way I used it for the specs) the parity is not perfect when providing incorrect specs

* The CLI help uses argparse's formatting, and the documentation for the local and remote specs was set on these arguments rather than as an epilog. The version string was also removed from the help screen

* Because they are set by argparse's arguments validation, the status codes on incorrect arguments are slightly different:
  - running smtpd.py as a regular user without the `--nosetuid` flag still exits with status 1
  - providing incorrect spec formats (missing or non-int port) or providing too many positional arguments (3 or more) now exits with status 2 (formerly 1)

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: smtpd-to-argparse.diff
keywords: patch
messages: 128917
nosy: barry, docs at python, xmorel
priority: normal
severity: normal
status: open
title: smtpd-as-a-script feature should be documented and should use argparse
versions: Python 3.3
Added file: http://bugs.python.org/file20812/smtpd-to-argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:06:11 2011
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 20 Feb 2011 20:06:11 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298232371.33.0.593051659.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Second patch: documenting smtpd-as-a-script in the module's rst

----------
Added file: http://bugs.python.org/file20813/smtpd-as-script-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:24:57 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 20 Feb 2011 20:24:57 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298233497.48.0.540703144285.issue11199@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

The problem is due to the way urllib closes a FTP data transfer.
The data channel is closed, and a shutdown hook is called that waits for a message on the control channel. But in that case, when the data connection is closed while the transfer is in progress, the server doesn't send any further message on the control channel, and we remain stuck (note that if the data channel is closed after the file has been transfered, in that case an end of transfer message is sent, which explains why this dones't happen with the sleep in between).
The solution is to first wait for a message on the control channel, and then close the data channel (which makes sense, a close hook is generally called before closing the corresponding connection).
The attached patch just does that.
Note that I'm not sure why we need to wait for a further message on the control channel (maybe it's part of an RFC or something...).

----------
keywords: +patch
nosy: +neologix
Added file: http://bugs.python.org/file20814/urllib_ftp_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:30:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 20:30:51 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298233851.12.0.512904884169.issue11199@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola, orsenthil
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:31:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 20:31:51 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298233911.5.0.717525097303.issue11259@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:32:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Feb 2011 20:32:47 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298233967.43.0.555978626329.issue11257@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sun Feb 20 21:47:24 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 20 Feb 2011 20:47:24 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298234844.55.0.080293377149.issue11257@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Such code should be rewritten via weakref.

Can you write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:01:38 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 20 Feb 2011 21:01:38 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298235698.46.0.0923945191411.issue11259@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What do you mean by "constructions like self.ac_in_buffer[:n] will lead to misbehaviour."?
Please try to be more precise (e.g. by providing a piece of code which demonstrates the issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sun Feb 20 22:04:04 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 20 Feb 2011 21:04:04 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298235844.59.0.223101786659.issue11199@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file20815/urllib_ftp_close_27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:07:31 2011
From: report at bugs.python.org (David Phillips)
Date: Sun, 20 Feb 2011 22:07:31 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>


New submission from David Phillips <david.193.phillips at gmail.com>:

The following code works on python 3.1.3 but fails on Python 3.2rc2 (r32rc2:88269, Jan 30 2011, 14:30:28). (I run Mac OS X, version 10.6.6.)

-----------------------------

import urllib, urllib.request, urllib.error, urllib.parse

form = urllib.parse.urlencode({'field1':'Log in'})
try:
	response = urllib.request.urlopen('http://www.google.com/', form)
except urllib.error.HTTPError as exception:
	print (exception)

---------------------------------------

When loaded, the following error messages are generated:

---------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 1057, in do_request_
    mv = memoryview(data)
TypeError: cannot make memory view because object does not have the buffer interface

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 138, in urlopen
    return opener.open(url, data, timeout)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 364, in open
    req = meth(req)
  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/urllib/request.py", line 1062, in do_request_
    data))
ValueError: Content-Length should be specified                                 for iterable data of type <class 'str'> 'field1=Log+in'

------------------------------------

----------
components: Library (Lib)
messages: 128922
nosy: david193
priority: normal
severity: normal
status: open
title: urlopen breaks when data parameter is used.
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:11:26 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Feb 2011 22:11:26 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298239886.66.0.302615390783.issue11261@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:13:47 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 20 Feb 2011 22:13:47 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298240027.82.0.905307183334.issue11259@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sun Feb 20 23:28:14 2011
From: report at bugs.python.org (Eugene Morozov)
Date: Sun, 20 Feb 2011 22:28:14 +0000
Subject: [issue11262] re.sub replaces only first 32 matches with re.U flag
In-Reply-To: <1298240893.99.0.359755744829.issue11262@psf.upfronthosting.co.za>
Message-ID: <1298240893.99.0.359755744829.issue11262@psf.upfronthosting.co.za>


New submission from Eugene Morozov <eugene.morozov at gmail.com>:

There's a peculiar and difficult to find bug in the re.sub method. Try following example:
>>> text = 'X'*4096
>>> nt = re.sub(u"XX", u".", text, re.U)
>>> nt
u'............XXXXXXXXXXXXXXXXXXX' (only 32 dots, the rest of the string is not changed).

If I first compile regexp, and then perform compiled_regexp.sub, everything seems to work correctly.

----------
components: Regular Expressions
messages: 128923
nosy: Eugene.Morozov
priority: normal
severity: normal
status: open
title: re.sub replaces only first 32 matches with re.U flag
type: security
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11262>
_______________________________________

From report at bugs.python.org  Mon Feb 21 00:00:38 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 20 Feb 2011 23:00:38 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1298242838.31.0.510190944436.issue9995@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Instead of using http over TCP and basic auth to upload stuff to PyPI, you can also use SSH. In this case, no password is needed at all.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Mon Feb 21 00:01:05 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Feb 2011 23:01:05 +0000
Subject: [issue11262] re.sub replaces only first 32 matches with re.U flag
In-Reply-To: <1298240893.99.0.359755744829.issue11262@psf.upfronthosting.co.za>
Message-ID: <1298242865.3.0.703005548063.issue11262@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

If you read docs carefully, you notice that re.sub doesn't accept flags argument. Its 4th argument is count, re.U numerical value is 32.

Closing as invalid. There are some duplicates too, I'm sure.

----------
nosy: +SilentGhost
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11262>
_______________________________________

From report at bugs.python.org  Mon Feb 21 00:02:10 2011
From: report at bugs.python.org (Reiner Gerecke)
Date: Sun, 20 Feb 2011 23:02:10 +0000
Subject: [issue11263] Wrong link to source code of ftplib
In-Reply-To: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>
Message-ID: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>


New submission from Reiner Gerecke <mr.squidd at gmail.com>:

The link to the source code of the ftp module at the top of the documentation (http://docs.python.org/release/3.2/library/ftplib.html) points to a non-existant page.

  **Source code:** :source:`Lib/ftp.py`

It is referencing ftp.py, but needs to be ftplib.py.

----------
assignee: docs at python
components: Documentation
messages: 128926
nosy: Reiner.Gerecke, docs at python
priority: normal
severity: normal
status: open
title: Wrong link to source code of ftplib
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11263>
_______________________________________

From report at bugs.python.org  Mon Feb 21 00:10:41 2011
From: report at bugs.python.org (SilentGhost)
Date: Sun, 20 Feb 2011 23:10:41 +0000
Subject: [issue11263] Wrong link to source code of ftplib
In-Reply-To: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>
Message-ID: <1298243441.47.0.786148422465.issue11263@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

here is the patch

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
Added file: http://bugs.python.org/file20816/ftplib.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11263>
_______________________________________

From report at bugs.python.org  Mon Feb 21 00:11:04 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Sun, 20 Feb 2011 23:11:04 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1298243464.8.0.617496266387.issue11200@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Ha!  Your reply jogged my memory.  MvL mentioned exactly the potential for this backwards incompatibility here: http://mail.python.org/pipermail/python-dev/2010-December/106351.html when talking about whether other API changes could go into distutils to support accepted PEPs.

tarek, eric, since python-3.2 is now out, I assume that you're going to want to port distribute rather than back the changes out of distutils.  Do you want a bug report or is this high enough priority that you're already working on it?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Mon Feb 21 02:42:22 2011
From: report at bugs.python.org (Yang Zhang)
Date: Mon, 21 Feb 2011 01:42:22 +0000
Subject: [issue11226] subprocesses experience mysterious delay in receiving
	stdin EOF
In-Reply-To: <1297897452.24.0.902821859924.issue11226@psf.upfronthosting.co.za>
Message-ID: <1298252542.49.0.00478159881299.issue11226@psf.upfronthosting.co.za>


Yang Zhang <yang.pythonbugs at mailnull.com> added the comment:

After way too much time, I figured it out, after a quote from this post jumped out at me:

  See the "I/O on Pipes and FIFOs" section of pipe(7) ("man 7 pipe")

  "If all file descriptors referring to the write end of a pipe have
  been closed, then an attempt to read(2) from the pipe will see end-of-
  file (read(2) will return 0)."

I should've known this, but it never occurred to me - had nothing to do with Python in particular. What was happening was: the subprocesses were getting forked with open (writer) file descriptors to each others' pipes. As long as there are open writer file descriptors to a pipe, readers won't see EOF.

E.g.:

  p1=Popen(..., stdin=PIPE, ...)
    # creates a pipe the parent process can write to
  p2=Popen(...)
    # inherits the writer FD - as long as p2 exists, p1 won't see EOF

Turns out there's a close_fds parameter to Popen, so the solution is to pass close_fds=True. All simple and obvious in hindsight, but still managed to cost at least a couple eyeballs good chunks of time.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11226>
_______________________________________

From report at bugs.python.org  Mon Feb 21 02:51:05 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 21 Feb 2011 01:51:05 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <20110221015054.GA4234@kevin>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Feb 20, 2011 at 10:07:31PM +0000, David Phillips wrote:

> The following code works on python 3.1.3 but fails on Python 3.2rc2
> (r32rc2:88269, Jan 30 2011, 14:30:28). (I run Mac OS X, version
> 10.6.6.)

Is that a real world code? (As in used in production)?  Because,
things have been a bit tightened in 3.2 and it expects data to be
bytes and throws an exception if it is not bytes.

urlencode will output str and you have explicitly encode it to bytes
(Using the value Accept-Encoding response header) before you send the
data to urlopen. The updated docs reflect this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Mon Feb 21 03:28:15 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 21 Feb 2011 02:28:15 +0000
Subject: [issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1298255295.65.0.557441408826.issue11224@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Lars, the attached patch fixes the issue. I'll add this to ActivePython 3.2. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11224>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:17:54 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Mon, 21 Feb 2011 03:17:54 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298258274.21.0.0434914072576.issue11252@psf.upfronthosting.co.za>


Suresh Kalkunte <sskalkunte at gmail.com> added the comment:

If the defect was with the script, the failure to bypass the '\' notation would have to be true on Redhat Linux. Since build.conf with '\' notation gets parsed without errors on Redhat Linux, I am under the impression the parsing performed by Python on Win32 recognizes '\' as a legitimate file token resulting in the script to fail.

In summary, I view semantics of '\' being different in Win32 vs. Linux as an inconsistency and hence thought it to be a possible defect in Python. However, if Python scripts do not guarantee platform independence, i.e, one's scripts need to be cognizant of platform idiosyncrasy, then, I believe it is not a bug in Python.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:18:05 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 03:18:05 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298258285.71.0.550412991899.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> > > With your patch, "%.200s" truncates the input string to 200 *characters*, but I think that it should truncate to 200 *bytes*, as printf does.
> > 
> > Sorry, I don't understand. The result of PyUnicode_FromFormatV() is a unicode object. Then how to truncate to 200 *bytes*?

> You can truncate the input char* on the call to PyUnicode_DecodeUTF8:
pass a size smaller than strlen(s).


Now I wonder how should we treat precision formatters of '%s'. First of all, the PyUnicode_FromFormat() should behave like C printf(). In C printf(), the precision formatter of %s is to specify a maximum width of the displayed result. If final result is longer than that value, it must be truncated. That means the precision is applied on the final result. While python's PyUnicode_FromFormat() is to produce unicode strings, so the width and precision formatter should be applied on the final unicode string result. And the format stage is split into two ones, one is converting each paramater to an unicode string, another one is to put the width and precision formatters on them. So I wonder if we should apply the precision formatter on the converting stage, that is, to PyUnicode_DecodeUTF8(). So in my opinion precision should not be applied to input chars, but output unicodes.

I hope I didn't misunderstand something.

So haypo, what's your opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Mon Feb 21 04:49:28 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 03:49:28 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1298260168.45.0.226843974537.issue7330@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20739/issue_7330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7330>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:21:12 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 21 Feb 2011 04:21:12 +0000
Subject: [issue11264] Format Specification Mini-Language missing type 'i'?
In-Reply-To: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>
Message-ID: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>


New submission from Matt Joiner <anacrolix at gmail.com>:

The Format Specification Mini-Language is missing type 'i', generally the same as 'd', and ubiquitous in the libraries from which the specification is derived. See the 'd,i' conversion specifier in C: http://linux.die.net/man/3/printf, and the Old String Formatting Operations: http://docs.python.org/dev/py3k/library/stdtypes.html#old-string-formatting-operations.

>>> '{:d}'.format(3)
'3'
>>> '{:i}'.format(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'i' for object of type 'int'

----------
components: Interpreter Core
messages: 128934
nosy: anacrolix
priority: normal
severity: normal
status: open
title: Format Specification Mini-Language missing type 'i'?
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11264>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:23:49 2011
From: report at bugs.python.org (David Phillips)
Date: Mon, 21 Feb 2011 04:23:49 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298262229.27.0.0494632803503.issue11261@psf.upfronthosting.co.za>


David Phillips <david.193.phillips at gmail.com> added the comment:

Converting the type of my variable "form" from string to bytes did, indeed, allow the code to run, but I have to wonder about changing the inputs to urlopen like this. 

The 3.1.3 docs call for the data parameter to be string, and I presume that has been the case all along. Changing the data parameter from string to bytes may be a relatively clean change to make, but this change is going to break a lot of existing code. Are you sure you want to do that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:44:57 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 04:44:57 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298263497.73.0.51350976502.issue11257@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

--- asyncore.py	2010-09-15 22:18:21.000000000 +0600
+++ asyncore.py	2011-02-21 09:43:15.033839614 +0500
@@ -58,7 +58,7 @@
 try:
     socket_map
 except NameError:
-    socket_map = {}
+    socket_map = weakref.WeakValueDictionary()
 
 def _strerror(err):
     try:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:46:20 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 04:46:20 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298263580.33.0.643349602948.issue11257@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

sorry, forgot 
"import weakref"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Mon Feb 21 05:56:59 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 04:56:59 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298264219.69.0.732931273804.issue11259@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

asynchat.py: class async_chat: handle_read():
-----------------------
            elif isinstance(terminator, int) or isinstance(terminator, long):
                # numeric terminator
                n = terminator
                if lb < n:
                    self.collect_incoming_data (self.ac_in_buffer)
                    self.ac_in_buffer = ''
                    self.terminator = self.terminator - lb
                else:
                    self.collect_incoming_data (self.ac_in_buffer[:n])
                    self.ac_in_buffer = self.ac_in_buffer[n:]
                    self.terminator = 0
                    self.found_terminator()
------------------------------
suppose, terminator is -10. "if lb < n" never match. So, "else" branch executed.
next, it will call "self.collect_incoming_data (self.ac_in_buffer[:n])", to push data to user. It should push some data from beginning of the buffer, intead of this, total buffer except last 10  characters pushed.

Moreover, "self.ac_in_buffer = self.ac_in_buffer[n:]" shoudl give tail of the buffer, ut instead of this, "self.ac_in_buffer" will contain part of the tail.

Such behaviour may break protocol parsing. In my case, malicious user pass 'Content-Length: -100' and totally break protocol parsing. Crafted values may gain memory leak.

In any way, author of this code does not thought about negative n in constructions [:n] or [n:].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:18:52 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:18:52 +0000
Subject: [issue11265] asyncore does not check for EAGAIN errno
In-Reply-To: <1298265532.74.0.854480048578.issue11265@psf.upfronthosting.co.za>
Message-ID: <1298265532.74.0.854480048578.issue11265@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

According to man:
----------------------
ERRORS
       EAGAIN or EWOULDBLOCK
The socket is marked nonblocking and no connections are present to be accepted.  POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities.
-----------------

patch included

----------
components: Library (Lib)
files: z.patch
keywords: patch
messages: 128939
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not check for EAGAIN errno
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20817/z.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11265>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:19:14 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:19:14 +0000
Subject: [issue11265] asyncore does not check for EAGAIN errno
In-Reply-To: <1298265532.74.0.854480048578.issue11265@psf.upfronthosting.co.za>
Message-ID: <1298265554.0.0.747545837635.issue11265@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11265>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:31:31 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:31:31 +0000
Subject: [issue11266] asyncore does not handle EINTR in recv, send, connect,
	accept, 
In-Reply-To: <1298266290.98.0.867769013141.issue11266@psf.upfronthosting.co.za>
Message-ID: <1298266290.98.0.867769013141.issue11266@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

in spite of usage of non-blocking IO, syscalls may return EINTR if signal arrive during some syscalls.

It is desirable to re-call syscall after receiving EINTR. Trivial loops should be implemented around (recv, send, connect, accept)

----------
components: Library (Lib)
messages: 128940
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not handle EINTR in recv, send, connect, accept,
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11266>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:41:19 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:41:19 +0000
Subject: [issue10867] mmap.flush() issue msync() even if mapping was created
	with prot=mmap.PROT_READ only
In-Reply-To: <1294489230.48.0.811640987738.issue10867@psf.upfronthosting.co.za>
Message-ID: <1298266879.23.0.652899333932.issue10867@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10867>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:50:40 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 05:50:40 +0000
Subject: [issue11263] Wrong link to source code of ftplib
In-Reply-To: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>
Message-ID: <1298267440.04.0.159838318675.issue11263@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11263>
_______________________________________

From report at bugs.python.org  Mon Feb 21 06:54:32 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 05:54:32 +0000
Subject: [issue11267] asyncore does not check for POLLERR and POLLHUP if
	neither readable nor writable
In-Reply-To: <1298267672.06.0.624805045141.issue11267@psf.upfronthosting.co.za>
Message-ID: <1298267672.06.0.624805045141.issue11267@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

asyncore.py: poll2() :
--------------------
if flags:
    # Only check for exceptions if object was either readable
    # or writable.
    flags |= select.POLLERR | select.POLLHUP | select.POLLNVAL
    pollster.register(fd, flags)
--------------------

This is unexpected behaviour. Why descriptor does not get polled if neither read nor write selected ? So I can not track dropping of connection if I do not want neither read nor write. I think "if flags:" should be removed.

----------
components: IO, Library (Lib)
messages: 128941
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not check for POLLERR and POLLHUP if neither readable nor writable
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11267>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:36:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 06:36:03 +0000
Subject: [issue11268] Mac OS/X installer fails if documentation was previously
	installed.
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

The 3.2.0 install failed at the documentation step.  I believe this happened because I had already install the release candidate beforehand, so it looks like on of the steps is not checking for existing files.

----------
assignee: ned.deily
components: Installation
messages: 128942
nosy: ned.deily, rhettinger
priority: normal
severity: normal
status: open
title: Mac OS/X installer fails if documentation was previously installed.
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11268>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:55:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Feb 2011 06:55:54 +0000
Subject: [issue11264] Format Specification Mini-Language missing type 'i'?
In-Reply-To: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>
Message-ID: <1298271354.75.0.31998045591.issue11264@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

IMO the new format language was quite right to do away with redundant specifiers, since "d" and "i" are completely equivalent.

----------
assignee:  -> eric.smith
nosy: +eric.smith, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11264>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:58:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Feb 2011 06:58:10 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298271490.04.0.154909357462.issue11261@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Quite a few docs still say "string" where in fact bytes are expected in Python 3.x; we're updating these as we go along.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Mon Feb 21 07:58:16 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Feb 2011 06:58:16 +0000
Subject: [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <1298271496.67.0.809551144202.issue11261@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
type: crash -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11261>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:00:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Feb 2011 07:00:49 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298271649.58.0.890197135347.issue11252@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:21:45 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 07:21:45 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298272905.81.0.421673704846.issue11246@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Yes. The %V should be combination of %U and %s.

Here is a patch which fixed this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:22:33 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 07:22:33 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298272953.29.0.607587808451.issue11246@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20818/issue11246.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:25:02 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Feb 2011 07:25:02 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1298273102.47.0.0522093432297.issue11200@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Toshio: yeah go ahead and add one, and let's do this asap in Distribute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Mon Feb 21 08:43:07 2011
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 21 Feb 2011 07:43:07 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1298274187.45.0.375326462066.issue11200@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Also, let's keep this open/valid for Distutils2

----------
components: +Distutils2 -Library (Lib)
nosy: +alexis, eric.araujo
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:08:24 2011
From: report at bugs.python.org (Matt Joiner)
Date: Mon, 21 Feb 2011 09:08:24 +0000
Subject: [issue11264] Format Specification Mini-Language missing type 'i'?
In-Reply-To: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>
Message-ID: <1298279304.76.0.491177257627.issue11264@psf.upfronthosting.co.za>


Matt Joiner <anacrolix at gmail.com> added the comment:

Is there any reason 'd' was chosen over 'i'? Is there a more appropriate place I can find this out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11264>
_______________________________________

From report at bugs.python.org  Mon Feb 21 10:47:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 09:47:31 +0000
Subject: [issue11268] 3.2 Mac OS X installer may fail if documentation was
	previously installed
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298281651.82.0.7121412008.issue11268@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If a version of Python 3.2 has been previously installed, a subsequent re-install of Python 3.2 may fail attempting to install the Documentation package.  On Mac OS X 10.6, the message reported by the installer is:

"The following installation step failed: run postflight script for Python Documentation.  Contact the software manufacturer for assistance."

Avoid the problem by dragging the folder /Library/Frameworks/Python/Versions/3.2/share to the Trash (you may be asked to enter an administrator password to do so) or, equivalently, run the following from a command line shell:

  sudo rm -rf /Library/Frameworks/Python.framework/Versions/3.2/share

Then re-run the installer to ensure that all installation steps have been completed.

----------
stage:  -> needs patch
title: Mac OS/X installer fails if documentation was previously installed. -> 3.2 Mac OS X installer may fail if documentation was previously installed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11268>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:18:23 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Mon, 21 Feb 2011 10:18:23 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>


New submission from Sergey Schetinin <sergey at maluke.com>:

Tested on Python 2.7, but probably affects all versions. Test case is attached.

The reason this went unnoticed until now is that browsers are very conservative when quoting field names, so most field names are the same after their quoting.

Related bug in WebOb: https://bitbucket.org/ianb/webob/issue/2

----------
components: Library (Lib)
files: tcgi.py
messages: 128950
nosy: mlk
priority: normal
severity: normal
status: open
title: cgi.FieldStorage forgets to unquote field names when parsing multipart/form-data
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20819/tcgi.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:31:24 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Mon, 21 Feb 2011 10:31:24 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298284284.68.0.762431592119.issue11269@psf.upfronthosting.co.za>


Sergey Schetinin <sergey at maluke.com> added the comment:

And here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file20820/cgi-patch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Mon Feb 21 11:41:27 2011
From: report at bugs.python.org (Barry Scott)
Date: Mon, 21 Feb 2011 10:41:27 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298284887.86.0.612393477886.issue7291@psf.upfronthosting.co.za>


Barry Scott <barry.scott at onelan.co.uk> added the comment:

The attached patch builds on Mike's work.

The core of the problem is that the Request object
did not know what was going on. This means that it
was not possible for get_authorization() to work
for proxy-auth and www-auth.

I change Request to know which of the four types of
connection it represents. There are new methods on
Request that return the right information based on
the connection type.

To understand how to make this work I needed to
instrument the code. There is now a set_debuglevel
on the OpenerDirector object that turns on debug in
all the handlers and the director. I have added
more debug messages to help understand this code.

This code now passes the 72 test cases I run. I'll
attach the code I used to test as a follow up to this.

----------
nosy: +b.a.scott
Added file: http://bugs.python.org/file20821/http_proxy_https.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:04:57 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 11:04:57 +0000
Subject: [issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl
	8.5.9 (Cocoa)
In-Reply-To: <1292765395.17.0.260810328922.issue10736@psf.upfronthosting.co.za>
Message-ID: <1298286297.75.0.101357954358.issue10736@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
priority: critical -> high
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10736>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:09:43 2011
From: report at bugs.python.org (Barry Scott)
Date: Mon, 21 Feb 2011 11:09:43 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298286583.01.0.742707828819.issue7291@psf.upfronthosting.co.za>


Barry Scott <barry.scott at onelan.co.uk> added the comment:

Attached is the code I used to test these changes.
See the README.txt file for details include
the results of a test run.

----------
Added file: http://bugs.python.org/file20822/urllib2_tests.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:15:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 11:15:37 +0000
Subject: [issue11268] 3.2 Mac OS X installer may fail if documentation was
	previously installed
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298286937.6.0.930716803147.issue11268@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patch corrects the problem in the installer.  I'll apply it after py3k is re-opened.

----------
keywords: +patch
stage: needs patch -> commit review
versions: +Python 2.7
Added file: http://bugs.python.org/file20823/issue11268_installer_doc_abort.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11268>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:19:23 2011
From: report at bugs.python.org (Barry Scott)
Date: Mon, 21 Feb 2011 11:19:23 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298287163.98.0.710878757946.issue7291@psf.upfronthosting.co.za>


Barry Scott <barry.scott at onelan.co.uk> added the comment:

I left out some white space changes to match the style
of the std lib code. Re posting with white space cleanup.

----------
Added file: http://bugs.python.org/file20824/http_proxy_https.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:19:31 2011
From: report at bugs.python.org (Barry Scott)
Date: Mon, 21 Feb 2011 11:19:31 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1298287171.29.0.964078257851.issue7291@psf.upfronthosting.co.za>


Changes by Barry Scott <barry.scott at onelan.co.uk>:


Removed file: http://bugs.python.org/file20821/http_proxy_https.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:24:14 2011
From: report at bugs.python.org (Eric Smith)
Date: Mon, 21 Feb 2011 11:24:14 +0000
Subject: [issue11264] Format Specification Mini-Language missing type 'i'?
In-Reply-To: <1298262072.63.0.92596842133.issue11264@psf.upfronthosting.co.za>
Message-ID: <1298287454.75.0.451890960577.issue11264@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It would be redundant, so we don't need both. I don't recall any discussion when PEP 3101 was developed as to choosing 'd' over 'i'. In all of the C code I've seen use printf, I don't think I've ever seen 'i' used.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11264>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:33:46 2011
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Mon, 21 Feb 2011 11:33:46 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1298288026.37.0.326549890337.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

This is not the proper place for it, but in the 3.2 and 2.7 news it is reported that ?The multi-argument form of operator.attrgetter() function now runs slightly faster? while it should be ?The multi-argument form of operator.attrgetter() function now runs slightly faster and the single-argument form runs much faster?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:33:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 11:33:51 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1298288031.68.0.087280005101.issue11184@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> georg.brandl
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Mon Feb 21 12:36:18 2011
From: report at bugs.python.org (Michael Foord)
Date: Mon, 21 Feb 2011 11:36:18 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1298288178.57.0.753216281337.issue11133@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

__dict__ as a property is documented as an exception to the "no code execution" claim.

The patch is not sufficient - instances may have a class member "__dict__" whilst still having an instance __dict__. Alternatively the "__dict__" property may be provided by a base class and so not available in "type(obj).__dict__" but still be provided by a property.

I don't think there is any general way to tell whether fetching obj.__dict__ will get an instance dictionary or fetch a "__dict__" member from the class or a base-class... (Hence the documented exception.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11133>
_______________________________________

From report at bugs.python.org  Mon Feb 21 13:36:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 12:36:18 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1298291778.58.0.32209421585.issue10276@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch looks good to me.

----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10276>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:20:18 2011
From: report at bugs.python.org (Andreas Sauer)
Date: Mon, 21 Feb 2011 13:20:18 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>


New submission from Andreas Sauer <sauerandreas at gmx.de>:

Module: logging
OS: Windows XP

When using the RotatingFileHandler, the logging cras when i open the Logfile in an Texteditor.

I think there is a Problem in renaming the Files, while it's open in the Texteditor.

Traceback (most recent call last):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 76, in emit
    if self.shouldRollover(record):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 150, in shouldRollo
ver
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file

----------
components: Extension Modules
messages: 128960
nosy: RockstarVC
priority: normal
severity: normal
status: open
title: logging: RotatingFileHandler crash when opening the Logfile in an Texteditor
type: crash
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11270>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:30:40 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 13:30:40 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1298295040.2.0.697396816015.issue10829@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Hi, haypo, Your patch seems cannot be applied cleanly on current py3k trunk. And after modified your patch, test_unicode.py runs into Segmentation fault. Is there something wrong or some changes which could influence this bug had been already made since the patch is worked out?


On the current trunk, I guess the bug could be fixed in a simpler way:

In step 1, before check '%%', check '%'(a string ends with '%') first. Then check '%%' and skip it.

The whole patch:

Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c	(revision 88453)
+++ Objects/unicodeobject.c	(working copy)
@@ -750,8 +750,12 @@
      * result in an array) */
     for (f = format; *f; f++) {
          if (*f == '%') {
-             if (*(f+1)=='%')
+             if (*(f+1)=='\0')
+                continue;
+             if (*(f+1)=='%') {
+                 f++;
                  continue;
+             }
              if (*(f+1)=='S' || *(f+1)=='R' || *(f+1)=='A')
                  ++callcount;
              while (Py_ISDIGIT((unsigned)*f))


After applying this small patch and tests in your patch, test_unicode.py can passed.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:31:33 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 13:31:33 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1298295093.09.0.361508886572.issue10829@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Mon Feb 21 14:34:04 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 21 Feb 2011 13:34:04 +0000
Subject: [issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary
	limit of 500 bytes is outdated
In-Reply-To: <1294196554.94.0.785505480291.issue10833@psf.upfronthosting.co.za>
Message-ID: <1298295244.96.0.242680252047.issue10833@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

see also #7330, I'm implementing "%.100s" in that issue.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10833>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:04:49 2011
From: report at bugs.python.org (Tobias Brink)
Date: Mon, 21 Feb 2011 15:04:49 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than
	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>


New submission from Tobias Brink <tobias.brink at gmail.com>:

I tested the new concurrent.futures.ProcessPoolExecutor.map() in 3.2 with the is_prime() function from the documentation example. This was significantly slower than using multiprocessing.Pool.map(). Quick look at the source showed that multiprocessing sends the iterable in chunks to the worker process while futures sends always only one entry of the iterable to the worker.

Functions like is_prime() which finish relatively fast make the communication overhead (at least I guess that is the culprit) very big in comparison.

Attached is a file which demonstrates the problem and a quick workaround.  The workaround uses the chunk idea from multiprocessing.  The problem is that it requires the iterables passed to map() to have a length and be indexable with a slice.  I believe this limitation could be worked around.

----------
components: Library (Lib)
files: map_comparison.py
messages: 128963
nosy: tbrink
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor.map() slower than multiprocessing.Pool.map() for fast function argument
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file20825/map_comparison.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11271>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:48:24 2011
From: report at bugs.python.org (Duncan Booth)
Date: Mon, 21 Feb 2011 15:48:24 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>


New submission from Duncan Booth <kupuguy at gmail.com>:

In Python 3.2, the builtin function `input()` returns a string with a trailing '\r' on windows:

    C:\Python32>python
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(repr(input()))
    test
    'test\r'
    >>>

This breaks code that expects the string to be stripped, e.g. 'pydoc.py -b' doesn't recognise its commands:

    C:\Python32>python lib\pydoc.py -b
    Server ready at http://localhost:4680/
    Server commands: [b]rowser, [q]uit
    server> q
    Server commands: [b]rowser, [q]uit
    server> b
    Server commands: [b]rowser, [q]uit
    server>

----------
components: Interpreter Core, Windows
messages: 128964
nosy: duncanb
priority: normal
severity: normal
status: open
title: input() has trailing carriage return on windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:49:23 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 15:49:23 +0000
Subject: [issue11273] asyncore creates selec (or poll) on every iteration
In-Reply-To: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za>
Message-ID: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

select.poll() object or r,w,e arrays for select() should not be built from the start in each iteration.

For performance issue, such objects should be created in loop() function and modified in add_channel/del_channel. As we do not know, what type of event loop (select or poll) will be choosed, we must either build both (bad performance anyway) or create new class:

1. new class a-la "poller" should be created, accepting "map" and "use_poll" parameters. poll() should be moved to poller.poll()
2. The "dispatcher" class should accept "poller" as parameter (not just "map")
3. "add_channel" and "del_channel" should add/remove items in "poller" (select.poll.modify or list.remove for r,w,e)
4. "poller" should have weakref to each controlled "dispatcher" just for unregistering dead dispatchers via weakref callback.

I can create a patch, but will not start until someone approve my idea.

----------
components: Library (Lib)
messages: 128965
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore creates selec (or poll) on every iteration
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11273>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:50:44 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 15:50:44 +0000
Subject: [issue11274] asyncore does not support epoll
In-Reply-To: <1298303444.27.0.804622018325.issue11274@psf.upfronthosting.co.za>
Message-ID: <1298303444.27.0.804622018325.issue11274@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

epoll support should be added. Big performance boost on large number of sockets.

----------
components: Library (Lib)
messages: 128966
nosy: mmarkk
priority: normal
severity: normal
status: open
title: asyncore does not support epoll
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11274>
_______________________________________

From report at bugs.python.org  Mon Feb 21 16:54:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Feb 2011 15:54:25 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298303665.67.0.592534671141.issue11272@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:10:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Feb 2011 16:10:16 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298304616.96.0.130959034528.issue11272@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed on Python 3.2 (winxp). The problem doesn't seem to exist on 3.1.3.

----------
priority: normal -> critical
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:10:44 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Feb 2011 16:10:44 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298304644.34.0.811535657052.issue11272@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:18:42 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Feb 2011 16:18:42 +0000
Subject: [issue11274] asyncore does not support epoll
In-Reply-To: <1298303444.27.0.804622018325.issue11274@psf.upfronthosting.co.za>
Message-ID: <1298305122.77.0.340920638057.issue11274@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

This is not easy to do. See:
http://bugs.python.org/issue6692
Closing out as duplicate.

----------
nosy: +giampaolo.rodola
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11274>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:20:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Feb 2011 16:20:15 +0000
Subject: [issue11273] asyncore creates selec (or poll) on every iteration
In-Reply-To: <1298303363.56.0.939143119689.issue11273@psf.upfronthosting.co.za>
Message-ID: <1298305215.48.0.332781733752.issue11273@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11273>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:27:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Feb 2011 16:27:18 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298305638.16.0.993206684937.issue11257@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'd be fine with this. My only concern are performances.
I've tried this:
http://code.google.com/p/pyftpdlib/issues/attachmentText?id=152&aid=-7106494857544071944&name=bench.py&token=bd350bbd6909c7c2a70da55db15d24ed

Results:

plain dict: 722.26 Mb/sec
WeakValueDictionary: 659.76 Mb/sec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:41:22 2011
From: report at bugs.python.org (Tobias Brink)
Date: Mon, 21 Feb 2011 16:41:22 +0000
Subject: [issue11271] concurrent.futures.ProcessPoolExecutor.map() slower than
	multiprocessing.Pool.map() for fast function argument
In-Reply-To: <1298300689.71.0.822605356721.issue11271@psf.upfronthosting.co.za>
Message-ID: <1298306482.98.0.379150916058.issue11271@psf.upfronthosting.co.za>


Tobias Brink <tobias.brink at gmail.com> added the comment:

Playing around a bit I wrote the attached implementation which works with all iterables.

----------
Added file: http://bugs.python.org/file20826/new_processpoolexecutor.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11271>
_______________________________________

From report at bugs.python.org  Mon Feb 21 17:49:41 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 21 Feb 2011 16:49:41 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298306981.39.0.185622166154.issue11272@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

On WinXp with Python 3.2a4+ or 3.1.3 I cannot reproduce this issue.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:05:15 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 21 Feb 2011 17:05:15 +0000
Subject: [issue6692] asyncore kqueue support
In-Reply-To: <1250127249.77.0.440620100529.issue6692@psf.upfronthosting.co.za>
Message-ID: <1298307915.22.0.894730081352.issue6692@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6692>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:10:58 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 21 Feb 2011 17:10:58 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298308258.8.0.333557483675.issue11272@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

With py3.2 final, I can reproduce this bug with command line (as demonstrated by the OP) but not with the IDLE (for 3.2a4+ I have only command line, which I compiled myself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:13:18 2011
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 21 Feb 2011 17:13:18 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298308398.5.0.0803849738039.issue11272@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

#10841 may be related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:14:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Feb 2011 17:14:45 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298308485.8.0.772940291116.issue11272@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou, v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:30:15 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 21 Feb 2011 17:30:15 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298309415.6.0.917850693818.issue11272@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 18:54:39 2011
From: report at bugs.python.org (Hoyt Koepke)
Date: Mon, 21 Feb 2011 17:54:39 +0000
Subject: [issue11275] Linking to gcc's gomp causes crash later.
In-Reply-To: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>
Message-ID: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>


New submission from Hoyt Koepke <hoytak at gmail.com>:

Hello,

I've encountered a strange bug that appears to be either in gcc's gomp
implementation or in how python loads extension modules linked against
gomp.  Here's the error:

Using gcc (multiple versions) on linux, I compile an empty c extension
module and pass -lgomp as a linker arg.  If I import it, running a
simple script in matplotlib causes a segfault.  Not passing -lgomp or
not loading the empty module makes the code works fine.  More
specifically, if I compile:

#include "Python.h"
static struct PyMethodDef methods[] = {
 {0, 0, 0, 0}
};
PyMODINIT_FUNC initempty(void) {
 Py_InitModule4("empty", methods, 0, 0, PYTHON_API_VERSION);
}

using ``ext_modules = [Extension("empty", ["empty.c"], extra_link_args
= ["-lgomp"])]``, then

import empty
import matplotlib.pylab as plt

plt.figure()
plt.plot([0,1], [0,1], '-b')
plt.show()


causes the program to segfault (removing ``import empty`` makes it
fine).  Looking at a traceback:

#0  0x00f78bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x008f51f2 in py_to_agg_transformation_matrix (obj=0x8223f58,
errors=false) at src/agg_py_transforms.cpp:20
#2  0x008fdd73 in _path_module::update_path_extents (this=0x8e45f90,
args=...) at src/path.cpp:378
#3  0x009048bd in
Py::ExtensionModule<_path_module>::invoke_method_varargs (this=<value
optimized out>, method_def=0x8e9ae30, args=...) at
./CXX/Python2/ExtensionModule.hxx:184
#4  0x008f0d96 in method_varargs_call_handler
(_self_and_name_tuple=0x8e6eeac, _args=0x94e683c) at
CXX/Python2/cxx_extensions.cxx:1714
#5  0x080dc0d0 in PyEval_EvalFrameEx ()
#6  0x080dddf2 in PyEval_EvalCodeEx ()

While occurring in some of matplotlib's extension code (and I haven't
found another library that crashes it), the fact that the deciding
factor is whether I link against gomp indicates the it's probably
upstream somewhere.

I encountered this error a year ago and asked about it on the
matplotlib mailing list, but found a quick workaround then, and with
deadline pressure I forgot about it.  However, it's come up again, and
then I was asked to bump it to python-dev, which is why I'm posting it
here.

I can reproduce it on the following systems.  In all cases, matplotlib
is compiled from source on the development branch (r8969) and uses
QT4Agg as the backend, as is numpy, scipy, etc.  If needed, I can
track down more versions.

gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.4, 64bit, Python 2.6.6, ubuntu 10.10
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64bit, Python 2.6.5, ubuntu 10.04
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, 32bit, Python 2.6.4, ubuntu 9.10

gcc 4.5.2 (source build), Python 2.6.5, ubuntu 10.04.  On this build,
the given source example does not produce the result, and I haven't
been able to tweak it so it does.  However, linking to a much larger
extension library that uses many different parts of openmp causes
exactly the same crash.  If I recompile that library without openmp
support, then everything works fine; with openmp support it corrupts
something and matplotlib crashes in exactly the same way.

gcc 4.3.2, Python 2.6.2, ubuntu 9.04 (I don't have access to this
system any more, since it got upgraded, but it had the same problem a
year ago).

I attached example code that reproduces it.  

Thanks,

--Hoyt

----------
components: Extension Modules
files: python-gomp-bug.tar.gz
messages: 128974
nosy: hoytak
priority: normal
severity: normal
status: open
title: Linking to gcc's gomp causes crash later.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file20827/python-gomp-bug.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11275>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:07:19 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 21 Feb 2011 18:07:19 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298311639.41.0.636292540624.issue11272@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
keywords: +3.2regression

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:26:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 18:26:30 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1298312790.84.0.471616209476.issue8650@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Fixed by r87729.

This only addresses the compress() and decompress() functions, but e.g. crc32() and adler32() are also touched by this issue.

----------
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:26:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 18:26:45 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1298312805.62.0.0740061714076.issue8651@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Fixed by r87728.

This only addresses the compress() and decompress() functions, but e.g. crc32() and adler32() are also touched by this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:28:06 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 18:28:06 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1298312886.65.0.0302984687233.issue10276@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the patch! Committed in r88460 (3.3) and r88461 (3.2).
2.7 would need more surgery in order for this to be fixed, see #8651 and #8650.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10276>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:44:37 2011
From: report at bugs.python.org (rg3)
Date: Mon, 21 Feb 2011 18:44:37 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298313877.36.0.872801947959.issue11199@psf.upfronthosting.co.za>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

That makes sense and explains why the problem could not be reproduced over the loopback (the transfer would be too fast).

I have not tested the patch, but I can reproduce the problem with a local connection if I compile pure-ftpd with the --with-throttling switch and limit the bandwidth to 1 KB/sec, using the -t option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:48:49 2011
From: report at bugs.python.org (Michael Schurter)
Date: Mon, 21 Feb 2011 18:48:49 +0000
Subject: [issue8407] expose signalfd(2) and sigprocmask(2) in the signal module
In-Reply-To: <1271307639.03.0.656473126494.issue8407@psf.upfronthosting.co.za>
Message-ID: <1298314129.43.0.640841281998.issue8407@psf.upfronthosting.co.za>


Michael Schurter <m at schmichael.com> added the comment:

Any hopes of getting this into Python 3.3?

----------
nosy: +schmichael
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8407>
_______________________________________

From report at bugs.python.org  Mon Feb 21 19:58:55 2011
From: report at bugs.python.org (rg3)
Date: Mon, 21 Feb 2011 18:58:55 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298314735.78.0.605946450178.issue11199@psf.upfronthosting.co.za>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

I just tested the patch under Python 2.6. It doesn't seem to solve the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:19:02 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 21 Feb 2011 19:19:02 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1298315942.59.0.994049517108.issue8651@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:19:11 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 21 Feb 2011 19:19:11 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1298315951.1.0.381482063335.issue8650@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:20:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 19:20:29 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298316029.16.0.682090234906.issue11272@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Confirmed on Python 3.2 (winxp).
> The problem doesn't seem to exist on 3.1.3.

Can you try Python 3.1 with -u command line flag?

I changed Python 3.2 to always open all files in binary module, not only if -u flag is used. I had also to fix the parser to support \r\n newlines: it looks like I missed something in the parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:26:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 19:26:19 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1298316379.76.0.529196863121.issue8650@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg128975

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:27:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 19:27:13 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1298316433.5.0.181747393748.issue8651@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
Removed message: http://bugs.python.org/msg128976

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:27:30 2011
From: report at bugs.python.org (SilentGhost)
Date: Mon, 21 Feb 2011 19:27:30 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298316450.26.0.284678197837.issue11272@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

> Can you try Python 3.1 with -u command line flag?
Yes, I can reproduce it with 3.1.3 with -u flag

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:27:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 19:27:38 +0000
Subject: [issue8651] "s#" and friends can silently truncate buffer length
In-Reply-To: <1273253096.48.0.301498355728.issue8651@psf.upfronthosting.co.za>
Message-ID: <1298316458.45.0.245889581216.issue8651@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I removed Antoine's message because it was related to issue #8650.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8651>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:28:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 19:28:24 +0000
Subject: [issue8650] zlibmodule.c isn't 64-bit clean
In-Reply-To: <1273252861.66.0.962857738541.issue8650@psf.upfronthosting.co.za>
Message-ID: <1298316504.49.0.687632096881.issue8650@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Woops, I removed a duplicate message of Antoine. in this issue instead of #8651. Removed message:
-----
> Fixed by r87729.

This only addresses the compress() and decompress() functions, but e.g. crc32() and adler32() are also touched by this issue.
-----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8650>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:31:31 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 21 Feb 2011 19:31:31 +0000
Subject: [issue10990] tests mutating sys.gettrace() w/o re-instating previous
	state
In-Reply-To: <1295824876.68.0.687534068337.issue10990@psf.upfronthosting.co.za>
Message-ID: <1298316691.74.0.542336177049.issue10990@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r88467 has it for 3.3.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10990>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:43:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 19:43:04 +0000
Subject: [issue11089] ConfigParser 50x slower in 2.7
In-Reply-To: <1296569082.9.0.874258670374.issue11089@psf.upfronthosting.co.za>
Message-ID: <1298317384.29.0.864643844211.issue11089@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r88469 and r88470.

----------
resolution: later -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11089>
_______________________________________

From report at bugs.python.org  Mon Feb 21 20:59:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 19:59:00 +0000
Subject: [issue11263] Wrong link to source code of ftplib
In-Reply-To: <1298242930.32.0.19382495718.issue11263@psf.upfronthosting.co.za>
Message-ID: <1298318340.59.0.906331029441.issue11263@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the report.
Fixed in r88473 and r88474.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11263>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:05:25 2011
From: report at bugs.python.org (Duncan Booth)
Date: Mon, 21 Feb 2011 20:05:25 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298318725.1.0.479929580306.issue11272@psf.upfronthosting.co.za>


Duncan Booth <kupuguy at gmail.com> added the comment:

Yes, it does indeed look like stdin has been opened in binary mode. Just iterating over it also gives the spurious carriage returns:


    C:\Python32>python
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sys
    >>> for line in sys.stdin:
    ...     print(repr(line))
    ...
    hello
    'hello\r\n'
    ^Z
    >>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:17:09 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 21 Feb 2011 20:17:09 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298319429.8.0.695271712731.issue11252@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Unfortunately the bug is not in ConfigParser but rather in your gen-build.py. There is nothing special about backslashes and ConfigParser reads them in as part of the value for ldap/paths.

But then look what happens in gen-build.py:215. The `split()` returns

['ldap/apr_ldap_init.c', '\\', 'ldap/apr_ldap_option.c', '\\', 'ldap/apr_ldap_rebind.c']

and later on the `map()` in line 216 adds new elements to the list. However, on Linux `glob.glob('\\')` == `[]` so nothing is actually added. OTOH on Windows `glob.glob('\\')` == `['\\']`. This behaviour is correct. As a side note, the assert actually fails on '/' (thanks to `clean_path`).

So, the easiest fix for you is to get rid of the backslashes from the configuration file. They work on Linux by mere coincidence.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:24:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 20:24:27 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298319867.7.0.779493025849.issue11246@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+        text = PyUnicode_FromFormat(b'repr=%V', 'abcdef', b'abcdef')
+        self.assertEqual(text, 'repr=abcdef')

How do you know which argument is used? For example, you should use instead 'abc' and b'xyz'.

+        text = PyUnicode_FromFormat(b'repr=%V', None, '??????'.encode('UTF-8'))
+        self.assertEqual(text, 'repr=??????')

I prefer ASCII literals using \x or \u: '\xe4\xba\xe6\xb0\u2018'.

You should also add a test specific to the replace error handler, e.g. (None, b'abc\xff') => 'abc\ufffd'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:32:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Feb 2011 20:32:50 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ cat test.py
import cPickle
cPickle
cPickle.load
$ 2to3 -f imports test.py
RefactoringTool: Refactored test.py
--- test.py     (original)
+++ test.py     (refactored)
@@ -1,3 +1,3 @@
-import cPickle
+import pickle
 cPickle
-cPickle.load
+pickle.load
RefactoringTool: Files that need to be modified:
RefactoringTool: test.py

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 128991
nosy: Arfrever
priority: normal
severity: normal
status: open
title: 2to3: imports fixer doesn't update references to modules specified without attributes
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:47:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Feb 2011 20:47:28 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1298321248.88.0.110073373541.issue11276@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:52:45 2011
From: report at bugs.python.org (Jon McKenzie)
Date: Mon, 21 Feb 2011 20:52:45 +0000
Subject: [issue11251] cmd.Cmd tab completion treats dashes as spaces
In-Reply-To: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>
Message-ID: <1298321565.9.0.219115616441.issue11251@psf.upfronthosting.co.za>


Jon McKenzie <jcmcken at gmail.com> added the comment:

Marked as closed, since I found this was not a bug, but just a readline default.

Can set tab completion delimiters with readline.set_completer_delims(string)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11251>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:53:24 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 20:53:24 +0000
Subject: [issue11187] PyUnicode_AsEncodedString: the bootstrap hack is no more
	needed
In-Reply-To: <1297429451.12.0.801264472969.issue11187@psf.upfronthosting.co.za>
Message-ID: <1298321604.85.0.127749189297.issue11187@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r88476. I prefer to only change it in Python 3.3, so no backport.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11187>
_______________________________________

From report at bugs.python.org  Mon Feb 21 21:58:51 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 20:58:51 +0000
Subject: [issue11169] compileall doesn't support PEP 383 (undecodable
	paths/filenames)
In-Reply-To: <1297341526.6.0.0854316308475.issue11169@psf.upfronthosting.co.za>
Message-ID: <1298321931.25.0.132148730888.issue11169@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r88478.

> Not sure this can make it into stable branches.

I agree, I prefer to not touch stable releases.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11169>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:04:32 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 21:04:32 +0000
Subject: [issue11268] 3.2 Mac OS X installer may fail if documentation was
	previously installed
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298322272.7.0.555805935694.issue11268@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Applied in py3k (r88475), 32 (r88477) for 3.2.1, and 27 (r88479) unreleased.

----------
keywords: +3.2regression -patch
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11268>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:06:56 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 21:06:56 +0000
Subject: [issue11168] UnicodeEncodeError on recusion limit if the script
	filename is undecodable
In-Reply-To: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>
Message-ID: <1298322416.03.0.664828204418.issue11168@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r88480 removes the filename variable: use gdb7+python-gdb.py or the faulthandler module to get a Python backtrace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11168>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:07:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 21:07:21 +0000
Subject: [issue11168] UnicodeEncodeError on recusion limit if the script
	filename is undecodable
In-Reply-To: <1297340502.7.0.210225805392.issue11168@psf.upfronthosting.co.za>
Message-ID: <1298322441.08.0.537187984328.issue11168@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11168>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:24:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 21:24:27 +0000
Subject: [issue10830] PyUnicode_FromFormatV("%c") doesn't support non-BMP
	characters on narrow build
In-Reply-To: <1294191792.83.0.0600420394952.issue10830@psf.upfronthosting.co.za>
Message-ID: <1298323467.55.0.852513687559.issue10830@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in 3.3 (r88481).

Keep it open to backport it maybe to 3.2 later.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10830>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:32:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 21:32:16 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298323936.96.0.486295212559.issue11260@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for taking an interest in this and working up a patch.  Unfortunately I do have some concerns.

As far as I know the only module that currently uses argparse is compileall, which was only changed recently.

Do tests currently exist for smtpd run as a script?  If not, our experience with converting compileall to argparse indicates a thorough test suite is needed (and even so we missed some things we hadn't thought to test).

We converted compileall because its help output was broken, but in retrospect it might have been better to fix the help output in the existing code.  In other words, if the current code works, is "updating" it a sufficient reason to change it, considering the chances of introducing new bugs?  The answer might be yes, but I don't think it is obviously yes.

----------
nosy: +r.david.murray
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:32:43 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 21 Feb 2011 21:32:43 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298323963.62.0.615900421589.issue11199@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> I just tested the patch under Python 2.6. It doesn't seem to solve the problem. 

Are you sure the patch applied cleanly ?
I tested both on 3.2 and 2.7, and it fixed the problem for me.
If not, could you submit a tcpdump capture ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:50:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 21:50:01 +0000
Subject: [issue11229] Make the Mac installer more like the Windows installer
In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za>
Message-ID: <1298325001.71.0.090391372059.issue11229@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11229>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:50:49 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Feb 2011 21:50:49 +0000
Subject: [issue11268] 3.2 Mac OS X installer may fail if documentation was
	previously installed
In-Reply-To: <1298270163.78.0.234304211196.issue11268@psf.upfronthosting.co.za>
Message-ID: <1298325049.19.0.274965803376.issue11268@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks Ned :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11268>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:54:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 21:54:52 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298325292.86.0.696155913979.issue11269@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:56:09 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 21:56:09 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1298325369.62.0.68337244632.issue11270@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11270>
_______________________________________

From report at bugs.python.org  Mon Feb 21 22:59:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 21:59:11 +0000
Subject: [issue10826] pass_fds sometimes fails
In-Reply-To: <1294152290.71.0.646502628705.issue10826@psf.upfronthosting.co.za>
Message-ID: <1298325551.24.0.154045092116.issue10826@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88484 (3.x), r88485 (3.2).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10826>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:13:15 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 22:13:15 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Following r88460 (issue10276), test_zlib crashes on the Snow Leopard buildbot (apparently in the new "test_big_buffer" test case).

----------
messages: 129002
nosy: ixokai, ned.deily, pitrou
priority: critical
severity: normal
status: open
title: test_zlib crashes under Snow Leopard buildbot
type: crash
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:22:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 22:22:01 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298326921.22.0.0746193799089.issue11277@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Do adler32() and crc32() support length up to UINT32_MAX? Or should we maybe limit the length to INT32_MAX?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:22:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 22:22:55 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298326975.08.0.00316727992795.issue11277@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've tried INT_MAX and it didn't change anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:26:15 2011
From: report at bugs.python.org (rg3)
Date: Mon, 21 Feb 2011 22:26:15 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298327175.69.0.448067040097.issue11199@psf.upfronthosting.co.za>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

I have to correct myself. I applied the patch manually to my Python 2.6 installation. In Python 2.6, the line you moved is number 961, and I did the same change.

With your change, the connection can be closed, but you have to wait for the file to be completely transferred. As I was throttling to 1 KB/sec initially, I thought it was still hanging because it takes more than 1 minute for the test file to be sent. Still, the connection isn't immediately closed when you request to close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:34:20 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 22:34:20 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298327660.84.0.312221094091.issue11277@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Current OS X zlib is 1.2.3.  Test crashes with most recently released zlib, 1.2.5, as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:40:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 22:40:57 +0000
Subject: [issue11251] cmd.Cmd tab completion treats dashes as spaces
In-Reply-To: <1298162228.53.0.248175970939.issue11251@psf.upfronthosting.co.za>
Message-ID: <1298328057.71.0.625914152124.issue11251@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: wont fix -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11251>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:42:06 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 21 Feb 2011 22:42:06 +0000
Subject: [issue11270] logging: RotatingFileHandler crash when opening the
	Logfile in an Texteditor
In-Reply-To: <1298294418.47.0.778073580595.issue11270@psf.upfronthosting.co.za>
Message-ID: <1298328126.7.0.974048687018.issue11270@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't think this error can be avoided, though if you set logging.raiseExceptions to False then the exception won't be raised, though the handler won't produce any more output, either.

I don't believe this is a logging bug - you're not supposed to keep files open in the editor while you're still rotating, as the library assumes that all rotated files are under its control for deleting and renaming.

If you need different functionality, subclass the handler and implement your own handling logic to deal with open files; it's not appropriate to do this in the standard library as there's no "obvious" way to handle locking of files which are supposed to be under the library's control.

Based on the above reasoning, I'm marking this as "invalid" and "pending" to see what your response to my comment is. If I don't hear any more about this for a week or so, I'll mark this issue as closed.

----------
assignee:  -> vinay.sajip
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11270>
_______________________________________

From report at bugs.python.org  Mon Feb 21 23:44:11 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 21 Feb 2011 22:44:11 +0000
Subject: [issue11158] Python VM deadlock
In-Reply-To: <1297239951.49.0.685866204309.issue11158@psf.upfronthosting.co.za>
Message-ID: <1298328251.35.0.52717175717.issue11158@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As I've not had any response to my latest comment for over a week, I'm closing this issue, as I said I would.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11158>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:03:19 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 21 Feb 2011 23:03:19 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1298329399.08.0.320777742336.issue6784@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:15:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 23:15:53 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298330153.54.0.179125837686.issue11243@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:19:27 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Feb 2011 23:19:27 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1298330367.46.0.887345744678.issue11216@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

While your idea has merit, we can only add a parameter in a new version (not in a bug-fix release), so the doc fix is all we can do before 3.3.

----------
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:39:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 21 Feb 2011 23:39:35 +0000
Subject: [issue6137] Make pickle generated by Python 3.x compatible with 2.x
	and vice-versa.
In-Reply-To: <1243500757.52.0.733513174255.issue6137@psf.upfronthosting.co.za>
Message-ID: <1298331575.86.0.635234774135.issue6137@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6137>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:40:30 2011
From: report at bugs.python.org (Shay Rojansky)
Date: Mon, 21 Feb 2011 23:40:30 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1298331630.99.0.537451830909.issue11216@psf.upfronthosting.co.za>


Shay Rojansky <roji at roji.org> added the comment:

Thanks and no problem for me, the workaround (deleting the header) works just fine.

I'm not sure if/when the more general discussion on the package will take place (low-level vs. high-level), I would be interested in following.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:43:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Feb 2011 23:43:36 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298331816.6.0.188852578125.issue11277@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 10 at address: 0x000000010170e000
0x00000001016eeaa0 in crc32 ()

(gdb) backtrace
#0  0x00000001016eeaa0 in crc32 ()
#1  0x00000001016e806d in PyZlib_crc32 (self=0x1016aa588, args=0x1016bf220) at /private/tmp/a/py3k/Modules/zlibmodule.c:993

PyZlib_crc32(PyObject *self, PyObject *args)
...
        while (len > (size_t) UINT_MAX) {
            crc32val = crc32(crc32val, buf, UINT_MAX);
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:44:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 23:44:31 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1298331871.04.0.236607850838.issue4681@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I was a bit optimistic concerning 32-bit Windows. I had to do some changes, in part because off_t is 32-bit there. The final patch is committed in r88486 (tested under 32-bit and 64-bit Linux and Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:45:29 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 21 Feb 2011 23:45:29 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298331929.02.0.501152637843.issue11277@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:47:30 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Feb 2011 23:47:30 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1298332050.02.0.00641520097022.issue10829@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Well, the main problem is that there are 3 different codes to parse the format string, and each code is different... Attached patch factorizes the code: create one subfunction parse_format_flags(). It fixes also this issue and prepares the work to fix #10831.

----------
Added file: http://bugs.python.org/file20828/parse_format_flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 00:59:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Feb 2011 23:59:57 +0000
Subject: [issue4681] mmap offset should be off_t instead of ssize_t,
	and size calculation needs corrected
In-Reply-To: <1229503209.88.0.900633557014.issue4681@psf.upfronthosting.co.za>
Message-ID: <1298332797.68.0.759790054392.issue4681@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported in r88487 to 3.2, and in r88488 to 2.7.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4681>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:28:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Feb 2011 00:28:57 +0000
Subject: [issue11216] email.message.Message set_charset does not encode
	properly?
In-Reply-To: <1297715179.32.0.0121348193736.issue11216@psf.upfronthosting.co.za>
Message-ID: <1298334537.37.0.360390387702.issue11216@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Discussion of the new API, and what changes will be made for 3.3, will take place on the email-sig mailing list (see http://mail.python.org).  Please join!  Right now it is a dormant list, but I plan to post some stuff soon :)

The more I stare at the set_charset code and try to write out the actual algorithm in words, the buggier this looks.  If the input and output charsets differ, the body encoding is done unconditionally, but the CTE is set in that case only if the CTE header doesn't exist.

I've attached a proposed doc patch which tries to describe the actual algorithm.  If you'd care to take a look and see if you see any mistakes in my description, that would be great.  Note that you have to go down a couple of twisty passages if you want to fully understand what the set_charset code is doing.

----------
components: +Documentation
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20829/set_charset_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11216>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:44:15 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Feb 2011 00:44:15 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1298335455.4.0.824876633733.issue11085@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Followed Brett's example with importlib and made collection into a package with an abc module.  See r88490.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:47:04 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Tue, 22 Feb 2011 00:47:04 +0000
Subject: [issue11278] raw_input() and input() not stripping EOL on win32
In-Reply-To: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>
Message-ID: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>


New submission from Dave Flogeras <dflogeras2 at gmail.com>:

>From the python prompt, raw_input() (2.7.1) and input (3.2.0) behave as documented (they strip the trailing EOL chars)

However the two line test program:
x = raw_input() # or input() in 3.2.x
print( repr( x ))

And then run from the command line prompt, .\test.py, shows 'mytest\r' including the EOL char.

----------
messages: 129017
nosy: Dave.Flogeras
priority: normal
severity: normal
status: open
title: raw_input() and input() not stripping EOL on win32
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11278>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:48:02 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 22 Feb 2011 00:48:02 +0000
Subject: [issue11278] raw_input() and input() not stripping EOL on win32
In-Reply-To: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>
Message-ID: <1298335682.58.0.202989734312.issue11278@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Duplicate of #11272.

----------
nosy: +brian.curtin
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11278>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:48:26 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Tue, 22 Feb 2011 00:48:26 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298335706.74.0.331075526972.issue11269@psf.upfronthosting.co.za>


Sergey Schetinin <sergey at maluke.com> added the comment:

I've dug into the RFCs and tested various browsers.

RFC 2388 (the one defining multipart/form-data) says: 

Field names originally in non-ASCII character sets may be encoded
within the value of the "name" parameter using the standard method
described in RFC 2047.

RFC 2047 in turn defines the coding sometimes seen in email headers ("=?iso-8859-1?q?this is some text?=").

That means that this report is invalid. And I was misled by the bug that belongs to Google Chrome (which is the browser I was doing initial testing with).

I tested this with the following html form:

<form action="handle" method="POST" enctype="multipart/form-data">
<button name='"%22' type="submit" value="">Test</button>
</form>

Here are the headers submitted by various browsers:

IE 8: 
  Content-Disposition: form-data; name=""%22"
Firefox 4.0b11:
  Content-Disposition: form-data; name="\"%22"
Chrome 9:
  Content-Disposition: form-data; name="%22%22"

And the Chrome one is the one clearly invalid.

cgi still does no decoding of parameters as per RFC 2047, but browsers do not use that encoding for non-ASCII field names anyway (they just put the field names in UTF-8), so that might be unnecessary.

Please close this bug at your own judgement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:50:08 2011
From: report at bugs.python.org (Dave Flogeras)
Date: Tue, 22 Feb 2011 00:50:08 +0000
Subject: [issue11278] raw_input() and input() not stripping EOL on win32
In-Reply-To: <1298335624.95.0.787051793751.issue11278@psf.upfronthosting.co.za>
Message-ID: <1298335808.65.0.278637435521.issue11278@psf.upfronthosting.co.za>


Dave Flogeras <dflogeras2 at gmail.com> added the comment:

Ok, I'm actually not sure of what I just said.  I might not be running the version I think I am, since windows behaves differently when using a program started with extensions vs. started with python.  It might actually be that Python 2.7 is correct, but 3.2 is not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11278>
_______________________________________

From report at bugs.python.org  Tue Feb 22 01:55:44 2011
From: report at bugs.python.org (Peter Bray)
Date: Tue, 22 Feb 2011 00:55:44 +0000
Subject: [issue11279] test_posix and lack of "id -G" support - less noise
	required?
In-Reply-To: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>
Message-ID: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>


New submission from Peter Bray <pdb_ml at yahoo.com.au>:

Solaris 10's id(1M) does not support the "-G" option, so we get the following:

% ./python -m test test_posix 
[1/1] test_posix
id: illegal option -- G
Usage: id [-ap] [user]
1 test OK.

The code already tests that id -G (std) output, and assumes that id -G is not supported if the output is empty. 

QUESTION: Does the user compiling the code need to see the stderr output of id? After all the test is correctly skipped.

Fix:
% diff ./Lib/test/test_posix.py.FCS ./Lib/test/test_posix.py
378c378
<         with os.popen('id -G') as idg:
---
>         with os.popen('id -G 2> /dev/null') as idg:

Consideration: Lib/platform.py has introduced DEV_NULL but it does not seem to be used in other code or tests (beside platform.py).

Regards,

Peter

----------
components: Tests
messages: 129021
nosy: illumino
priority: normal
severity: normal
status: open
title: test_posix and lack of "id -G" support - less noise required?
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11279>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:02:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 01:02:00 +0000
Subject: [issue11279] test_posix and lack of "id -G" support - less noise
	required?
In-Reply-To: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>
Message-ID: <1298336520.04.0.930333048389.issue11279@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +jcea, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11279>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:21:47 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Feb 2011 01:21:47 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298337707.81.0.104375746255.issue11269@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for doing the research.  As far as I know we've never had a request to support RFC2047 in FieldStorage, so presumably no browsers actually generate it.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:30:52 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 01:30:52 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298338252.17.0.97961428882.issue11277@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So on my system, that 'while' loop is executed once (put a printf() after the bug and len adjustments and it was never hit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:40:41 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 22 Feb 2011 01:40:41 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1298288178.57.0.753216281337.issue11133@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=nSh2==QFw8KAPJ-ePro4--xrAic6ux=CdW6Zx@mail.gmail.com>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

> The patch is not sufficient - instances may have a class member "__dict__" whilst still having an instance __dict__.

Sure, but I don't think there is a way how you can access the instance
__dict__ in that case inside Python code. At least I can't think of
one.

>Alternatively the "__dict__" property may be provided by a base class and so not available in "type(obj).__dict__" but still be provided by a property.
>
> I don't think there is any general way to tell whether fetching obj.__dict__ will get an instance dictionary or fetch a "__dict__" member from the class or a base-class... (Hence the documented exception.)

Why not? ``obj.__dict__`` will fetch the instance dictionary iff there
is no class attribute "__dict__" in any of the base classes. In the
patch,``type.__dict__["__dict__"].__get__()`` is used to get (without
any doubt) the class dictionary. By looking inside that dictionary, we
can now tell whether "__dict__" is overwritten: If it isn't
overwritten, the dictionary either doesn't have a "__dict__" entry at
all or the value is a getset_descriptor. So we just need to iterate
over a type's mro, look inside each entries' dictionary and stop when
a "__dict__" entry is found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11133>
_______________________________________

From report at bugs.python.org  Tue Feb 22 02:42:10 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 22 Feb 2011 01:42:10 +0000
Subject: [issue11133] inspect.getattr_static code execution
In-Reply-To: <1297009822.22.0.910831968317.issue11133@psf.upfronthosting.co.za>
Message-ID: <1298338930.61.0.913167651118.issue11133@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file20830/inspect_issue_11133_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11133>
_______________________________________

From report at bugs.python.org  Tue Feb 22 03:22:29 2011
From: report at bugs.python.org (Andres Riancho)
Date: Tue, 22 Feb 2011 02:22:29 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>


New submission from Andres Riancho <andres.riancho at gmail.com>:

Buggy Code:

"""
    def http_error_302(self, req, fp, code, msg, headers):
        # Some servers (incorrectly) return multiple Location headers
        # (so probably same goes for URI).  Use first header.
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return
"""

The getheaders method is not be defined for the headers parameter, which is a dict object. This seems to be a mistake with the HTTPResponse.  getheaders function that's defined in httplib.py


Fixed Code:

"""
    def http_error_302(self, req, fp, code, msg, headers):
        # Some servers (incorrectly) return multiple Location headers
        # (so probably same goes for URI).  Use first header.
        if 'location' in headers:
            newurl = headers.get('location')
        elif 'uri' in headers:
            newurl = headers.get('uri')
        else:
            return
"""

----------
components: Extension Modules
messages: 129026
nosy: Andres.Riancho
priority: normal
severity: normal
status: open
title: urllib2 http_error_302 calls undefined "getheaders" method
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 03:42:26 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Feb 2011 02:42:26 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298342546.9.0.87821945511.issue11280@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Andres, the HTTP Response is sent the xxx_error_xxx method when it is handled by RedirectHandler. Does the below code not work for you in case? I am unable to see the problem here (and also this piece of code is present from 2004!) I am inclined to mark this request as rejected. (Please reopen if you are sure that this is wrong in specific scenarios)

----------
nosy: +orsenthil
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:04:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 03:04:39 +0000
Subject: [issue10992] tests failing when run under coverage
In-Reply-To: <1295836026.73.0.339636680883.issue10992@psf.upfronthosting.co.za>
Message-ID: <1298343879.95.0.0864667325643.issue10992@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

3.3 in r88494

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10992>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:15:38 2011
From: report at bugs.python.org (Ned Deily)
Date: Tue, 22 Feb 2011 03:15:38 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298344538.95.0.0603869415412.issue11277@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>>> from test.support import _4G
>>> _4G
4294967296
>>> mapping.size()
4294967300

pbuf.len = 4294967300, len = 4294967300
UINT_MAX = 4294967295

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:16:25 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 03:16:25 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1298344585.67.0.561628871476.issue10512@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r88496 for 3.3
r88497 for 3.2

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:34:01 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Tue, 22 Feb 2011 03:34:01 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298345641.12.0.251052932437.issue11252@psf.upfronthosting.co.za>


Suresh Kalkunte <sskalkunte at gmail.com> added the comment:

Yes, the easier fix is to change build.conf file to not use '\'. However, 

> on Linux `glob.glob('\\')` == `[]` so nothing is actually added. 
> OTOH on Windows `glob.glob('\\')` == `['\\']`

is more definite compared to

> They work on Linux by mere coincidence

----------
resolution: invalid -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:35:42 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 03:35:42 +0000
Subject: [issue11074] fix tokenize so it can be reloaded
In-Reply-To: <1296446651.43.0.796363573653.issue11074@psf.upfronthosting.co.za>
Message-ID: <1298345742.36.0.557777193721.issue11074@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r88498 for 3.3
r88499 for 3.2

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11074>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:55:17 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 03:55:17 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298346917.25.0.0134627036129.issue11246@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks haypo!

Here the updated patch, following your comments.

----------
type:  -> behavior
Added file: http://bugs.python.org/file20831/issue11246.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Tue Feb 22 04:55:46 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 03:55:46 +0000
Subject: [issue11246] PyUnicode_FromFormat("%V") decodes the byte string from
	ISO-8859-1
In-Reply-To: <1298067134.11.0.957382113163.issue11246@psf.upfronthosting.co.za>
Message-ID: <1298346946.23.0.63454613886.issue11246@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20818/issue11246.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11246>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:06:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 04:06:22 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298347582.23.0.214253039844.issue11277@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Does it matter that _4G < UINT_MAX?

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 05:10:55 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 04:10:55 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>


New submission from Paulo Scardine <paulo at scardine.com.br>:

In smtplib there is now way to bind to an specific source address on a machine with multiple interfaces; also, there no way to control the source port for the connection.

Since 2.7, socket.create_connection accepts a source_address parameter, a (host, port) tuple for the socket to bind to as its source address before connecting. If host or port are '' or 0 respectively the OS default behavior will be used.

I would like to add source_ip and source_port parameters to smtplib.SMTP, default to '' and 0 respectively.

It is a small change with no impact over existing code. Should I submit a patch?

----------
components: Library (Lib)
messages: 129035
nosy: paulos
priority: normal
severity: normal
status: open
title: smtplib: add ability to bind to specific source IP address/port
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 07:09:59 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 06:09:59 +0000
Subject: [issue11282] unittest document not keep consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

r88451:
Remove unittest methods scheduled for removal in 3.3

This commit remove assertSameElements() and assertDictContainsSubset(). But shouldn't some modification be done in the unittest library documentation? I wonder if we should remove the docs about the two methods. Now the doc only said "Deprecated since version 3.2."

----------
assignee: docs at python
components: Documentation
messages: 129036
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: unittest document not keep consist with code
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Tue Feb 22 07:30:04 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 06:30:04 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1298356204.95.0.123495018079.issue9523@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Sine r88451 removed unittest's assertSameElements() method, I need to updated my patch to fit it. So here it is.

----------
Added file: http://bugs.python.org/file20832/issue9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Tue Feb 22 07:30:42 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 06:30:42 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1298356242.19.0.360162439337.issue9523@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


Removed file: http://bugs.python.org/file20783/issue_9523.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:24:10 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 07:24:10 +0000
Subject: [issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format
	strings
In-Reply-To: <1294188403.72.0.24360709681.issue10829@psf.upfronthosting.co.za>
Message-ID: <1298359450.08.0.0476327054304.issue10829@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

> Well, the main problem is that there are 3 different codes to parse the format string, and each code is different... Attached patch factorizes the code: create one subfunction parse_format_flags(). It fixes also this issue and prepares the work to fix #10831.


Sounds nice! Maybe several related issues can also use this, like #7330.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10829>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:27:11 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Tue, 22 Feb 2011 07:27:11 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298359631.66.0.802493148363.issue11252@psf.upfronthosting.co.za>


Suresh Kalkunte <sskalkunte at gmail.com> added the comment:

lukasz.langa, confirming the difference in return values for glob.glob() on Win32/Cygwin vs. Linux as the following results show:

--------------------------------------------------------
F1()
ret_val1
     F2(ret_val1)
ret_val2

--
\\\
Cygwin
///
--
string.split() 
/
     glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
['\\']

--
\\\
Win32
///
--
string.split()
/
     glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
['\\']

--
\\\
Linux
///
--
string.split()
/
     glob.glob('/')
['/']

string.split()
\
     glob.glob('\')
[]
--------------------------------------------------------
For my education, is there a reason why glob.glob('\') on Win32/Cygwin returns ['\\'] instead of [] in Linux ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Tue Feb 22 08:40:28 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 07:40:28 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1298327175.69.0.448067040097.issue11199@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=p0bftcqPfF4j9m7FmLkDYMprFmU5z3awEcczj@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> rg3 <sarbalap+freshmeat at gmail.com> added the comment:
>
> I have to correct myself. I applied the patch manually to my Python 2.6 installation. In Python 2.6, the line you moved is number 961, and I did the same change.

OK. For information, you can apply it using the Unix "patch" command,
who can most of the time do all the work for you.

>
> With your change, the connection can be closed, but you have to wait for the file to be completely transferred. As I was throttling to 1 KB/sec initially, I thought it was still hanging because it takes more than 1 minute for the test file to be sent. Still, the connection isn't immediately closed when you request to close it.

That's expected, it's a consequence of this point I raised earlier:

> Note that I'm not sure why we need to wait for a further message on the control channel (maybe it's part of an RFC or something...).

The current code explicitely waits for the end of transfer before
closing the data channel.
Don't ask me why, I don't have a clue. I wrote a 2-line patch to
disable this behaviour which seems to work fine, but since I'm not
sure why the code is doing this right now, I'd like some feedback
before doing the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 09:48:20 2011
From: report at bugs.python.org (wesley chun)
Date: Tue, 22 Feb 2011 08:48:20 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>


New submission from wesley chun <wescpy at gmail.com>:

In the re docs, it states the following for the conditional regular expression syntax:

(?(id/name)yes-pattern|no-pattern)
Will try to match with yes-pattern if the group with given id or name exists, and with no-pattern if it doesn?t. no-pattern is optional and can be omitted. For example, (<)?(\w+@\w+(?:\.\w+)+)(?(1)>) is a poor email matching pattern, which will match with '<user at host.com>' as well as 'user at host.com', but not with '<user at host.com'.

this regex is incomplete as it allows for 'user at host.com>':

>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', '<user at host.com>'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', 'user at host.com'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', '<user at host.com'))
False
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)', 'user at host.com>'))
True

This error has existed since this feature was added in 2.4...
http://docs.python.org/release/2.4.4/lib/re-syntax.html

... through the 3.3. docs...
http://docs.python.org/dev/py3k/library/re.html#regular-expression-syntax

The fix is to add the end char '$' to the regex to get all 4 working:


>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', '<user at host.com>'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', 'user at host.com'))
True
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', '<user at host.com'))
False
>>> bool(re.match(r'(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)', 'user at host.com>'))
False

If accepted, I propose this patch (also attached):

$ svn diff re.rst
Index: re.rst
===================================================================
--- re.rst      (revision 88499)
+++ re.rst      (working copy)
@@ -297,9 +297,9 @@
 ``(?(id/name)yes-pattern|no-pattern)``
    Will try to match with ``yes-pattern`` if the group with given *id* or *name*
    exists, and with ``no-pattern`` if it doesn't. ``no-pattern`` is optional and
-   can be omitted. For example,  ``(<)?(\w+@\w+(?:\.\w+)+)(?(1)>)`` is a poor email
+   can be omitted. For example,  ``(<)?(\w+@\w+(?:\.\w+)+)(?(1)>|$)`` is a poor email
    matching pattern, which will match with ``'<user at host.com>'`` as well as
-   ``'user at host.com'``, but not with ``'<user at host.com'``.
+   ``'user at host.com'``, but not with ``'<user at host.com'`` nor ``'user at host.com>'`` .

----------
assignee: docs at python
components: Documentation, Regular Expressions
files: re.rst
messages: 129041
nosy: docs at python, wesley.chun
priority: normal
severity: normal
status: open
title: incorrect pattern in the re module docs for conditional regex
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20833/re.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Tue Feb 22 09:50:04 2011
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 22 Feb 2011 08:50:04 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298364604.48.0.805340517281.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> Do tests currently exist for smtpd run as a script?

I have to confess I didn't think to check.

> If not, our experience with converting compileall to argparse indicates a thorough test suite is needed (and even so we missed some things we hadn't thought to test).

OK, so if there is no test suite currently I should create one, and if there is one I should ensure it's complete? I guess I should use compileall as an example of how to test modules-as-scripts if the former? Overall, smtpd-as-a-script is really pretty simple, it totals 28 lines apart from the argument parsing itself (which is a bit under 60 lines ignoring the help text/pattern and gets a bit under 50 including it post-patch), and as I mentioned the only part which actually needed changing is the arguments parsing, which was very well factored out.

> In other words, if the current code works, is "updating" it a sufficient reason to change it, considering the chances of introducing new bugs?

I'm not sure, but one of the ways I see standard libraries is not just as "ready to use" code, it's also as a repository of how to do things. And to that end, if argparse is now considered the canonical way to parse command-line arguments (which I would expect), there are very few examples of how to do things in the stdlib itself (though there are examples outside of it, due to the life argparse had pre-stdlib).

It also rose to the occasion as I was wondering about the numerous standard library modules-as-scripts which are either undocumented or under-documented: because it had a good command-line documentation and a clean separation between the configuration (options parsing) and the actual execution, but no module documentation (in Doc/) it seemed like a good starting point: if it's not feasible to correctly convert "best cases" (and smtpd is probably one, short of modules using optparse probably) then the whole idea is stillborn: I do not see how it would be possible to fare better on some of the fully undocumented modules using manual options parsing, yet it would have to be expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:38:11 2011
From: report at bugs.python.org (s7v7nislands)
Date: Tue, 22 Feb 2011 09:38:11 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>


New submission from s7v7nislands <s7v7nislands at gmail.com>:

when use popen*() and close_fds is True, python will close unused fds. but the MAXFD is not the real max. especially in freebsd, subprocess.MAXFD=655000. so python will try to close to many fd, it's too slow, in my test on freebsd, using about 3 seconds.

poor english.

patch for 2.7 trunck:
jiangxiaobing at s7v7nislands ~/source/svn/python27 $ svn diff
Index: Lib/subprocess.py
===================================================================
--- Lib/subprocess.py	(revision 88499)
+++ Lib/subprocess.py	(working copy)
@@ -1065,11 +1065,16 @@
 
 
         def _close_fds(self, but):
+            maxfd = MAX_FD
+            try:
+                maxfd = os.dup(0) + 1
+            except:
+                pass
             if hasattr(os, 'closerange'):
                 os.closerange(3, but)
-                os.closerange(but + 1, MAXFD)
+                os.closerange(but + 1, maxfd)
             else:
-                for i in xrange(3, MAXFD):
+                for i in xrange(3, maxfd):
                     if i == but:
                         continue
                     try:
Index: Lib/popen2.py
===================================================================
--- Lib/popen2.py	(revision 88499)
+++ Lib/popen2.py	(working copy)
@@ -82,8 +82,13 @@
     def _run_child(self, cmd):
         if isinstance(cmd, basestring):
             cmd = ['/bin/sh', '-c', cmd]
-        os.closerange(3, MAXFD)
+        maxfd = MAXFD
         try:
+            maxfd = os.dup(0) + 1
+        except:
+            pass
+        os.closerange(3, maxfd)
+        try:
             os.execvp(cmd[0], cmd)
         finally:
             os._exit(1)



patch for 3.3 truck:
diff --git a/Lib/subprocess.py b/Lib/subprocess.py
index c02fb52..98a25b3 100644
--- a/Lib/subprocess.py
+++ b/Lib/subprocess.py
@@ -1112,8 +1112,14 @@ class Popen(object):
                 if fd >= start_fd:
                     os.closerange(start_fd, fd)
                     start_fd = fd + 1
-            if start_fd <= MAXFD:
-                os.closerange(start_fd, MAXFD)
+            maxfd = MAXFD
+            try:
+                maxfd = os.dup(0) + 1
+            except:
+                pass
+
+            if start_fd <= maxfd:
+                os.closerange(start_fd, maxfd)
 
 
         def _execute_child(self, args, executable, preexec_fn, close_fds,

----------
components: Library (Lib)
files: py3k.patch
keywords: patch
messages: 129043
nosy: s7v7nislands
priority: normal
severity: normal
status: open
title: slow close file descriptors in subprocess, popen2, os.pepen*
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20834/py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:39:36 2011
From: report at bugs.python.org (s7v7nislands)
Date: Tue, 22 Feb 2011 09:39:36 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298367576.57.0.902842750967.issue11284@psf.upfronthosting.co.za>


Changes by s7v7nislands <s7v7nislands at gmail.com>:


Added file: http://bugs.python.org/file20835/python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:48:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Feb 2011 09:48:20 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298368100.63.0.393873042639.issue11260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Xavier, I think these efforts are misguided in several ways:

* Many of the undocumented command-line interfaces are
intentionally undocumented -- they were there for the
convenience of the developer for exercising the module
as it was being developed and are not part of the official API.
Most are not production quality and would have been done
much differently if that had been the intent.

* The standard library's primary purpose is to be a library
for use in user programs, not to serve as a suite of applications.
We do have a few applications such as pydoc that assist
development, but that is not what we want to do for most
modules.  Real apps need more features than we usually
offer and they need much faster development cycles than
supported by our 18-24 month release cycle. 

* To the extent the standard library serves as a set of
examples, that is just side benefit.  There are other
ways to make code specifically for examples (we include
tons of examples in the documentation; we had a Demos
directory; there is the wiki; and there is the ASPN
Cookbook site; etc)

* David Murray is correct is pointing-out that converting
to argparse risks changing the semantics and possibly
breaking someone's existing uses of the current interface.

* Though argparse is the shiny new kid on the block and
it should be used for new code, there is no imperative
to go change all existing command-line scripts.  We haven't
even done that same exercise for the new string formatting.

* All that being said, there are some exceptions and it
make may sense to document the interface in some where
we really do want a command-line app.  I'll look at
any patches you want to submit, but try to not go wild
turning the library into a suite of applications.  For
the most part, that is not what the standard library
is about.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 10:49:12 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 09:49:12 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298368152.67.0.464153509624.issue11284@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

dup(2) returns the lowest numbered available file descriptor: if there's a discontinuity in the FDs allocation, this code is going to close only the FDs up to the first available FD.
Imagine for example the following:
open("/tmp/foo") = 3
open("/tmp/bar") = 4
close(3)

Then dup(0) will return 3, and not the max FD.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:42:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 10:42:45 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298371365.77.0.815983872221.issue11243@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Of course you're right.  It just reads, passes around and spits out that ... of a mail just the same it came in.  Performance is very well, too, just about 1.5 seconds - some two weeks ago it took about 1.1 seconds, but with Python 2.7 - so!

P.S.: my very own desire was just to have a single entry point where i can drop whatever ... in and get something back which may be just as silly but at least conformant, e.g. '__setitem__[x] = ADJUST(__getitem__[x])'; imagine what a swiss ;-) would need to do to get to that point with EMail 5.1: x=header.decode_header(), if x[1] is None check wether string is ASCII clean, otherwise hard-encode with latin1/unknown 8-bit; but even if x[1] is not None the content may be malformed; and then remember that all these steps can throw exceptions, which need to be handled because the mail *will* be processed.  Of course, we're talking about the header here only 8-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:43:43 2011
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 22 Feb 2011 10:43:43 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298371423.53.0.918838339669.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> any of the undocumented command-line interfaces are intentionally undocumented -- they were there for the convenience of the developer for exercising the module as it was being developed and are not part of the official API.

I can understand that, but it's not clear from the source code which is which, and for several of them third-parties have taken up the convenience. Maybe a more formal process of defining which tools are to be considered "official" and which are easter-eggs is needed? In any case, even for "easter eggs" surely a good command-line documentation is a good idea (even if the module documentation side is not added due to the "easter egg" status) isn't it?

> The standard library's primary purpose is to be a library for use in user programs, not to serve as a suite of applications.

Sure, and I don't think most of the module-as-scripts have what it takes to be seen as applications, but many are useful and/or interesting helpers/shortcuts for day to day tasks. http.server and smtpd are good examples of useful modules-as-scripts (http.server being the exact opposite of smtpd in that it has a module-as-script documentation but no documentation whatsoever on the command-line)

> Real apps need more features than we usually offer and they need much faster development cycles than supported by our 18-24 month release cycle. 

I think my suggestion has been misunderstood: I don't want to turn these into real apps, they're fine as basic scripts/helpers to spend 5mn on a task instead of half an hour. I think they deserve better than to be documented and known through StackOverflow or Reddit "what are the -m stdlib features" lists.

> To the extent the standard library serves as a set of examples, that is just side benefit.  There are other ways to make code specifically for examples (we include tons of examples in the documentation; we had a Demos directory; there is the wiki; and there is the ASPN Cookbook site; etc)

Sure, but I think it's still an important driver of how things "are done" in that they're *concrete* examples, not abstract (of course the Cookbook is generally concrete as well). I'm not discounting the importance or quality of the rest of the documentation at all, or at least that was not my intention.

> All that being said, there are some exceptions and it make may sense to document the interface in some where we really do want a command-line app.  I'll look at any patches you want to submit, but try to not go wild turning the library into a suite of applications.  For the most part, that is not what the standard library is about.

As I said, my only intention here is be to document (and argparsify/formalize) what is already there. I considered doing more (e.g. for the specific case of smtpd-as-a-script making ports optional even when hosts are specified, that kind of things) but decided against this distraction, I really just want to make existing module-as-script features simpler to discover and use.

That said, do you have guidelines of which areas this idea would be most interestingly/efficiently applied? Maybe a list of modules-as-scripts you know are used regularly and could benefit from some improvements in their interface or documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:46:14 2011
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 22 Feb 2011 10:46:14 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298371574.32.0.360743729648.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

One more note I forgot previously: the conversion of as much scripts as possible to argparse would be for three reasons:

* Make behavior consistent across the board (e.g. -h/--help)
* Make CLI documentation format consistent across the board either so users know what to expect and when
* Provide easy to reach (for users) examples of using argparse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 11:57:13 2011
From: report at bugs.python.org (Sean Reifschneider)
Date: Tue, 22 Feb 2011 10:57:13 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1298372233.14.0.309671619638.issue10924@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Committed in r88500.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:04:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 11:04:11 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298347582.23.0.214253039844.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298372648.3757.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Does it matter that _4G < UINT_MAX?

You mean _4G > UINT_MAX, right?
Yes, it matters, otherwise that defeats the point of the test :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:25:10 2011
From: report at bugs.python.org (Andres Riancho)
Date: Tue, 22 Feb 2011 11:25:10 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298373910.14.0.0500710446595.issue11280@psf.upfronthosting.co.za>


Andres Riancho <andres.riancho at gmail.com> added the comment:

Please take a deeper look. I think you're trusting the "old code" more than my bug report. Some things to keep in mind:

 * The "headers" parameter is a dict. It will never have a getheaders method

 * The If you search the whole urllib2.py file, you won't find instances of headers.getheaders(), you'll find headers.get() , as expected when using a dict.

Also, the call chain to this method is:

 * def error(self, proto, *args)
 * meth_name = 'http_error_%s' % proto
 * args = (dict, proto, meth_name) + args
 * return self._call_chain(*args)
 * Where args comes from:
    error('http', request, response, code, msg, hdrs)
 * And the hdrs variable is set here:
    code, msg, hdrs = response.code, response.msg, response.info()
 * And as you know, the response object returns a dict when info() is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:29:05 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 11:29:05 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298374145.21.0.964097322601.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

'Have no glue, but Ned Daily's patch (msg129011) seems to be required for adler, too.  (You know...)

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:30:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 11:30:02 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298374202.42.0.002879715401.issue11277@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, it's not a patch, just a traceback :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 12:42:06 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 11:42:06 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298374926.47.0.321090747642.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Wait a few minutes, i'll write this simple patch for adler and crc.  But excessive testing and such is beyond my current capabilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:11:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Feb 2011 12:11:15 +0000
Subject: [issue11243] email/message.py str conversion
In-Reply-To: <1298040800.89.0.758296478469.issue11243@psf.upfronthosting.co.za>
Message-ID: <1298376675.09.0.174815209881.issue11243@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We might wind up with a relatively quick 3.2.1, in which case we can get this fixed then.

The parser is supposed to operate without throwing exceptions (just setting defects), so if you find a case where *parsing* throws an exception please open an issue.  Once you start manipulating the model, of course, you may get exceptions.  I'm not sure what should happen if, say, the charset name is invalid (8bit), but certainly throwing an error because it is a Header rather than a string is wrong and needs fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11243>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:15:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:15:01 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298376901.18.0.0982605655992.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

File: issue11277.patch.
Hmm.  Two non-register constants and equal code on 32 and 64 bit.  Does Python has a '64 bit' switch or the like - PY_SSIZE_T_MAX is not preprocessor-clean, i would guess.

----------
keywords: +patch
Added file: http://bugs.python.org/file20836/issue11277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:17:02 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:17:02 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298377022.13.0.574777476258.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20836/issue11277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:17:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:17:20 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298377040.34.0.942724286006.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Sorry - that was a mess.

----------
Added file: http://bugs.python.org/file20837/issue11277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:18:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 12:18:10 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298376901.18.0.0982605655992.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298377086.3757.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> File: issue11277.patch.
> Hmm.  Two non-register constants and equal code on 32 and 64 bit.
> Does Python has a '64 bit' switch or the like - PY_SSIZE_T_MAX is not
> preprocessor-clean, i would guess.

Er, how is this patch different from r88460?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:19:48 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Feb 2011 12:19:48 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298377188.92.0.1129070938.issue11281@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This sounds like a reasonable feature request.  If you would like to propose a patch against trunk (py3k, what will become 3.3), I will take a look at it.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:24:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Feb 2011 12:24:36 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1298377476.05.0.125942768837.issue10924@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Some buildbots are failing after the commit.

Also in the crypt.py module I still see things that according to msg126453 should be fixed already:
 * more statements on the same line (e.g. "if salt == None: salt = mksalt()");
 * the hardcoded salt values instead of string.ascii_letters;

According to the PEP8 there shouldn't be any spaces after the '[' and before the ']' (e.g. "method_list = [ METHOD_SHA512, METHOD_SHA256, METHOD_MD5 ]" and in the listcomps) and around the = in the function/method declarations/calls (e.g. "def crypt(word, salt = None):").

----------
keywords: +buildbot
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:24:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:24:38 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298377478.77.0.133933963721.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I guess not at all.  Well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:32:09 2011
From: report at bugs.python.org (Andres Riancho)
Date: Tue, 22 Feb 2011 12:32:09 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298377929.38.0.478284089138.issue11280@psf.upfronthosting.co.za>


Andres Riancho <andres.riancho at gmail.com> added the comment:

One more comment to be added. Please take a look at the following [0] w3af bug report. The interesting part starts at "[ Sun Nov 28 01:25:47 2010 - debug ] Traceback (most recent call last):".

In there you'll find that my w3af code had a section of urllib2's code in logHandler.py (self.original_http_error_302(req, fp, code, msg, headers)) and that the error is very clear (to me at least):

[ Sun Nov 28 01:25:47 2010 - debug ] newurl = headers.getheaders('location')[0]
[ Sun Nov 28 01:25:47 2010 - debug ] AttributeError?: 'dict' object has no attribute 'getheaders'

[0] https://sourceforge.net/apps/trac/w3af/ticket/160511

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:40:01 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:40:01 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298378401.83.0.38641203583.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

test_zlib.py (with my patch but that's somewhat identical in the end, say) does

.............................s.......
----------------------------------------------------------------------
Ran 37 tests in 1.809s

OK (skipped=1)

This is on Snow Leopard 64 bit, 02b70cb59701 (r88451) -> Python 3.3a0.
Is there a switch i must trigger?  Just pulled 24 changesets, recompiling and trying again with r88460.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:41:53 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 12:41:53 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1298378513.82.0.274720681552.issue10228@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

It looks like because before the second time running of WhichDBTestCase.test_whichdb(), previous dumb files are not cleaned clearly, so the gdbm's open() doesn't create a new gdbm database but open an existing dumb database.

In fact during the working of #9523, I found this problem and fix it in the patch of #9523. Here I extract the fixing, it is simple:


cat patches/issue10228.diff 
Index: Lib/test/test_dbm.py
===================================================================
--- Lib/test/test_dbm.py	(revision 88499)
+++ Lib/test/test_dbm.py	(working copy)
@@ -123,7 +123,7 @@
             name = module.__name__
             if name == 'dbm.dumb':
                 continue   # whichdb can't support dbm.dumb
-            test.support.unlink(_fname)
+            delete_files()
             f = module.open(_fname, 'c')
             f.close()
             self.assertEqual(name, dbm.whichdb(_fname))

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:49:08 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:49:08 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Just pulled 64380ee4bbc5 (r88500) and compiled, Python's busted:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/Users/steffen/usr/opt/py3k/lib/python3.3/io.py", line 60, in <module>
Abort trap

----------
components: IO
messages: 129065
nosy: sdaoden
priority: normal
severity: normal
status: open
title: io.py standart stream setup crash
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:50:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 12:50:34 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298378401.83.0.38641203583.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298379029.3757.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is on Snow Leopard 64 bit, 02b70cb59701 (r88451) -> Python 3.3a0.
> Is there a switch i must trigger?  Just pulled 24 changesets,
> recompiling and trying again with r88460.

Have you tried "./python -m test -v -uall test_zlib" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:53:31 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 12:53:31 +0000
Subject: [issue3783] dbm.sqlite proof of concept
In-Reply-To: <1220572652.24.0.256023256295.issue3783@psf.upfronthosting.co.za>
Message-ID: <1298379211.24.0.19507786873.issue3783@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3783>
_______________________________________

From report at bugs.python.org  Tue Feb 22 13:56:36 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 12:56:36 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298379396.0.0.118073176932.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

No, i've got no idea of this framework... Just did 'python3 test_zlib.py' directly.  Thanks for the switch.  But i can't test your thing due to issue11285, so this may take a while (others have more knowledge anyway)..

(P.S.: your constant-folding stack patch is a great thing, just wanted to say this once..)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:01:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 13:01:32 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298379692.87.0.0960631576599.issue11285@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you try to identify which revision introduced the issue?

----------
nosy: +haypo, ned.deily, pitrou
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:06:11 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:06:11 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298379971.09.0.730147023159.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

So here is this (with my patch, but this is for real: issue11277.2.patch):

== CPython 3.3a0 (py3k, Feb 22 2011, 14:00:52) [GCC 4.2.1 (Apple Inc. build 5664)]
==   Darwin-10.6.0-i386-64bit little-endian
==   /private/var/folders/Da/DaZX3-k5G8a57zw6MSmjJ++++TM/-Tmp-/test_python_89365
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_zlib
test_adler32empty (test.test_zlib.ChecksumTestCase) ... ok
test_adler32start (test.test_zlib.ChecksumTestCase) ... ok
test_crc32_adler32_unsigned (test.test_zlib.ChecksumTestCase) ... ok
test_crc32empty (test.test_zlib.ChecksumTestCase) ... ok
test_crc32start (test.test_zlib.ChecksumTestCase) ... ok
test_penguins (test.test_zlib.ChecksumTestCase) ... ok
test_same_as_binascii_crc32 (test.test_zlib.ChecksumTestCase) ... ok
test_badargs (test.test_zlib.ExceptionTestCase) ... ok
test_badcompressobj (test.test_zlib.ExceptionTestCase) ... ok
test_baddecompressobj (test.test_zlib.ExceptionTestCase) ... ok
test_badlevel (test.test_zlib.ExceptionTestCase) ... ok
test_decompressobj_badflush (test.test_zlib.ExceptionTestCase) ... ok
test_big_compress_buffer (test.test_zlib.CompressTestCase) ... ok
test_big_decompress_buffer (test.test_zlib.CompressTestCase) ... ok
test_incomplete_stream (test.test_zlib.CompressTestCase) ... ok
test_length_overflow (test.test_zlib.CompressTestCase) ... skipped 'not enough free memory, need at least 4 GB'
test_speech (test.test_zlib.CompressTestCase) ... ok
test_speech128 (test.test_zlib.CompressTestCase) ... ok
test_badcompresscopy (test.test_zlib.CompressObjectTestCase) ... ok
test_baddecompresscopy (test.test_zlib.CompressObjectTestCase) ... ok
test_big_compress_buffer (test.test_zlib.CompressObjectTestCase) ... ok
test_big_decompress_buffer (test.test_zlib.CompressObjectTestCase) ... ok
test_compresscopy (test.test_zlib.CompressObjectTestCase) ... ok
test_compressincremental (test.test_zlib.CompressObjectTestCase) ... ok
test_compressoptions (test.test_zlib.CompressObjectTestCase) ... ok
test_decompimax (test.test_zlib.CompressObjectTestCase) ... ok
test_decompinc (test.test_zlib.CompressObjectTestCase) ... ok
test_decompincflush (test.test_zlib.CompressObjectTestCase) ... ok
test_decompress_incomplete_stream (test.test_zlib.CompressObjectTestCase) ... ok
test_decompresscopy (test.test_zlib.CompressObjectTestCase) ... ok
test_decompressmaxlen (test.test_zlib.CompressObjectTestCase) ... ok
test_decompressmaxlenflush (test.test_zlib.CompressObjectTestCase) ... ok
test_empty_flush (test.test_zlib.CompressObjectTestCase) ... ok
test_flushes (test.test_zlib.CompressObjectTestCase) ... ok
test_maxlenmisc (test.test_zlib.CompressObjectTestCase) ... ok
test_odd_flush (test.test_zlib.CompressObjectTestCase) ... ok
test_pair (test.test_zlib.CompressObjectTestCase) ... ok

----------------------------------------------------------------------
Ran 37 tests in 1.789s

OK (skipped=1)
1 test OK.

----------
Added file: http://bugs.python.org/file20838/issue11277.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:06:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:06:35 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298379995.29.0.847066385567.issue11285@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Let me see some minutes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:07:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:07:07 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298380027.76.0.110055806318.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20837/issue11277.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:08:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:08:17 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298380097.05.0.878682703259.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Is not that much help for a >4GB error, huh?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:22:40 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:22:40 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298380960.15.0.922633274096.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Just stepping ... with c8d1f99f25eb/r88476:

== CPython 3.3a0 (py3k, Feb 22 2011, 14:18:19) [GCC 4.2.1 (Apple Inc. build 5664)]
==   Darwin-10.6.0-i386-64bit little-endian
==   /private/var/folders/Da/DaZX3-k5G8a57zw6MSmjJ++++TM/-Tmp-/test_python_5126
Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_zlib
test_adler32empty (test.test_zlib.ChecksumTestCase) ... ok
test_adler32start (test.test_zlib.ChecksumTestCase) ... ok
test_crc32_adler32_unsigned (test.test_zlib.ChecksumTestCase) ... ok
test_crc32empty (test.test_zlib.ChecksumTestCase) ... ok
test_crc32start (test.test_zlib.ChecksumTestCase) ... ok
test_penguins (test.test_zlib.ChecksumTestCase) ... ok
test_same_as_binascii_crc32 (test.test_zlib.ChecksumTestCase) ... ok
test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase) ... 
^C
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C
Bus error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:30:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 13:30:14 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298380960.15.0.922633274096.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298381409.3757.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Just stepping ... with c8d1f99f25eb/r88476:

Right, that's what we should investigate :)
Could try to diagnose the crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:39:19 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 13:39:19 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298381959.54.0.935495312135.issue11285@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

According to adorable but slow Mercurial:

The first bad revision is:
changeset:   9894:fc8a94cc17a4
branch:      py3k
user:        raymond.hettinger
date:        Tue Feb 22 01:41:50 2011 +0100
summary:     [svn r88490] Issue #11085: Moved collections abstract base classes into a separate module

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:43:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 13:43:47 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298382227.61.0.621769874057.issue11285@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:53:04 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 13:53:04 +0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1298382784.35.0.211690043622.issue2159@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2159>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:56:10 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Feb 2011 13:56:10 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

I have 10MB pickled structure generated in Python 2.7. I only use basic
types (no clases) like sets, dictionaries, lists, strings, etc.

The pickle stores a lot of strings. Some of them should be "bytes",
while other should be "unicode". My idea is to import ALL the strings as
bytes in Python 3.2 and navigate the data structure to convert the
appropiate values to unicode, in a one-time operation (I version the
structure, so I can know if this conversion is already done, simply
storing a new version value).

But I get this error:

"""
Python 3.2 (r32:88445, Feb 21 2011, 13:34:07)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> >>> f=open("file.pickle", mode="rb").read()
>>> >>> len(f)
9847316
>>> >>> b=pickle.loads(f,encoding="latin1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object
"""

I use the encoding "latin1" for transparent byte/unicode conversion (do
not touch the values!).

This seems to be a bug in Python 3.2. Any suggestion?.

The bytestream is protocol 2.


PYTHON 3.1.3 loads the pickle just fine.

Trying to generate a testcase. I can't upload the pickle, because it contains propietary information.

----------
components: Library (Lib)
messages: 129075
nosy: georg.brandl, jcea
priority: release blocker
severity: normal
stage: test needed
status: open
title: Some "trivial" python 2.x pickles fails to load in Python 3.2
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 14:58:26 2011
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 22 Feb 2011 13:58:26 +0000
Subject: [issue11287] Add context manager support to dbm modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

dbm objects, including gdbm, ndbm, dumb, should support context manager. That is, can be used with 'with' keyword, just like regular file objects.

I'm working out a patch for this.

----------
components: Extension Modules
messages: 129076
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: Add context manager support to dbm modules
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11287>
_______________________________________

From report at bugs.python.org  Tue Feb 22 15:48:56 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 22 Feb 2011 14:48:56 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298386136.44.0.144747321062.issue10882@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Yes I agree it can go in now. Unless someone wants to do some tests on more OS's like FreeBSD 7.2, Solaris, etc. (I've only checked on Linux 2.6, FreeBSD 8.1, OpenIndiana and OS X 10.5).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:02:11 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 22 Feb 2011 15:02:11 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298386931.62.0.306503287479.issue11260@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'd support updating to argparse *if* you write a test suite for full coverage of the existing cli first.  Once that passes, you'll have more confidence in your port.  Modernizing the argument parsing in that case would be a useful addition.  Not critical, but on the whole I think a good thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:05:28 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Feb 2011 15:05:28 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298387128.87.0.469940179293.issue11286@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I got a trivial (41 bytes long) reproductable case:

Pickle the following structure in Python 2.7, and try to unpickle with Python 3.2, using a "latin1" encoding:

"""
{'ya_volcados': {'comment': ''}}
"""

Load with:

"""
#!/usr/local/bin/python3

import pickle

f=open("z.pickle", "rb").read()

a=pickle.loads(f,encoding="latin1")
"""

(I use "latin1" because my real pickle includes binary data stored as strings. Note that the testcase doesn't content binary data).

Python 3.2, 32 bits. Tested under Solaris and Linux.

This worked in Python 3.1.3, so we have a regression.

----------
keywords: +3.2regression
stage: test needed -> needs patch
Added file: http://bugs.python.org/file20839/z.pickle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:10:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 15:10:30 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298387430.5.0.995681380093.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so it boils down to:

>>> pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.')
{'': ''}
>>> pickle.loads(b'\x80\x02}q\x00U\x00q\x01h\x01s.', encoding='latin1')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation forbidden on released memoryview object

(this is protocol 2, by the way. Protocol 0 works fine.)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:13:09 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 22 Feb 2011 15:13:09 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298387589.88.0.473626050147.issue11286@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Storing the pickle using protocol 0, it works OK.

Using protocol 1 or 2, it fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:21:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 15:21:00 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298388060.38.0.667500660925.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is because of the buffer pointer passed to the codecs machinery being NULL when the empty string is being decoded.

Quick patch follows (needs a test). Also, it is not clear whether it is allowed to store a NULL pointer in the "buf" member of a Py_buffer when the length is 0. Nick, Mark?


Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c	(r?vision 88500)
+++ Objects/unicodeobject.c	(copie de travail)
@@ -1460,6 +1460,7 @@
     PyObject *buffer = NULL, *unicode;
     Py_buffer info;
     char lower[11];  /* Enough for any encoding shortcut */
+    static const char empty[] = "";
 
     if (encoding == NULL)
         encoding = PyUnicode_GetDefaultEncoding();
@@ -1485,6 +1486,8 @@
 
     /* Decode via the codec registry */
     buffer = NULL;
+    if (s == NULL)
+        s = empty;
     if (PyBuffer_FillInfo(&info, NULL, (void *)s, size, 1, PyBUF_FULL_RO) < 0)
         goto onError;
     buffer = PyMemoryView_FromBuffer(&info);

----------
nosy: +mark.dickinson, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:27:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Feb 2011 15:27:29 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298388449.12.0.764907102532.issue11280@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The traceback you point to seems to indicate the getheaders call is in your code.

Can you provide a minimal test case that demonstrates the failure mode you are concerned about?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:31:04 2011
From: report at bugs.python.org (Andres Riancho)
Date: Tue, 22 Feb 2011 15:31:04 +0000
Subject: [issue11280] urllib2 http_error_302 calls undefined "getheaders"
	method
In-Reply-To: <1298341349.41.0.55623221755.issue11280@psf.upfronthosting.co.za>
Message-ID: <1298388664.11.0.113485191202.issue11280@psf.upfronthosting.co.za>


Andres Riancho <andres.riancho at gmail.com> added the comment:

Yes, the traceback was in my code because as I stated before: "my w3af code had a section of urllib2's code in logHandler.py" in other words, I copy+pasted a section of urllib2 into my code.

Can't provide a test case now, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11280>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:36:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 15:36:43 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298389003.86.0.567582308737.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

+1, this has been done for other modules such as ftplib as well and probably could be done for others such as httplib and poplib.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:37:58 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 15:37:58 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298389078.05.0.50904530156.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

.. even with a self-compiled 1.2.3, INT_MAX/1000 ... nothing.
The problem is not crc32(), but the buffer itself:

   if (pbuf.len > 1024*5) {
        unsigned char *buf = pbuf.buf;
        Py_ssize_t len = pbuf.len;
        Py_ssize_t i;
fprintf(stderr, "CRC 32 2.1\n");
for(i=0; (size_t)i < (size_t)len;++i)
    *buf++ = 1;
fprintf(stderr, "CRC 32 2.2\n");

2.2 is never reached (in fact accessing buf[1] already causes fault).
Thus the problem is not zlib, but PyArg_ParseTuple().
But just don't ask me more on that!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:39:19 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 15:39:19 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298389159.28.0.180121679449.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(P.S.: of course talking about ChecksumBigBufferTestCase and the 4GB, say.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:41:58 2011
From: report at bugs.python.org (Matthew Funke)
Date: Tue, 22 Feb 2011 15:41:58 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>


New submission from Matthew Funke <go4tli at gmail.com>:

I uninstalled Python 3.1.3 and installed the 32-bit version of Python 3.2 on my 64-bit Win7 box.  (My favorite IDE requires the 32-bit version.)  trying to run IDLE crashes; running C:\python32\python.exe returns this error:

Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I tried Googling the error, but couldn't find much help for it.  Thoughts?

----------
components: IDLE, Windows
messages: 129088
nosy: Matthew.Funke
priority: normal
severity: normal
status: open
title: Python installed from MSI doesn't work
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:44:55 2011
From: report at bugs.python.org (SilentGhost)
Date: Tue, 22 Feb 2011 15:44:55 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1298389495.96.0.283429351111.issue10924@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Here is the patch fixing pep-8 compatibility and test. It is against the latest commit.

----------
nosy: +SilentGhost
status: closed -> open
Added file: http://bugs.python.org/file20840/crypt.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:50:48 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 22 Feb 2011 15:50:48 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298389848.04.0.877097858945.issue11288@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:56:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 15:56:29 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298389078.05.0.50904530156.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298390186.3757.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> .. even with a self-compiled 1.2.3, INT_MAX/1000 ... nothing.
> The problem is not crc32(), but the buffer itself:
> 
>    if (pbuf.len > 1024*5) {
>         unsigned char *buf = pbuf.buf;
>         Py_ssize_t len = pbuf.len;
>         Py_ssize_t i;
> fprintf(stderr, "CRC 32 2.1\n");
> for(i=0; (size_t)i < (size_t)len;++i)
>     *buf++ = 1;
> fprintf(stderr, "CRC 32 2.2\n");

Thank you! So it's perhaps a bug in mmap on Snow Leopard.
Could you try to debug a bit more precisely and see at which buffer
offset (from the start) the fault occurs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 16:58:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 15:58:35 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298390315.35.0.771640626763.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Snippet

    if (pbuf.len > 1024*5) {
        volatile unsigned char *buf = pbuf.buf;
        Py_ssize_t len = pbuf.len;
Py_ssize_t i = 0;
volatile unsigned char au[100];
volatile unsigned char*x = au;
        fprintf(stderr, "CRC ENTER, buffer=%p\n", buf);
for (i=0; (size_t)i < (size_t)len; ++i) {
    fprintf(stderr, "%ld, buf=%p\n", (signed long)i, buf);
    *x = *buf++;
}

results in

test_big_buffer (test.test_zlib.ChecksumBigBufferTestCase) ... CRC ENTER, buffer=0x1014ab000
0, buf=0x1014ab000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:17:33 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 16:17:33 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298391453.23.0.383208143975.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> I would like to add source_ip and source_port parameters to 
> smtplib.SMTP, default to '' and 0 respectively.

It would be better to provide a unique source_address parameter defaulting to None, for consistency with socket.create_connection() expecting a (addr, port) tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:37:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 16:37:28 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298392648.43.0.55855071363.issue11277@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Out of curiosity, could you try the following patch?

Index: Lib/test/test_zlib.py
===================================================================
--- Lib/test/test_zlib.py	(r?vision 88500)
+++ Lib/test/test_zlib.py	(copie de travail)
@@ -70,7 +70,7 @@
         with open(support.TESTFN, "wb+") as f:
             f.seek(_4G)
             f.write(b"asdf")
-            f.flush()
+        with open(support.TESTFN, "rb") as f:
             self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
 
     def tearDown(self):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:53:34 2011
From: report at bugs.python.org (Clayton Darwin)
Date: Tue, 22 Feb 2011 16:53:34 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1298393614.88.0.809270711663.issue6549@psf.upfronthosting.co.za>


Clayton Darwin <claytondarwin at gmail.com> added the comment:

I have been working with the ttk module (Windows XP, Python 3.1) and have encountered some specific issues with ttk.Style() not fully propagating the style into the widget.  In my particular case, there seem to be issues with setting style in TCombobox and TEntry.  The biggest issue is that you can't change the style of the ttk.Combobox popdown.  Style can be set in the top window, but not using all methods, but nothing works for the popdown. 

I have included an example script that illustrates the issues I have encountered.

Clayton

----------
nosy: +claytondarwin
Added file: http://bugs.python.org/file20841/ttk_combobox_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6549>
_______________________________________

From report at bugs.python.org  Tue Feb 22 17:58:57 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 16:58:57 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298393937.36.0.290078114551.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch with tests.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20842/null_ptr_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:05:06 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:05:06 +0000
Subject: [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Patch in attachment provides a context manager for SMTP class so that it can be used with the "with" statement.

----------
messages: 129096
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: smtplib context manager
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11289>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:05:25 2011
From: report at bugs.python.org (Clayton Darwin)
Date: Tue, 22 Feb 2011 17:05:25 +0000
Subject: [issue11290] ttk.Combobox['values'] String Conversion to Tcl
In-Reply-To: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>
Message-ID: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>


New submission from Clayton Darwin <claytondarwin at gmail.com>:

In working with the ttk.Combobox (Windows XP, Python 3.1), I have found that setting the values for the popdown using ttk.Combobox['values'] has an problem converting the string to the proper Tcl value when (and this is the only instance I have found) there is a backslash in the string but no spaces.  In this case, the string will translate if it is enclosed in curly brackets '{'+mystring+'}', which I believe is the Tcl syntax to not make substitutions.

I have attached a short script that illustrates this issue.

Clayton

----------
components: Tkinter
files: tcl_string_test.py
messages: 129097
nosy: claytondarwin
priority: normal
severity: normal
status: open
title: ttk.Combobox['values'] String Conversion to Tcl
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file20843/tcl_string_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11290>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:12:23 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 17:12:23 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298394743.61.0.28116090725.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Seems like the signature of Lib.test.mock_socket.create_connection does not match socket.create_connection since 2.7.

I need help with the docs; the last argument is positional and optional, using the `[ ]' notation. What is the notation for the new keyword arguments?

----------
keywords: +patch
Added file: http://bugs.python.org/file20844/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:16:18 2011
From: report at bugs.python.org (SilentGhost)
Date: Tue, 22 Feb 2011 17:16:18 +0000
Subject: [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298394978.57.0.543637391313.issue11289@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

you didn't attach anything, Giampaolo.

----------
components: +Library (Lib)
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11289>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:16:44 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:16:44 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298395004.41.0.481018367806.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Seems like the signature of Lib.test.mock_socket.create_connection does 
> not match socket.create_connection since 2.7.

You can add a fake parameter which does nothing.

> What is the notation for the new keyword arguments?

fun(a, b, c=None, d=None)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:18:21 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 17:18:21 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298395101.07.0.631257009831.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Also, it is my first patch and I have no clue about what I'm doing, I don't expect to get it right in the first try - please point any mistakes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:18:36 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:18:36 +0000
Subject: [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298395116.18.0.885016151997.issue11289@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Ouch! Here. =)

----------
keywords: +patch
Added file: http://bugs.python.org/file20845/smtplib_context_manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11289>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:22:18 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 17:22:18 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298395338.52.0.175013978481.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

@Giampaolo: should I change the text in Doc/library/smtplib.rst or it is infered from the docstrings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:24:28 2011
From: report at bugs.python.org (SilentGhost)
Date: Tue, 22 Feb 2011 17:24:28 +0000
Subject: [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298395468.64.0.121650087427.issue11289@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

is print really necessary in the test?

Also, I think it would be better to unpack the tuple in test, rather then index it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11289>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:26:02 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:26:02 +0000
Subject: [issue11289] smtplib context manager
In-Reply-To: <1298394306.41.0.957762202245.issue11289@psf.upfronthosting.co.za>
Message-ID: <1298395562.93.0.483169181453.issue11289@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> is print really necessary in the test?

no, my mistake

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11289>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:37:20 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:37:20 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298396240.36.0.215612790276.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Yes, you must update  Doc/library/smtplib.rst and write tests.
If you're not the one who's gonna commit the patch you can ignore Doc/whatsnew/3.3.srt and Misc/NEWS changes.

Updating the docstring is usually optional but I see smtplib module is already well documented so I'd update docstrings as well.

As for how to write a patch see:
http://www.python.org/dev/faq/#patches
...or search in the bug tracker for committed patches, such as:
http://bugs.python.org/issue8807
http://svn.python.org/view?view=revision&revision=84144

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 18:41:32 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 17:41:32 +0000
Subject: [issue11287] Add context manager support to dbm modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298396492.22.0.410878146444.issue11287@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11287>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:07:19 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 18:07:19 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298398039.66.0.102248056671.issue11277@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> .. even with a self-compiled 1.2.3, INT_MAX/1000 ... nothing.
> The problem is not crc32(), but the buffer itself:
> 
>    if (pbuf.len > 1024*5) {
>         unsigned char *buf = pbuf.buf;
>         Py_ssize_t len = pbuf.len;
>         Py_ssize_t i;
> fprintf(stderr, "CRC 32 2.1\n");
> for(i=0; (size_t)i < (size_t)len;++i)
>     *buf++ = 1;
> fprintf(stderr, "CRC 32 2.2\n");

Unless I'm mistaken, in the test the file is mapped with PROT_READ, so it's normal to get SIGSEGV when writting to it:

   def setUp(self): 
            with open(support.TESTFN, "wb+") as f: 
                f.seek(_4G) 
                f.write(b"asdf") 
                f.flush() 
                self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) 

> for(i=0; (size_t)i < (size_t)len;++i)
>     *buf++ = 1;

But it seems you're also getting segfaults when only reading it, right ?

I've got a stupid question: how much memory do you have ?
Cause there seems to be some issues with page cache when reading mmaped files on OS-X:
http://lists.apple.com/archives/darwin-development/2003/Jun/msg00141.html

On Linux, the page cache won't fill forever, so you don't need to have enough free memory to accomodate the whole file (the page cache should grow, but not forever). But on OS-X, it seems that the page replacement algorithm seems to retain mmaped pages in the page cache much longer, which could potentially trigger an OOM later (because of overcommitting, mmap can very well return a valid address range which leads to a segfault when accessed later).
I'm not sure why it would segfault on the first page, though.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 19:33:40 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Tue, 22 Feb 2011 18:33:40 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298399620.45.0.164700212287.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

My first idea was to make the argument a tuple to match socket.create_connection(), but SMTP uses host and port arguments, for consistency it's better havin separate source_ip and source_port arguments. As a side effect, it makes easier to specify only source_port. 

The submited patch includes tests and updated docstrings; 

At the smtplib.rst, for example:

SMTP(host='', port=0, local_hostname=None[, timeout])

Would be ok to change it like:

SMTP(host='', port=0, local_hostname=None[, timeout], source_ip='', source_port=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:08:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 19:08:22 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1298401702.91.0.688204862439.issue11276@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

While directly referencing a module on its own is useless, this is an issue if the module is used in e.g., an assignment: ``blah = cPickle`` is not changed.

----------
nosy: +brett.cannon
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:09:55 2011
From: report at bugs.python.org (rg3)
Date: Tue, 22 Feb 2011 19:09:55 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <AANLkTi=p0bftcqPfF4j9m7FmLkDYMprFmU5z3awEcczj@mail.gmail.com>
Message-ID: <201102222009.49627.sarbalap+freshmeat@gmail.com>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

> > I have to correct myself. I applied the patch manually to my Python
> > 2.6 installation. In Python 2.6, the line you moved is number 961,
> > and I did the same change.
> 
> OK. For information, you can apply it using the Unix "patch" command,
> who can most of the time do all the work for you.

Yes, thanks, I already knew about "patch" but decided to apply the 
change manually just in case, as it belonged to a different Python 
branch.

> That's expected, it's a consequence of this point I raised earlier:
> > Note that I'm not sure why we need to wait for a further message on
> > the control channel (maybe it's part of an RFC or something...).

There's no doubt that not hanging is an improvement, but the current 
behavior somewhat defeats the purpose of an early call to "close".

To get a broader view, the test case I provided is actually part of a 
much larger program. In that program, I read lines from the Slackware 
change log, stopping when I read a line that the program already knows 
about (because it caches the change log contents). This prevents the 
program from reading more than a single line if no new entries are 
present in the change log, but having to wait for the full file defeats 
the purpose, specially on slow dial-up connections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:10:41 2011
From: report at bugs.python.org (Toshio Kuratomi)
Date: Tue, 22 Feb 2011 19:10:41 +0000
Subject: [issue11200] Addition of abiflags breaks distutils
In-Reply-To: <1297535287.04.0.13129153677.issue11200@psf.upfronthosting.co.za>
Message-ID: <1298401841.06.0.338900443583.issue11200@psf.upfronthosting.co.za>


Toshio Kuratomi <a.badger at gmail.com> added the comment:

Distribute issue opened and patch based on Antoine's comments attached.

https://bitbucket.org/tarek/distribute/issue/191/distribute-fails-unittests-on-python-32

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11200>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:12:47 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 19:12:47 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298401967.65.0.555554394794.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

We already have 3 places where a tuple is used:

socket.socket.bind
socket.create_connection
http.client.HTTPConnection

Changing this notation in smtplib for such a rarely used feature is not worth the effort, imo.
Also, I would not add two new SMTP attributes. Passing a tuple to socket.create_connection() is just fine. If you want to know the source address afterwards you can use socket.getsockname().

PS - I modified smtplib.py in meantime. Please update your local copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:20:36 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 19:20:36 +0000
Subject: [issue11086] add lib2to3/__main__.py
In-Reply-To: <1296507167.64.0.584286117272.issue11086@psf.upfronthosting.co.za>
Message-ID: <1298402436.87.0.611155090736.issue11086@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

r88503 has the patch in 3.3

Didn't both with documenting it since I only expect core devs who are debugging something with 2to3 will want to use this approach.

----------
assignee:  -> brett.cannon
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11086>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:52:42 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 19:52:42 +0000
Subject: [issue11291] poplib suppresses exception on QUIT
In-Reply-To: <1298404361.7.0.353311049952.issue11291@psf.upfronthosting.co.za>
Message-ID: <1298404361.7.0.353311049952.issue11291@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Unlike ftplib, smtplib and probably others, poplib suppresses error_proto exceptions on quit().
I'm not sure in what circumstances a POP3 server can return a negative response on QUIT but if this happens poplib should raise an exception.
Users who don't care about QUIT response can use the new close() method.
For backward compatibility patch should only be applied to Python 3.3 .

----------
files: poplib_quit.patch
keywords: patch
messages: 129114
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: poplib suppresses exception on QUIT
versions: Python 3.3
Added file: http://bugs.python.org/file20846/poplib_quit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11291>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:55:49 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 19:55:49 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298404549.91.0.851372480638.issue11199@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file20814/urllib_ftp_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:55:56 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 19:55:56 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298404556.18.0.0131778589213.issue11199@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Removed file: http://bugs.python.org/file20815/urllib_ftp_close_27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:56:31 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 19:56:31 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298404591.3.0.854093628713.issue11199@psf.upfronthosting.co.za>


Changes by Charles-Francois Natali <neologix at free.fr>:


Added file: http://bugs.python.org/file20847/urllib_ftp_close_27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 20:57:33 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 19:57:33 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1297515605.42.0.925312292331.issue11199@psf.upfronthosting.co.za>
Message-ID: <1298404653.8.0.919664074697.issue11199@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Attached are two new versions which don't wait for the end of transfer.

----------
Added file: http://bugs.python.org/file20848/urllib_ftp_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:14:35 2011
From: report at bugs.python.org (rg3)
Date: Tue, 22 Feb 2011 20:14:35 +0000
Subject: [issue11199] urllib hangs when closing connection
In-Reply-To: <1298404653.8.0.919664074697.issue11199@psf.upfronthosting.co.za>
Message-ID: <201102222114.30612.sarbalap+freshmeat@gmail.com>


rg3 <sarbalap+freshmeat at gmail.com> added the comment:

Charles-Francois Natali, Tuesday, February 22, 2011 20:57:
> Attached are two new versions which don't wait for the end of
> transfer.

I tested the one for Python 2.7 applied to Python 2.6 and it appears to 
work perfectly. Thanks for the quick fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11199>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:15:37 2011
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 22 Feb 2011 20:15:37 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298405737.14.0.965633494802.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Barry, do I correctly understand your comment to mean I should write end-to-end tests of the CLI (until reaching the already tested "meat" of smtpd), not just the CLI options parsing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:16:51 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Tue, 22 Feb 2011 20:16:51 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298405811.01.0.840693729759.issue11284@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

To elaborate on this, to my knowledge, there's no portable and reliable way to close all open file descriptors.
Even with the current code, it's still possible that some FD aren't properly closed, since getconf(SC_OPEN_MAX) often returns RLIMIT_NOFILE soft limit, which might have been lowered by the application after having opened a whole bunch of files.
Anyway, if the performance hit is too high, I think you only have two options:
- set your FD as CLOEXEC (note that it's already the case for FD used by popen and friends), and don't pass close_fds argument
- if you don't need many FD, you could explicitely set RLIMIT_NOFILE to a low value so that close_fds doesn't need to try too many FD, e.g.:
import resource
resource.setrlimit(resource.RLIMIT_NOFILE, (1024, 1024))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:19:30 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 20:19:30 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1298405970.99.0.422904317764.issue8914@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

applied in r88506

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:23:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 20:23:28 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298406208.85.0.941739128999.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I have a MacBook with 2 GB RAM.  Of course i'm a little bit messy, so an entry is half written before it comes to an ... end.  msg129091 is real life, though.

Antoine, your msg129093 patch of test_zlib.py does it (with and without fprintf(3)s).  CRC ok etc., it just works.
(Seems mmap(2) has a problem here, i would say; the mentioned bug report is from 2003, so the golden sunset watchers may need some more additional time, if you allow me that comment.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:25:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 20:25:50 +0000
Subject: [issue11292] Curses - add A_REVERSE to attributes table
In-Reply-To: <1298406350.63.0.533877508283.issue11292@psf.upfronthosting.co.za>
Message-ID: <1298406350.63.0.533877508283.issue11292@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003142.html here's a patch to add A_REVERSE attribute to attribs table.

----------
assignee: sandro.tosi
components: Documentation
files: add-a_reverse-py3k.patch
keywords: patch
messages: 129121
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Curses - add A_REVERSE to attributes table
versions: Python 3.3
Added file: http://bugs.python.org/file20849/add-a_reverse-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11292>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:28:00 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 22 Feb 2011 20:28:00 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1298406480.14.0.509827592028.issue11049@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Can we commit this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:31:05 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 22 Feb 2011 20:31:05 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298405737.14.0.965633494802.issue11260@psf.upfronthosting.co.za>
Message-ID: <20110222153059.7ddcbaef@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 22, 2011, at 08:15 PM, Xavier Morel wrote:

>Barry, do I correctly understand your comment to mean I should write
>end-to-end tests of the CLI (until reaching the already tested "meat" of
>smtpd), not just the CLI options parsing?

Given the way the __main__ is written, that's probably more thorough.  Testing
just the parsing alone would be uninteresting I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:32:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 20:32:27 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298406747.88.0.319524054417.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(That is to say: i think it's better not to assume that these boys plan to *ever* fix it.  (Though mmap(2) is not CoreAudio/AudioUnit.))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:35:40 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 20:35:40 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298406940.82.0.0659268240252.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(neologix: SIGBUS is not the same as SIGSEGV.  You know.  Thanks for this nice bug report.  Eight years is a .. time in computer programming - unbelievable, thinking of all these nervous wrecks who ever reported a bug to Apple!  Man!!!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:37:46 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Tue, 22 Feb 2011 20:37:46 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298407066.33.0.871004282657.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

neologix: even with 2 GB RAM top(1) shows more than 600 MB free memory with the 4 GB test up and running ... in an Mac OS X environment ...  Lucky me, i don't believe them a single word...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 21:57:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 20:57:42 +0000
Subject: [issue11293] Distutils - read the file when using it in
	long_description
In-Reply-To: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>
Message-ID: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003087.html here's a patch to read the contents of the file for long_description.

----------
assignee: sandro.tosi
components: Documentation
files: distutils-read-longdescr-file-py3k.patch
keywords: patch
messages: 129127
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Distutils - read the file when using it in long_description
versions: Python 3.3
Added file: http://bugs.python.org/file20850/distutils-read-longdescr-file-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11293>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:10:56 2011
From: report at bugs.python.org (dholth)
Date: Tue, 22 Feb 2011 21:10:56 +0000
Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction,
	but should according to spec
In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za>
Message-ID: <1298409056.29.0.272408574666.issue9924@psf.upfronthosting.co.za>


dholth <dholth at fastmail.fm> added the comment:

What should this option be called?

connect(strict=True) ?

----------
nosy: +dholth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:12:00 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Feb 2011 21:12:00 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298409120.08.0.611327028523.issue11288@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can anybody reproduce this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:20:11 2011
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 22 Feb 2011 21:20:11 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298409611.41.0.604278839065.issue11288@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

It works fine for me. Just did a 32-bit Python 3.2 install on a Windows 7 64-bit machine and IDLE works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:20:44 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 21:20:44 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1298409644.4.0.497914449681.issue10924@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I will look at the patch.

----------
assignee: jafo -> brett.cannon
nosy: +brett.cannon
stage: committed/rejected -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:23:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Feb 2011 21:23:04 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298409784.53.0.410672954296.issue11260@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> As I said, my only intention here is be to document 
> (and argparsify/formalize) what is already there.

In a handful of cases, that would be useful; however,
for the most part, these APIs were undocumented for
a reason.  Some of the command-line interfaces were
slapped together without much of a design effort; some
were little more than quick-and-dirty ad-hoc tests.
It would be a mistake to "document and formalize"
accidental mini-apps.

There's no harm in adding --help or a usage example,
but please avoid making behavior guarantees that we
really don't want to have to live with.

Only "document and formalize" the parts that are well
thought out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:39:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 21:39:16 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298406208.85.0.941739128999.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298410753.3757.39.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, your msg129093 patch of test_zlib.py does it (with and
> without fprintf(3)s).  CRC ok etc., it just works.

Indeed, and it also seems to work on the buildbot. I will commit the
patch soon. Thanks for your help!

> (Seems mmap(2) has a problem here, i would say; the mentioned bug
> report is from 2003, so the golden sunset watchers may need some more
> additional time, if you allow me that comment.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:44:28 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 22 Feb 2011 21:44:28 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298411068.15.0.0883426188399.issue11288@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Matthew: please run "python -v", and attach any output it makes to this report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:47:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Feb 2011 21:47:08 +0000
Subject: [issue10924] Adding salt and Modular Crypt Format to crypt library.
In-Reply-To: <1295247997.49.0.7150272714.issue10924@psf.upfronthosting.co.za>
Message-ID: <1298411228.28.0.440382612523.issue10924@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The patch didn't even import as-is or past the tests, but I tweaked it so it did (and made method() just an attribute on the module).

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10924>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:51:26 2011
From: report at bugs.python.org (Matthew Funke)
Date: Tue, 22 Feb 2011 21:51:26 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298411486.66.0.110227754056.issue11288@psf.upfronthosting.co.za>


Matthew Funke <go4tli at gmail.com> added the comment:

Here's the output, in its entirety:

-------------------------

C:\Python32>python -v
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 22:59:41 2011
From: report at bugs.python.org (Matthew Funke)
Date: Tue, 22 Feb 2011 21:59:41 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298411981.56.0.811884783885.issue11288@psf.upfronthosting.co.za>


Matthew Funke <go4tli at gmail.com> added the comment:

I also tried uninstalling, re-downloading the MSI, and re-installing, but no joy.  Thank you for any insight you can lend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:01:50 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 22 Feb 2011 22:01:50 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298412110.57.0.709159670436.issue11286@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Antoine's patch looks good to me.

Given the assumptions in the memoryview code, disallowing NULL for the buf pointer sounds like the right thing to do, even for zero-length buffers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:20:44 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 22 Feb 2011 22:20:44 +0000
Subject: [issue11294] Locale - update & uniform ERA_*_FMT doc
In-Reply-To: <1298413244.48.0.422350536879.issue11294@psf.upfronthosting.co.za>
Message-ID: <1298413244.48.0.422350536879.issue11294@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-February/003004.html here's a patch to:

- clarify ERA_D_FMT is for date
- uniform the way {ERA_}<tag> descriptions are written (are not a native to know if it's better 'a date' or 'dates' (same goes for 'time'))
- add ERA_T_FMT

----------
assignee: sandro.tosi
components: Documentation
files: locale_era_dt-py3k.patch
keywords: patch
messages: 129139
nosy: sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Locale - update & uniform ERA_*_FMT doc
versions: Python 3.3
Added file: http://bugs.python.org/file20851/locale_era_dt-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11294>
_______________________________________

From report at bugs.python.org  Tue Feb 22 23:37:04 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Feb 2011 22:37:04 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298414224.07.0.352317723657.issue11277@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88511 (3.3) and r88514 (3.2).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:04:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Feb 2011 23:04:20 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <1298415860.12.0.822461359575.issue11283@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:04:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Feb 2011 23:04:53 +0000
Subject: [issue11282] unittest document not keep consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298415893.28.0.085323396358.issue11282@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:05:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Feb 2011 23:05:14 +0000
Subject: [issue11282] unittest document not keep consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298415914.19.0.339507363487.issue11282@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Wed Feb 23 00:46:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Feb 2011 23:46:03 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1298418363.3.0.595999193098.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I started to commit some parts of the huge patch:

r88515: Mark PyWin_FindRegisteredModule() as private
r88516: Remove unused argument of _PyImport_GetDynLoadFunc()
r88517 (3.3), r88518 (3.2): document encoding used by import functions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Feb 23 01:22:26 2011
From: report at bugs.python.org (Jonathan Hayward)
Date: Wed, 23 Feb 2011 00:22:26 +0000
Subject: [issue11295] On Windows,
	Python crashes on ANSI / Windows-formatted source files
In-Reply-To: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>
Message-ID: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>


New submission from Jonathan Hayward <jonathan.hayward at pobox.com>:

So far as I can tell, Python 2.7 crashes on at least some ANSI / Windows \r\n-delimited source files. More specifically, as invoked by Apache as a CGI script, the source file line:

import cgi

generated an error logged by Apache, complaining that the module "cgi\r" couldn't be imported.

Email sent as follows:

--

Today I was visiting with a friend and installing OSS on his computer. On an x86_64 Windows 7 box, he had already installed Apache, and I installed Python with a python.org installer. I opened up Notepad and created a "Hello world" Python CGI script, put it in the cgi-bin directory, saw it crash, and looked in the logs.

The log message complained that I had tried to "import cgi\r": in other words, Python on Windows was choking because the file I made in Notepad used "\r\n" for line breaks. (The equivalent script made with vim, and presumably "\n" for line breaks worked predictably.)

Isn't it a defect/design flaw for Python on Windows to choke on "\r\n"-separated files? Should I file a bug, or is this a side effect of decisions that are now non-negotiable? (I wasn't thrilled, after trying to sell my friend on the idea that Python is a good language with a low barrier to entry, to find that it choked on a Notepad-edited "Hello world!" CGI script.)

----------
components: Interpreter Core
messages: 129142
nosy: JonathanHayward
priority: normal
severity: normal
status: open
title: On Windows, Python crashes on ANSI / Windows-formatted source files
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11295>
_______________________________________

From report at bugs.python.org  Wed Feb 23 01:24:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 00:24:40 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1298420680.41.0.118777886144.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r88519: Mark _PyImport_FindBuiltin() argument as constant
r88520: Add PyModule_GetNameObject()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Feb 23 01:41:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 00:41:02 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298421662.82.0.266745114564.issue11272@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch to fix input() on Windows: strip also \r.

----------
keywords: +patch
Added file: http://bugs.python.org/file20852/input_rn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:02:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Feb 2011 01:02:33 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298422953.84.0.0343381540324.issue11272@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Is it possible to add some tests for input()?

Also the patch uses tabs instead of spaces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:10:29 2011
From: report at bugs.python.org (Carl Chenet)
Date: Wed, 23 Feb 2011 01:10:29 +0000
Subject: [issue11296] Possible error in What's new in Python 3.2 : duplication
	of rsplit() mention
In-Reply-To: <1298423429.64.0.239185638784.issue11296@psf.upfronthosting.co.za>
Message-ID: <1298423429.64.0.239185638784.issue11296@psf.upfronthosting.co.za>


New submission from Carl Chenet <chaica at ohmytux.com>:

Hi,

Could the rsplit() method be mentioned mistakenly two times in the following sentence of the current What's new in Python 3.2 ?

"The fast-search algorithm in stringlib is now used by the split(), rsplit(), splitlines() and replace() methods on bytes, bytearray and str objects. Likewise, the algorithm is also used by rfind(), rindex(), rsplit() and rpartition()."

Regards,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 129146
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: Possible error in What's new in Python 3.2 : duplication of rsplit() mention
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11296>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:11:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 01:11:06 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298423466.25.0.989389940533.issue11272@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

C:\Python32>python
    Python 3.2 ... on win32
    >>> import sys
    >>> for line in sys.stdin:
    ...     print(repr(line))
    ...
    hello
    'hello\r\n'
    ^Z

Oh yes, I confirm that there is a second bug: sys.stdin doesn't translate \r\n to \n, whereas sys.stdin is a text file.

Attached patch fixes both issues.

> Is it possible to add some tests for input()?

input() has already tests, but the bug was not detected because the test uses a mockup, not a subprocess. Moreover, I don't think that it is possible to test input() for the TTY case. It is not easy to test a TTY, especially on Windows.

If anyone knows how to reproduce the two bugs with a short Python script, I can try to convert it into a test.

> Also the patch uses tabs instead of spaces.

Yeah, I hate producing patches on Windows. Fixed in the new patch (prepared on Linux).

----------
Added file: http://bugs.python.org/file20853/issue11272.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:11:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 01:11:32 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298423492.84.0.918578101595.issue11272@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20852/input_rn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:17:20 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 23 Feb 2011 01:17:20 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1298423840.52.0.669359075743.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: amaury.forgeotdarc -> krisvale
keywords: +buildbot -easy, patch
nosy: +krisvale -amaury.forgeotdarc
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:19:28 2011
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 23 Feb 2011 01:19:28 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1298393614.88.0.809270711663.issue6549@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=_ssUckcRbBHHr+v3cJt7YPtebWAfAJ7vxLTZx@mail.gmail.com>


Guilherme Polo <ggpolo at gmail.com> added the comment:

> I have been working with the ttk module (Windows XP, Python 3.1) and have encountered some specific issues with ttk.Style() not fully propagating the style into the widget. ?In my particular case, there seem to be issues with setting style in TCombobox and TEntry. ?The biggest issue is that you can't change the style of the ttk.Combobox popdown. ?Style can be set in the top window, but not using all methods, but nothing works for the popdown.

Is this related to the initial report ?

Setting styles may be problematic, and I don't think there is
something fully describing all the things in ttk.Style (Tcl, Python
and other languages) yet. There is a .tcl script that performs a lot
of styling here:
http://tktable.git.sourceforge.net/git/gitweb.cgi?p=tktable/tile-qt;a=tree;f=library;hb=HEAD

It might help you, but I can't confirm. Good luck, but continue this
conversation on a forum if it is not related to the initial report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6549>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:19:30 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 23 Feb 2011 01:19:30 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1298423970.43.0.4351140862.issue4111@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: dmalcolm -> dino.viehland
nosy: +dino.viehland
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:28:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 23 Feb 2011 01:28:54 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1298424534.31.0.45701086588.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: krisvale -> amaury.forgeotdarc
keywords: +easy, patch -buildbot
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:31:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 01:31:22 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1298424682.07.0.660981975518.issue10142@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Jesus, perhaps you can address Amaury's comments by uploading a new patch?

----------
assignee: amaury.forgeotdarc -> 
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:32:34 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Wed, 23 Feb 2011 01:32:34 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298424754.0.0.63892299787.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Ok, I changed to a single parameter matching socket.create_connection().

I made my best to update tests and docs, but I don't have a clue if it is right.

----------
Added file: http://bugs.python.org/file20854/smtp_lib_source_address.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:33:03 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Wed, 23 Feb 2011 01:33:03 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298424783.68.0.7711118541.issue11281@psf.upfronthosting.co.za>


Changes by Paulo Scardine <paulo at scardine.com.br>:


Removed file: http://bugs.python.org/file20844/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:39:28 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 01:39:28 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298425168.99.0.885544533035.issue11286@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 02:49:35 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 23 Feb 2011 01:49:35 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298425775.41.0.702016082885.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Follow my comments:

> +                 source_address=('', 0)):

Make that default to None instead and pass it as-is to socket.create_connection().

> +        self.source_address = source_address

There's no need to store the source address as an instance attribute. 
Just pass it as-is to socket.create_connection() in __init__ and connect methods and then get rid of it.


I think source_address no longer makes sense in UNIX sockets / LMTP class. 
Or at least, this is what I get if I try to bind() a UNIX socket:

>>> import socket
>>> sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> sock.bind(("", 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in bind
TypeError: argument must be string or read-only character buffer, not tuple
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Wed Feb 23 03:58:24 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Wed, 23 Feb 2011 02:58:24 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298429904.66.0.851520715183.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

> There's no need to store the source address as an instance attribute.
> Just pass it as-is to socket.create_connection() in __init__ and 
> connect methods and then get rid of it.

Ok, what if user initialize with something like smtplib.SMTP(source_address=('200.165.12.1', 25)) and calls connect without source_address?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Wed Feb 23 04:20:52 2011
From: report at bugs.python.org (s7v7nislands)
Date: Wed, 23 Feb 2011 03:20:52 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.pepen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298431252.24.0.634496138498.issue11284@psf.upfronthosting.co.za>


s7v7nislands <s7v7nislands at gmail.com> added the comment:

thanks, neologix.

I think should put this hint in python doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Wed Feb 23 05:25:38 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Feb 2011 04:25:38 +0000
Subject: [issue11049] add tests for test.support
In-Reply-To: <1296241531.97.0.670133219758.issue11049@psf.upfronthosting.co.za>
Message-ID: <1298435138.64.0.991710432608.issue11049@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that the docs for import_fresh_module are confusing.  The code says there are sanity checks in test_heapq and test_warnings, so that code could presumably be used as a model for someone to develop a more complete stand-alone test (I haven't looked for that code myself).  I'm not sure why we have both import_fresh_module and CleanImport, since they seem to do similar things (but differently!)

I started making comments on other tests and then realized it wasn't much more work to just update them myself.  Extended patch attached.

----------
Added file: http://bugs.python.org/file20855/test_support.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11049>
_______________________________________

From report at bugs.python.org  Wed Feb 23 06:53:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 05:53:20 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298440400.38.0.172177487248.issue11286@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am not sure PyUnicode_Decode() should treat NULL as an empty string.  Decoding empty string is wasteful and if the caller knows that the string is empty, it should skip decoding because the result is empty.  Providing *two* ways to invoke expensive PyUnicode_Decode() to produce a known result is promoting inefficient coding.

This particular issue I would fix with something like attached issue11286.diff.

----------
Added file: http://bugs.python.org/file20856/issue11286.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:21:23 2011
From: report at bugs.python.org (Xavier Morel)
Date: Wed, 23 Feb 2011 07:21:23 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298445683.97.0.335534363184.issue11260@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> Only "document and formalize" the parts that are well thought out.

I don't believe I have the knowledge, right or ability to make that call for any module or package but a pair of extremely obvious ones (http.server seems a pretty good candidate as it's documented in the module doc, and is just missing a CLI help). Should I create a bug and nosy the people who have been involved in the module to get their opinion for each one? (as with this one, but maybe with a different wording/initial proposal) For this one, David expresses concerns on the stability on the interface (and the point of the idea), you express even bigger concerns with the idea itself and more generally modules-as-scripts in the stdlib (not their existence so much as their official support, which full documentation would imply, if I didn't misunderstand you), and Barry seems to okay the idea as long as an extensive test suite is created beforehand to ensure there is no regression, is that sufficient to go ahead with more work and defer the final decision for when that will be done?

Also, if this is to become an actual project if the smtpd stuff ever reaches fruition (though not necessarily a big or impactful one), should there be a meta-bug? (I know they're used in many bugzilla projects and I see the tracker handles dependencies)

> There's no harm in adding --help or a usage example, but please avoid making behavior guarantees that we really don't want to have to live with.

I'm not sure what that results in: for "quick hacks" which are not to be officially supported, does this mean fixing the CLI (adding a help for tools missing one) is OK but no more? Is an argparse switch still acceptable? Tests for the CLI tool? I'm guessing documentation in the module would definitely be off limits for those, is my interpretation correct? And again, who would be allowed to make the call on which modules-as-scripts may be considered supported, and can't be?

With this one, I created separate patches for the documentation and the CLI parsing alterations, which would allow merging the CLI without adding it to the official documentation (which would I think imply a lack of official support), would that be OK for future works, if this one pans out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:23:50 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 23 Feb 2011 07:23:50 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298445830.27.0.159563108083.issue11288@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
keywords: +3.2regression

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 08:55:44 2011
From: report at bugs.python.org (Bartosz)
Date: Wed, 23 Feb 2011 07:55:44 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298447744.78.0.970850873526.issue11288@psf.upfronthosting.co.za>


Bartosz <sspamerek at gmail.com> added the comment:

I've got the same situation. Windows 7 (32bit) python-3.2.msi installations puts through, but when I try to lunch python appears error :

Fatal Python error: Py_Initialize: unable to load the file system codec
LookupError: no codec search functions registered: can't find encoding

----------
nosy: +BWY

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 09:22:58 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 08:22:58 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298440400.38.0.172177487248.issue11286@psf.upfronthosting.co.za>
Message-ID: <4D64C3DE.4050408@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> I am not sure PyUnicode_Decode() should treat NULL as an empty string.

Definitely not. That would hide programming errors.

----------
nosy: +lemburg
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 10:20:36 2011
From: report at bugs.python.org (Duncan Booth)
Date: Wed, 23 Feb 2011 09:20:36 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298452836.94.0.63080690997.issue11272@psf.upfronthosting.co.za>


Duncan Booth <kupuguy at gmail.com> added the comment:

> If anyone knows how to reproduce the two bugs with a short Python
> script, I can try to convert it into a test.

If you don't mind kicking off some sub-processes then here's a script that shows the bugs.

I couldn't figure out how to do a script that would work on Python 3.1 but fail on Python 3.2, because I think to show the problem you have to use the shell to pipe data and Popen on Python 3.1 quotes the pipe character.

----------
Added file: http://bugs.python.org/file20857/stdintests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:22:37 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2011 10:22:37 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

Attaching a documentation patch.

----------
assignee: rhettinger
files: chainmap.diff
keywords: patch
messages: 129161
nosy: rhettinger
priority: low
severity: normal
status: open
title: Make ChainMap() public in the collections module.
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20858/chainmap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:35:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 10:35:09 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298457309.04.0.812009337939.issue11297@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is nice, but IMO there is some information lacking, e.g.:
- when an underlying mapping is mutated, does the ChainMap get updated too?
- does it work with arbitrary mappings or only with dicts or dicts subclasses?

I think new_child() isn't very useful. It seems two specialized for a one-liner. Ditto for parents().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:35:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 10:35:22 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298457322.59.0.862284014453.issue11297@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

("too specialized", sorry)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:38:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 10:38:53 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <4D64C3DE.4050408@egenix.com>
Message-ID: <1298457530.3710.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I am not sure PyUnicode_Decode() should treat NULL as an empty string.
> 
> Definitely not. That would hide programming errors.

Well, this could break some third-party code.

----------
title: Some "trivial" python 2.x pickles fails to load in	Python 3.2 -> Some "trivial" python 2.x pickles fails to load in Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:42:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 23 Feb 2011 10:42:24 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298457744.01.0.848269503581.issue11288@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Works fine for me (Windows 7, 64-bit, 32-bit Python-3.2). I do have the
plain US English version. Do you have localized versions?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:42:56 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 10:42:56 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298457530.3710.3.camel@localhost.localdomain>
Message-ID: <4D64E4AE.804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>>> I am not sure PyUnicode_Decode() should treat NULL as an empty string.
>>
>> Definitely not. That would hide programming errors.
> 
> Well, this could break some third-party code.

If that code passes NULL in as buffer s, that 3rd party code is
already broken and the patch would hide this fact.

----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:44:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 10:44:44 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <4D64E4AE.804@egenix.com>
Message-ID: <1298457880.3710.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine Pitrou wrote:
> > 
> > Antoine Pitrou <pitrou at free.fr> added the comment:
> > 
> >>> I am not sure PyUnicode_Decode() should treat NULL as an empty string.
> >>
> >> Definitely not. That would hide programming errors.
> > 
> > Well, this could break some third-party code.
> 
> If that code passes NULL in as buffer s, that 3rd party code is
> already broken and the patch would hide this fact.

Why broken? Passing NULL as a pointer and 0 as the length doesn't sound
"broken".
Other APIs such as PyString_FromStringAndSize() allow exactly this
convention.

----------
title: Some "trivial" python 2.x pickles fails to load in	Python 3.2 -> Some "trivial" python 2.x pickles fails to load in Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 11:58:36 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 10:58:36 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298457880.3710.5.camel@localhost.localdomain>
Message-ID: <4D64E85A.90908@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Antoine Pitrou wrote:
>>>
>>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>>
>>>>> I am not sure PyUnicode_Decode() should treat NULL as an empty string.
>>>>
>>>> Definitely not. That would hide programming errors.
>>>
>>> Well, this could break some third-party code.
>>
>> If that code passes NULL in as buffer s, that 3rd party code is
>> already broken and the patch would hide this fact.
> 
> Why broken? Passing NULL as a pointer and 0 as the length doesn't sound
> "broken".
> Other APIs such as PyString_FromStringAndSize() allow exactly this
> convention.

Right. They allow for this because those are object constructors
that allow for creating objects without pre-defined content
(hence the NULL). The 0 length feature is just a side-effect,
not the main reason why we allow NULLs to be passed in as
content buffer to those constructors.

PyUnicode_Decode() et al. are conversion functions and these
require valid content to work on. Passing in a NULL pointer
does not fit that specification and so allowing for this
would hide programming errors.

E.g. an application using PyUnicode_Decode()
might have hit a C lib error and forgets to check the pointer
for NULL. It then calls PyUnicode_Decode() and the application
continues happily without reporting the error.

That's a broken application.

----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:03:26 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 11:03:26 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298459006.98.0.356026559578.issue11285@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Hmm.  Note that this problem does *not* occur if i don't install Python but run it in place, e.g. 'cd Lib/test; ../../python.exe -m test -v -uall test_iter' works just perfect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:11:21 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 11:11:21 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298459481.7.0.0920255293338.issue11285@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

... and the problem is all gone with 8c2935f180fa/r88525.
So i'm faitful now and close this early alpha-stage problem.
One of the nosy ones may add a nice description, re-open it or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:13:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 11:13:28 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298459608.54.0.930442105356.issue11285@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(.. should close it, then.)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:16:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 11:16:51 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <4D64E85A.90908@egenix.com>
Message-ID: <1298459807.3710.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> PyUnicode_Decode() et al. are conversion functions and these
> require valid content to work on. Passing in a NULL pointer
> does not fit that specification and so allowing for this
> would hide programming errors.

"Valid content" doesn't mean a lot when the length is 0.
What is a valid 0-length string compared to an invalid one?
What if the pointer is non-NULL but segfaults when trying to dereference
it? Is it "valid"?

Moreover, malloc() is allowed by POSIX to return NULL when called with a
0 length:

        If size is 0, either a null pointer or a unique pointer that can
        be successfully passed to free() shall be returned.

(http://www.opengroup.org/onlinepubs/007904875/functions/malloc.html)

... which means that such a pointer can then, depending on the platform,
get passed (legitimately) to PyUnicode_Decode().

So, IMO, practicality beats purity here. Especially since it is bound to
land in a bugfix release (3.2.1), which users don't expect to produce
regressions in their own code.

OTOH, I agree that a NULL pointer combined with non-0 length could
produce an explicit error.

----------
title: Some "trivial" python 2.x pickles fails to load in	Python 3.2 -> Some "trivial" python 2.x pickles fails to load in Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:18:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 11:18:34 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298459914.33.0.327812068642.issue11285@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record:

> e.g. 'cd Lib/test; ../../python.exe -m test -v -uall test_iter' works
> just perfect.

You don't need to "cd". Just "./python -m test (etc.)".
See http://docs.python.org/devguide/runtests.html for more information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:18:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 11:18:48 +0000
Subject: [issue11285] io.py standart stream setup crash
In-Reply-To: <1298378948.27.0.148079828591.issue11285@psf.upfronthosting.co.za>
Message-ID: <1298459928.4.0.817620708442.issue11285@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11285>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:32:01 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 11:32:01 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298459807.3710.15.camel@localhost.localdomain>
Message-ID: <4D64F02D.3010504@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> PyUnicode_Decode() et al. are conversion functions and these
>> require valid content to work on. Passing in a NULL pointer
>> does not fit that specification and so allowing for this
>> would hide programming errors.
> 
> "Valid content" doesn't mean a lot when the length is 0.
> What is a valid 0-length string compared to an invalid one?
> What if the pointer is non-NULL but segfaults when trying to dereference
> it? Is it "valid"?
> 
> Moreover, malloc() is allowed by POSIX to return NULL when called with a
> 0 length:
> 
>         If size is 0, either a null pointer or a unique pointer that can
>         be successfully passed to free() shall be returned.
> 
> (http://www.opengroup.org/onlinepubs/007904875/functions/malloc.html)
> 
> ... which means that such a pointer can then, depending on the platform,
> get passed (legitimately) to PyUnicode_Decode().

... and Python has for years made sure that PyMem_Malloc() et al.
return a non-NULL pointer when passed a size 0 value (see pymem.h for
details), since the above was a really poor design choice.

A lot of Python code relies on those functions returning NULL only
in case of an error.

> So, IMO, practicality beats purity here. Especially since it is bound to
> land in a bugfix release (3.2.1), which users don't expect to produce
> regressions in their own code.

Nope. Your suggestion would be a new feature and those are not
allowed in patch level releases.

I'm -1 on the idea for the reasons already stated.

----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:37:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 11:37:23 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <4D64F02D.3010504@egenix.com>
Message-ID: <1298461039.3710.32.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > So, IMO, practicality beats purity here. Especially since it is bound to
> > land in a bugfix release (3.2.1), which users don't expect to produce
> > regressions in their own code.
> 
> Nope. Your suggestion would be a new feature and those are not
> allowed in patch level releases.

What new feature are you talking about? I think you misunderstood the
actual issue: NULL as an empty string *worked* in 3.1 and that's why we
have a regression with _pickle here.

So, in the end, you are the one proposing a change in actual behaviour,
while I'm trying to minimize changes (and breakage).

----------
title: Some "trivial" python 2.x pickles fails to load in	Python 3.2 -> Some "trivial" python 2.x pickles fails to load in Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:42:53 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 11:42:53 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>


New submission from blokeley <blokeley at gmail.com>:

`python -m unittest discover` caught me out. 

I had a test module called `test-foo.py` and no test was loaded.

When I renamed to `test_foo.py` it worked.

The documentation says "For a project?s tests to be compatible with test discovery they must all be importable".

I didn't realise that test-foo would not be importable. Could the documentation say "For a project?s tests to be compatible with test discovery they must all be importable, so ensure that the module names are valid Python identifiers."

Stackoverflow question is here: http://stackoverflow.com/questions/5088960/python-unittest-discovery-does-not-discover-tests

----------
assignee: docs at python
components: Documentation
messages: 129176
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: unittest discovery needs better explanation
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:52:05 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 11:52:05 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298461925.48.0.178528667706.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I append a doc_lib_mmap.patch which may be helpful for those poor creatures who plan to write Python scripts for Mac OS X.  (It may be a useful add-on anyway.)

----------
Added file: http://bugs.python.org/file20859/doc_lib_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Feb 23 12:55:39 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 23 Feb 2011 11:55:39 +0000
Subject: [issue11224] 3.2: tarfile.getmembers causes 100% cpu usage on Windows
In-Reply-To: <1297879946.93.0.216957943262.issue11224@psf.upfronthosting.co.za>
Message-ID: <1298462139.78.0.117093059252.issue11224@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Thanks for your great report. This is fixed now in r88528 (py3k) and r88529 (release32-maint).

----------
keywords: +3.2regression
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11224>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:06:18 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 23 Feb 2011 12:06:18 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298462778.69.0.593005246127.issue11298@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sounds like a good change to the docs. Care to provide a patch?

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:08:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Feb 2011 12:08:31 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298462911.99.0.517529405488.issue11298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:11:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 12:11:59 +0000
Subject: [issue11272] input() has trailing carriage return on windows
In-Reply-To: <1298303304.94.0.0754812016321.issue11272@psf.upfronthosting.co.za>
Message-ID: <1298463119.15.0.21916122216.issue11272@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in 3.3 (r88530) and 3.2 (r88531). Others versions are not affected.

Thanks Duncan Booth, I added tests based on your stdintests.py script. I used directly stdin argument of Popen() instead of using cmd.exe to create the pipe (which is not portable).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11272>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:14:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 12:14:35 +0000
Subject: [issue10830] PyUnicode_FromFormatV("%c") doesn't support non-BMP
	characters on narrow build
In-Reply-To: <1294191792.83.0.0600420394952.issue10830@psf.upfronthosting.co.za>
Message-ID: <1298463275.91.0.610987873531.issue10830@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in 3.2 too (r88532).

----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10830>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:21:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 12:21:28 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298463688.8.0.0154248567283.issue11277@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


Removed file: http://bugs.python.org/file20859/doc_lib_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:29:04 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 23 Feb 2011 12:29:04 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298464144.0.0.809625979209.issue11286@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

What if we commit Antoine patch for 3.2.x, and the "correct" patch for py3k trunk?.

I am actually +1 to Marc-Andre. I feel in my guts that the provided patch is hidding a deeper issue. But avoiding surprises for third parties in 3.2.1 is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:30:02 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Feb 2011 12:30:02 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1298464202.35.0.374851118138.issue2650@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Added file: http://bugs.python.org/file20860/test_re.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:30:07 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Feb 2011 12:30:07 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1298464207.48.0.325262918266.issue2650@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file20389/test_re.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:39:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 12:39:28 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298461039.3710.32.camel@localhost.localdomain>
Message-ID: <1298464763.3710.43.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Nope. Your suggestion would be a new feature and those are not
> > allowed in patch level releases.
> 
> What new feature are you talking about? I think you misunderstood the
> actual issue: NULL as an empty string *worked* in 3.1

And, with a very high likelihood, it also worked in 2.7, 2.6, etc.
So, feel free to suggest a compatibility breakage in 3.3 if you think
that's better (*), but I don't think that's acceptable in 3.2.1, where
the issue should be fixed anyway.

(*) which really means "provide a patch" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:44:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 12:44:35 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298465075.02.0.266967052498.issue11277@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Sorry, i've got that kid running around which sometimes doesn't know what it is doing.  But this documentation patch may really be a help.  It's my first doc-patch, so it surely needs to be revised, if interest exists in such a patch for mmap at all, say.  Thanks for your understanding.

----------
Added file: http://bugs.python.org/file20861/doc_lib_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Wed Feb 23 13:52:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 12:52:58 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1298465578.51.0.364598339196.issue3080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This new failure is perhaps related:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/572/steps/test/logs/stdio


======================================================================
FAIL: test_module (test.test_reprlib.LongReprTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_reprlib.py", line 237, in test_module
    "<module '%s' from '%s'>" % (areallylongpackageandmodulenametotestreprtruncation.__name__, areallylongpackageandmodulenametotestreprtruncation.__file__))
AssertionError: "<module 'areallylongpackageandmodulenametotestreprtruncation.areallylongpackage [truncated]... != "<module 'areallylongpackageandmodulenametotestreprtruncation.areallylongpackage [truncated]...
Diff is 825 characters long. Set self.maxDiff to None to see it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:10:35 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 13:10:35 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298466635.76.0.129953552414.issue11286@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Please go with Alexander's solution of fixing the higher level code rather than silently trying to introduce a new feature in PyUnicode_Decode() that hides programming errors.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:14:43 2011
From: report at bugs.python.org (David Beazley)
Date: Wed, 23 Feb 2011 13:14:43 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298466883.09.0.982637971051.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Bump.  This is still broken in Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:16:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 13:16:29 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298466635.76.0.129953552414.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298466986.3710.51.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please go with Alexander's solution of fixing the higher level code
> rather than silently trying to introduce a new feature in
> PyUnicode_Decode() that hides programming errors.

I'm sorry, I'm perfectly fine with my own patch, so someone else will
have to propose an alternative patch if they want you. I am certainly
not at your disposal for any "orders" you might give :)

Remember, this is open source, so active contributors have the last say,
not by-standers. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:18:05 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 13:18:05 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298467085.09.0.511905272218.issue11298@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

Will do but I haven't submitted a patch before and it's impossible to tell from python.org/dev whether to use the svn or hg repositories.

If possible, please just let me know the URL of the hg repository against which I should make the patch (I don't currently have an svn client).

I tried using hg convert on http://svn.python.org/projects/python/branches/py3k but my company firewall blocked that from working (too many HTTP requests per minute).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:30:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 23 Feb 2011 13:30:42 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298467842.15.0.582463268528.issue11298@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

http://code.python.org/hg/branches/py3k/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:30:46 2011
From: report at bugs.python.org (Bartosz)
Date: Wed, 23 Feb 2011 13:30:46 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298467846.81.0.423455624968.issue11288@psf.upfronthosting.co.za>


Bartosz <sspamerek at gmail.com> added the comment:

I've got English version too. Python is 32 bit and operating system is also 32 bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:35:30 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 23 Feb 2011 13:35:30 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298464144.0.0.809625979209.issue11286@psf.upfronthosting.co.za>
Message-ID: <4D650D1F.8000207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jes?s Cea Avi?n wrote:
> 
> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
> 
> What if we commit Antoine patch for 3.2.x, and the "correct" patch for py3k trunk?.
> 
> I am actually +1 to Marc-Andre. I feel in my guts that the provided patch is hidding a deeper issue. But avoiding surprises for third parties in 3.2.1 is a good idea.

Jesus, could you please check whether Alexander's solution fixes
the problem ?

Thanks.

----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:37:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 13:37:20 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298468240.64.0.432470497232.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, I hadn't seen Alexander's patch. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 14:42:04 2011
From: report at bugs.python.org (Bartosz)
Date: Wed, 23 Feb 2011 13:42:04 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298468524.88.0.882739309882.issue11288@psf.upfronthosting.co.za>


Bartosz <sspamerek at gmail.com> added the comment:

I have found a problem and sollution:

previously I have used Python 2.x and when I removed that version and next installed Python32,  PYTHONPATH in system variabled indicated still to Python2.x. Removing all python paths to old version solved the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:00:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 14:00:38 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298469638.92.0.863735868454.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

So, about Alexander's patch:
- it lacks a test
- it doesn't solve the issue with PyUnicode_Decode's confusing error message when a NULL is passed ("ValueError: operation forbidden on released memoryview object"); if we want to disallow NULL, we should have a clean error message

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:18:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 14:18:08 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1298470688.14.0.0604886999909.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This new failure is perhaps related: (...) test_reprlib

Ah yes, yesterday, I tried to remember which test was impacted by the module change, but all tests passed on Linux. Anyway, it's now fixed by r88533.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:23:14 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 14:23:14 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298470994.14.0.309031278513.issue11298@psf.upfronthosting.co.za>


Changes by blokeley <blokeley at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file20862/py3k_rev9921_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:24:26 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 14:24:26 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298471066.96.0.598762982149.issue11298@psf.upfronthosting.co.za>


Changes by blokeley <blokeley at gmail.com>:


Removed file: http://bugs.python.org/file20862/py3k_rev9921_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:28:00 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 14:28:00 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298471280.29.0.770236936804.issue11298@psf.upfronthosting.co.za>


Changes by blokeley <blokeley at gmail.com>:


Added file: http://bugs.python.org/file20863/py3k_rev9921_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:29:14 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 23 Feb 2011 14:29:14 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298471354.82.0.564722680093.issue11298@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks blokely, looks good. Needs applying to 2.7 / 3.2 and 3.3 branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:29:20 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Feb 2011 14:29:20 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298471360.43.0.99090108645.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If a patch had been proposed it probably would have gotten in to 3.2.  Maybe someone (perhaps you?) will find the time before 3.2.1.

Someone has decided to work on the bz2 rewrite, by the way (issue 5863).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:37:11 2011
From: report at bugs.python.org (David Beazley)
Date: Wed, 23 Feb 2011 14:37:11 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298471831.29.0.128434582689.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

If I can find some time, I may took a look at this.   I just noticed that similar problems arise trying to wrap TextIOWrapper around the file-like objects returned by urllib.request.urlopen as well.

In the big picture, some discussion of what it means to be "file-like" might be in order.   If something is "file-like" and binary, should that always imply that I be able to wrap a TextIOWrapper object around it in order to encode/decode text?  I would argue "yes", but I'd be curious to know what others think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:39:38 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 14:39:38 +0000
Subject: [issue8289] multiprocessing.Process.__init__ pickles all arguments
In-Reply-To: <1270220809.31.0.384012166997.issue8289@psf.upfronthosting.co.za>
Message-ID: <1298471978.67.0.50574792681.issue8289@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8289>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:42:59 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 14:42:59 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298472179.27.0.922635176967.issue10791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

What is the problem with Python 3.2? It works correctly here:

$ cat bla.txt
bli
blo
bla
$ gzip bla.txt 
$ ./python 
Python 3.3a0 (unknown, Feb 23 2011, 13:03:50) 
>>> import gzip, io
>>> f = io.TextIOWrapper(gzip.open("bla.txt.gz"),encoding='ascii')
>>> f.read()
'bli\nblo\nbla\n'

If someone added Python 3.2 in the Versions field because of an issue with bz2: please open a new issue instead.

----------
nosy: +haypo
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:46:42 2011
From: report at bugs.python.org (David Beazley)
Date: Wed, 23 Feb 2011 14:46:42 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298472402.82.0.198184911676.issue10791@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

Python 3.2 (r32:88445, Feb 20 2011, 21:51:21) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> import io
>>> f = io.TextIOWrapper(gzip.open("file.gz"),encoding='latin-1')
>>> f.readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: read1
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:54:01 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 14:54:01 +0000
Subject: [issue9276] pickle should support methods
In-Reply-To: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za>
Message-ID: <1298472841.36.0.379123010591.issue9276@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I also miss being able to pickle unbound methods on Python 3. I don't think there's an interest in pickling the actual code objects. In my opinion, unbound methods should be pickled exactly like all the other Python definitions, such as bound methods, top-level functions, and classes: They should be pickled by name.

IIUC, the challenge is how to figure out on which class an unbound method is defined. I'm using the term "unbound method" colloquially, I know it's implemented as a function. So perhaps Python needs to be changed to give unbound methods some attribute that will tell on which class they're defined?

----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9276>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:54:15 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 14:54:15 +0000
Subject: [issue9276] pickle should support methods
In-Reply-To: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za>
Message-ID: <1298472855.57.0.562321641944.issue9276@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9276>
_______________________________________

From report at bugs.python.org  Wed Feb 23 15:56:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Feb 2011 14:56:01 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298472961.29.0.86490814885.issue10791@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, a clear definition of the minimum requirements for being wrapped by TextIOWrapper sounds like a necessary thing to have (and I'd be inclined to agree with your assertion, but I didn't work on the IO library :).  It would be best to open a new issue for that.

----------
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:01:47 2011
From: report at bugs.python.org (Matthew Funke)
Date: Wed, 23 Feb 2011 15:01:47 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298473307.91.0.77659700176.issue11288@psf.upfronthosting.co.za>


Matthew Funke <go4tli at gmail.com> added the comment:

Changing the environment variables did the trick!  Thank you very much!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:04:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Feb 2011 15:04:09 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298473449.88.0.520907354984.issue10791@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Yes, a clear definition of the minimum requirements for being wrapped
> by TextIOWrapper sounds like a necessary thing to have

About that: is read1() argument mandatory or not?

In _pyio, BufferedIOBase.read1() argument is optional (default: None); BytesIO.read1(), BufferedReader.read1(), BufferedRWPair.read1(), BufferedRandom.read1() argument is mandatory.

In _io, BufferedIOBase.read1() raises directly an exception, without checking the arguments; BufferedReader.read1() argument is mandatory.

In the io doc, BufferedIOBase.read1() argument is optional (default: -1), BytesIO.read1() has no argument (!) and BufferedReader.read1() argument is mandatory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:15:31 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 15:15:31 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298474131.25.0.33633579283.issue11286@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Antoine is right, my patch is only of "discussion" quality and if my approach gets support, I will produce a more polished patch.

While I am fairly certain that this bug should be fixed where it was introduced, namely in the _pickle module, I am not sure patching both load_binstring() and load_short_binstring() is the right approach.

It may be better to modify _Unpickler_Read() so that it returns self->input_buffer (or even self->input_buffer + self->next_read_idx) for zero n.  This would be a cleaner design similar to that for PyMem_Malloc() et al. (Since _Unpickler_Read() is private API and the comment documenting it does not specify that it returns NULL for n = 0, I think this can be done in a bugfix release.  Furthermore, I reviewed the uses of _Unpickler_Read() with variable and thus potentially zero size and one of them is followed by a null check for s.)

On the other hand, my patch also eliminates redundant call to _Unpickler_Read() and makes load_binstring() and load_short_binstring() logic similar to that in load_counted_long().  The main advantage, of course is skipping PyUnicode_Decode() which will load a codec potentially triggering an import and execution of python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:22:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 15:22:40 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298474131.25.0.33633579283.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298474556.3710.54.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It may be better to modify _Unpickler_Read() so that it returns
> self->input_buffer (or even self->input_buffer + self->next_read_idx)
> for zero n.

I agree this would be better for readability and maintainability.

> On the other hand, my patch also eliminates redundant call to
> _Unpickler_Read() and makes load_binstring() and
> load_short_binstring() logic similar to that in load_counted_long().
> The main advantage, of course is skipping PyUnicode_Decode() which
> will load a codec potentially triggering an import and execution of
> python code.

Well, a theoretical argument could be made that some codec could return
a non-empty string when asked to decode an empty bytestring, but I'm not
sure it has much practical worth :)

----------
title: Some "trivial" python 2.x pickles fails to load in	Python 3.2 -> Some "trivial" python 2.x pickles fails to load in Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:35:25 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 15:35:25 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298474556.3710.54.camel@localhost.localdomain>
Message-ID: <AANLkTimc0=6QtqnKXxmp5hZqVxj5H2+qMfWN_kdjnru5@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Feb 23, 2011 at 10:22 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> Well, a theoretical argument could be made that some codec could return
> a non-empty string when asked to decode an empty bytestring, but I'm not
> sure it has much practical worth :)

I was thinking about that as well.  Note that the opposite is quite
common, for example any encoding that uses BOM will turn empty unicode
string into a non-empty byte string.  I don't think a codec that
decodes b'' into non-empty string exists, but it would be reasonable
for a codec that requires BOM or some other metadata to reject raise
an error on b''.  If we rely on decode(b'') == '', these errors will
go unnoticed.  I am going to prepare a Unpickler_Read() patch with
tests and play with it a little.  It is a good idea to separate
performance optimizations from bug fixes anyways.  If we want to
bypass decode on empty strings, we can do it independently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:38:16 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 15:38:16 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298475496.61.0.917643079437.issue11286@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:40:34 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 15:40:34 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298475634.93.0.633219113585.issue11298@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

Added release2.7-maint patch.

----------
Added file: http://bugs.python.org/file20864/py2.7-maint_rev45852_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:41:19 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 15:41:19 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298475679.65.0.245609079503.issue11298@psf.upfronthosting.co.za>


Changes by blokeley <blokeley at gmail.com>:


Removed file: http://bugs.python.org/file20864/py2.7-maint_rev45852_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:46:13 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 15:46:13 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298475973.7.0.158617191012.issue11298@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

Added release2.7-maint patch.

----------
Added file: http://bugs.python.org/file20865/py2.7-maint_rev45852_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:49:24 2011
From: report at bugs.python.org (blokeley)
Date: Wed, 23 Feb 2011 15:49:24 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298476164.3.0.643748253084.issue11298@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

Added release3.2-maint patch.

I created the patches by cloning the corresponding hg repo from http://code.python.org/hg If this is the wrong thing to do, let me know.

I have no idea where the 3.3 branch is. Please advise.

----------
Added file: http://bugs.python.org/file20866/py3.2-maint_rev9895_issue11298.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 16:50:33 2011
From: report at bugs.python.org (Michael Foord)
Date: Wed, 23 Feb 2011 15:50:33 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298476233.31.0.531067825606.issue11298@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hey, blokeley the same patch will apply cleanly against 3.2 / 3.3 so no worries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:15:39 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 16:15:39 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

Please allow to deepcopy and to pickle paused generators, including all their state.

This is implemented in Pypy:

	Python 2.5.2 (335e875cb0fe, Dec 28 2010, 20:31:56)
	[PyPy 1.4.1] on win32
	Type "copyright", "credits" or "license()" for more information.
	DreamPie 1.1.1
	>>> import pickle, copy
	>>> def next(thing): # For compatibility
	...     return thing.next()
	>>> def g():
	...     for i in range(4):
	...         yield i
	>>> list(g())
	[0, 1, 2, 3]
	>>> live_generator = g()
	>>> next(live_generator)
	0
	>>> next(live_generator)
	1
	
Now `live_generator` holds a generator which is in the middle of its operation. It went through 0 and 1, and it still has 2 and 3 to yield.

We deepcopy it:	
	
	>>> live_generator_deepcopy = copy.deepcopy(live_generator)
	
The deepcopied generator assumes the same state of the original one. Let's exhaust it:	
	
	>>> list(live_generator_deepcopy)
	[2, 3]
	>>> list(live_generator_deepcopy)
	[]
	
Pypy also lets us pickle and unpickle the live generator:
	
	>>> live_generator_pickled = pickle.dumps(live_generator)
	>>> live_generator_unpickled = pickle.loads(live_generator_pickled)
	>>> list(live_generator_unpickled)
	[2, 3]
	>>> list(live_generator_unpickled)
	[]
	
And the original live generator was unchanged by all these operations:
	
	>>> list(live_generator)
	[2, 3]
	>>> list(live_generator)
	[]
	
All the above was demonstrated in Pypy. In Python 3.2, trying to pickle a live generator raises this exception:

	>>> pickle.dumps(live_generator)
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	_pickle.PicklingError: Can't pickle <class 'generator'>: attribute lookup builtins.generator failed

And trying to deepcopy one raises this exception:
	
	>>> copy.deepcopy(live_generator)
	Traceback (most recent call last):
	  File "<stdin>", line 1, in <module>
	  File "c:\Python32\lib\copy.py", line 174, in deepcopy
		y = _reconstruct(x, rv, 1, memo)
	  File "c:\Python32\lib\copy.py", line 285, in _reconstruct
		y = callable(*args)
	  File "c:\Python32\lib\copyreg.py", line 88, in __newobj__
		return cls.__new__(cls, *args)
	TypeError: object.__new__(generator) is not safe, use generator.__new__()

It would be nice if Python 3.2 could pickle and deepcopy live generators.

----------
components: Library (Lib)
messages: 129213
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Allow deepcopying and pickling paused generators
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:21:53 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 23 Feb 2011 16:21:53 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298478113.21.0.407573417392.issue11299@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

P.S. I'm willing to write a test-case if it will help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:26:06 2011
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 23 Feb 2011 16:26:06 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298478366.66.0.441124539984.issue11297@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:52:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Feb 2011 16:52:35 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298479955.67.0.634680584304.issue10791@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would probably be ok to fallback on read() when read1() isn't implemented. read1() is supposed to be implemented by all BufferedIO-compliant classes, but in all honesty I don't think it's very useful in practice. It's supposed to be an optimization, and I think it's a misguided one; the generalized prefetch() primitive I proposed last year would certainly be more useful: see http://mail.python.org/pipermail/python-dev/2010-September/104194.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 17:55:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Feb 2011 16:55:53 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298480153.89.0.861833863741.issue11297@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think that new_child and parents are too specialized at all, indeed they are essential to one of the primary use cases for the construct.  I find Django's push and pop much more intuitive than new_child and parents, however, and would prefer those methods.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:19:59 2011
From: report at bugs.python.org (Alex)
Date: Wed, 23 Feb 2011 18:19:59 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298485199.42.0.679548045987.issue11297@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

An important distinction with Django's push/pop is that they mutate the Context (ChainMap) rather than return a fresh instance.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:26:10 2011
From: report at bugs.python.org (Alex)
Date: Wed, 23 Feb 2011 18:26:10 +0000
Subject: [issue10791] Wrapping TextIOWrapper around gzip files
In-Reply-To: <1293652434.65.0.434835329632.issue10791@psf.upfronthosting.co.za>
Message-ID: <1298485570.49.0.712697108791.issue10791@psf.upfronthosting.co.za>


Changes by Alex <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10791>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:39:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Feb 2011 18:39:16 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298486356.35.0.488802588711.issue11297@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, that's part of what I find more intuitive about it.  I think of the chainmap as a stack.  Perhaps if I had a different application (I would use it for either configuration or namespace management) I'd want a different API, but for those two the stack approach seems most natural to me.

In particular, since only the top dict can be updated, it seems most natural to pop it off the top of the stack in order to modify the next one down (and then push it back, if desired).  If instead the way to modify the next one down is to do parents, then I'm mutating the chainmap I just did the parents call on, but I'm not referencing that object, I'm referencing the one I got back from the parents call.  It just seems more natural that the mutation operations should be carried out via a single chainmap object by using pop and push rather than effectively modifying (potentially multiple) chainmap objects by manipulating other chainmap objects.  (Yes, I realize that it is really the underlying dicts that are being modified, but conceptually I'm thinking of the chainmap as a single data structure).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:11 +0000
Subject: [issue11227] [DOC] asyncore - use 'Host' header in HTTP example
In-Reply-To: <1297898789.12.0.318094407747.issue11227@psf.upfronthosting.co.za>
Message-ID: <1298486651.56.0.0105830246998.issue11227@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11227>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:17 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:17 +0000
Subject: [issue11239] regexp-howto - add missing } to metachars
In-Reply-To: <1297984111.53.0.588454087377.issue11239@psf.upfronthosting.co.za>
Message-ID: <1298486657.69.0.66478375631.issue11239@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11239>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:24 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:24 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1298486664.71.0.439672052289.issue11232@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:30 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:30 +0000
Subject: [issue11292] Curses - add A_REVERSE to attributes table
In-Reply-To: <1298406350.63.0.533877508283.issue11292@psf.upfronthosting.co.za>
Message-ID: <1298486670.84.0.392243452145.issue11292@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11292>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:36 +0000
Subject: [issue11293] Distutils - read the file when using it in
	long_description
In-Reply-To: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>
Message-ID: <1298486676.87.0.992062093472.issue11293@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11293>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:44:45 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 18:44:45 +0000
Subject: [issue11294] Locale - update & uniform ERA_*_FMT doc
In-Reply-To: <1298413244.48.0.422350536879.issue11294@psf.upfronthosting.co.za>
Message-ID: <1298486685.34.0.32309334418.issue11294@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
assignee: sandro.tosi -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11294>
_______________________________________

From report at bugs.python.org  Wed Feb 23 19:52:45 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 23 Feb 2011 18:52:45 +0000
Subject: [issue11288] Python installed from MSI doesn't work
In-Reply-To: <1298389318.8.0.365755340585.issue11288@psf.upfronthosting.co.za>
Message-ID: <1298487165.74.0.781684149316.issue11288@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, closing this as "invalid" then - it's not a bug in the installer, but a misconfiguration of the local system. Thanks to Bartosz for the analysis!

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11288>
_______________________________________

From report at bugs.python.org  Wed Feb 23 20:41:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2011 19:41:06 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298490066.21.0.649999695257.issue11297@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, the new_child() and parents() part of the API was modeled after contexts in ANLTR where they are needed to overcome the limitations of Django's push/pop style which precludes a context from having multiple, independent children at the same time.  The module docstring in the http://code.activestate.com/recipes/577434/ recipe shows how new_child() can be used to easily model both dynamic scoping and nested scoping.

The other advantage of the new_child/parents API over the push/pop API is that it overcomes the occasional templating need to keep two copies of the context (before a push and after a push).

In some ways, it is more difficult to keep track of a mutating chain that is being continuously pushed and popped.  It is simpler to assign a chain to a variable and always know that it is associated with a given template and not have to worry about whether some utility function pushed a new context and failed to pop it when it was done.  A push/pop style introduces the same problems as matching matching malloc() with free() in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:34:52 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Wed, 23 Feb 2011 20:34:52 +0000
Subject: [issue11300] mmap() large file failures on Mac OS X docfix
In-Reply-To: <1298493292.2.0.2203680343.issue11300@psf.upfronthosting.co.za>
Message-ID: <1298493292.2.0.2203680343.issue11300@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Issue 11277 was closed upon the generally accepted conclusion that the failure is that mmap(2) on Mac OS X has a long time known bug (see msg129107, or directly http://lists.apple.com/archives/darwin-development/2003/Jun/msg00141.html).

Issue 11277 fixed the problem in the test suite, but it does give end-users no hint that such a problem exists (on the documentation side).  And it's my believe that a beginner or even a non-low-level programmer may be lost in an equal situation.  (Though one could argue that such a HE should not use mmap(2), but everyone has a first-time somewhen, say.)

In addition, there are many people who don't have the chance to work/test on multiple operating systems and/or hardware, and who need the hand of people who are experienced and can give hints on stupidiness or however this word is correctly spelled.  (Am i preaching already?)

Because Python is expected to be a user-friendly language i do request a documentation patch which gives a hint.  I'll apply a patch, but i'm somewhat new to Python and rST etc., so it surely needs a hand.  (Maybe even its speech is too aggressive??)

----------
assignee: docs at python
components: Documentation
files: doc_lib_mmap.patch
keywords: patch
messages: 129221
nosy: docs at python, sdaoden
priority: normal
severity: normal
status: open
title: mmap() large file failures on Mac OS X docfix
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20867/doc_lib_mmap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11300>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:49:36 2011
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 23 Feb 2011 20:49:36 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298494176.95.0.951013268412.issue11252@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

OK, now I know more about glob than I ever wanted to! :) Basically it comes down to this:

unix>>> os.path.split('\\')
('', '\\')

win32>>> os.path.split('\\')
('\\', '')

This is why \ is recognized as the root directory on Win32 and as a non-existent file on Unix.

In case of / both Unix and Win32 treat it as a valid directory separator so `os.path.split('/')` returns `('/', '')`. This is why / is recognized as the root directory on both systems.

Does this answer your questions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Wed Feb 23 21:50:27 2011
From: report at bugs.python.org (Mike Cencula)
Date: Wed, 23 Feb 2011 20:50:27 +0000
Subject: [issue11301] cookielib.LWPCookieJar.save() doesn't save cookies
In-Reply-To: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>
Message-ID: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>


New submission from Mike Cencula <mike at cencula.com>:

I'm trying to use cookielib.LWPCookieJar.save() to save cookies from a website.  The cookie file is created with a header line, but the cookies are not stored.  Example program attached.

Python version:
2.5.2 (r252:60911, Jan 24 2010, 14:53:14)

Running on Debian lenny as a guest on Virtualbox

Output from the attached file pasted below:
------------
mike at debian:~$ python cookieexample2.py
Here are the headers of the page :
Server: none
Content-Type: text/html
Pragma: no-cache
Cache-Control: no-cache
Expires: Tue, 04 Dec 1993 21:29:02 GMT
Vary: Accept-Encoding
Date: Wed, 23 Feb 2011 20:43:55 GMT
Transfer-Encoding:  chunked
Connection: close
Connection: Transfer-Encoding


These are the cookies we have received so far :
0   :   <Cookie BIGipServerdiy_pool=604317450.20480.0000 for www.diy.co.uk/>
1   :   <Cookie BIGipServerdiy_pool=637871882.20480.0000 for www.diy.com/>
2   :   <Cookie DYN_USER_CONFIRM=1ab776eae0bf5661a2955c6ec7858439 for www.diy.com/>
3   :   <Cookie DYN_USER_ID=1619150879 for www.diy.com/>
4   :   <Cookie JSESSIONID=OVHJMMEHW4LOQCRHAWVCFFIKE2C0YIV0 for www.diy.com/>
mike at debian:~$

Contents of cookie.lwp afterward:
------------
mike at debian:~$ cat cookies.lwp
#LWP-Cookies-2.0
mike at debian:~$

Behavior is nearly identical using cookielib.MozillaCookieJar except the headers are different in the saved cookie file.  Cookies themselves are not saved.

I am new to Python, so I hope this is not user error.

----------
components: Library (Lib)
files: cookieexample2.py
messages: 129223
nosy: mcencula
priority: normal
severity: normal
status: open
title: cookielib.LWPCookieJar.save() doesn't save cookies
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file20868/cookieexample2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11301>
_______________________________________

From report at bugs.python.org  Wed Feb 23 22:12:30 2011
From: report at bugs.python.org (Mike Cencula)
Date: Wed, 23 Feb 2011 21:12:30 +0000
Subject: [issue11301] cookielib.LWPCookieJar.save() doesn't save cookies
In-Reply-To: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>
Message-ID: <1298495550.56.0.0565007383018.issue11301@psf.upfronthosting.co.za>


Mike Cencula <mike at cencula.com> added the comment:

User error indeed.  Adding ignore_discard=True, ignore_expires=True cured the issue.

Thank you.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11301>
_______________________________________

From report at bugs.python.org  Wed Feb 23 22:27:37 2011
From: report at bugs.python.org (Vincent Legoll)
Date: Wed, 23 Feb 2011 21:27:37 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>


New submission from Vincent Legoll <vincent.legoll at gmail.com>:

While working to improve pypy's compliance with cpython2.7
I added more tests to the ast module test suite.

They may be of interest here too...

----------
components: Tests
files: add-more-tests-for-ast_py.patch
keywords: patch
messages: 129225
nosy: vincele
priority: normal
severity: normal
status: open
title: Add more tests to test_ast.py
versions: Python 2.7
Added file: http://bugs.python.org/file20869/add-more-tests-for-ast_py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:00:24 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 22:00:24 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298498424.44.0.0798612824035.issue11286@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a new version of issue11286.diff which fixes the issue by removing special handling of n == 0 case from _Unpickler_Read().  Note that _Unpickler_Read() (formerly known as unpickler_read()) only started to return null pointer instead of a pointer to an empty string when given n == 0 after optimizations implemented in issue #9410.  This observation makes me more comfortable with changing the behavior of this function because current behavior is itself a regression from 3.1.

(An off-topic remark:  What was the point of renaming static functions in _pickle.c made in r84653?  There is no need to prefix static C functions with an underscore to make them private and the convention seems to be not to use CamelCase in the names of non-CAPI functions.)

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file20870/issue11286.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:01:06 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 22:01:06 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298498466.04.0.421519561506.issue11286@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20856/issue11286.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:19:56 2011
From: report at bugs.python.org (Jake)
Date: Wed, 23 Feb 2011 22:19:56 +0000
Subject: [issue4376] Nested ctypes 'BigEndianStructure' fails
In-Reply-To: <1227262171.21.0.443834827136.issue4376@psf.upfronthosting.co.za>
Message-ID: <1298499596.2.0.330923639542.issue4376@psf.upfronthosting.co.za>


Changes by Jake <jake.coffman at gmail.com>:


----------
nosy: +Jake.Coffman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4376>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:34:58 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Feb 2011 22:34:58 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ ./python.exe -m timeit "b'x'.decode('latin1')"
100000 loops, best of 3: 2.57 usec per loop
$ ./python.exe -m timeit "b'x'.decode('latin-1')"
1000000 loops, best of 3: 0.336 usec per loop

The reason for this behavior is that 'latin-1' is short-circuited in C code while 'latin1' has to be looked up in aliases.py.  Attached patch fixes this issue.

----------
files: latin1.diff
keywords: patch
messages: 129227
nosy: belopolsky, lemburg
priority: normal
severity: normal
status: open
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')
type: performance
Added file: http://bugs.python.org/file20871/latin1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:39:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 23 Feb 2011 22:39:42 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298500782.89.0.780499108563.issue11303@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Wed Feb 23 23:58:11 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 23 Feb 2011 22:58:11 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-January/002974.html here's a patch to fix it.

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 129228
nosy: docs at python, sandro.tosi
priority: low
severity: normal
stage: patch review
status: open
title: Input/output tutorial - PI is rounded not truncated
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:05:45 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Wed, 23 Feb 2011 23:05:45 +0000
Subject: [issue8426] multiprocessing.Queue fails to get() very large objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1298502345.35.0.0539326643712.issue8426@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Alright, it's normal behaviour, but since it doesn't seem to be documented, it can be quite surprising.
A queue works like this:
- when you call queue.put(data), the data is added to a deque, which can grow and shrink forever
- then a thread pops elements from the deque, and sends them so that the other process can receive them through a pipe or a Unix socket (created via socketpair). But, and that's the important point, both pipes and unix sockets have a limited capacity (used to be 4k - pagesize - on older Linux kernels for pipes, now it's 64k, and between 64k-120k for unix sockets, depending on tunable systcls).
- when you do queue.get(), you just do a read on the pipe/socket

In multiproc3.py, the items are first appended to the queue, then the sender process is waited on. But when size = 7279, the data submitted reaches 64k, so the writting thread blocks on the write syscall.
And since a join is performed before dequeing the item, you just deadlock, since the join waits for the sending thread to complete, and the write can't complete since the pipe/socket is full!
If you dequeue the item before waiting the submitter process, everything works fine:


    t0 = time.time()
    try:
        get_t0 = time.time()
        vals = q.get(timeout=3.)
        get_duration = time.time() - get_t0

        s.join()

Now, for the initial report, the problem is related:

def child(task_q, result_q):
    while True:
        print "  Getting task..."
        task = task_q.get()
        print "  Got task", task[:10]
        task = task * 100000000
        print "  Putting result", task[:10]
        result_q.put(task)
        print "  Done putting result", task[:10]
        task_q.task_done()



    tasks = ["foo", "bar", "ABC", "baz"]
    for task in tasks:
        print "Putting task", task[:10], "..."
        task_q.put(task)
        print "Done putting task", task[:10]
    task_q.join()
    for task in tasks:
        print "Getting result..."
        print "Got result", result_q.get()[:10]

When the child puts results, since they're bigger tha 64k, the underlying pipe/socket fills up. Thus, the sending thread blocks on the write, and doesn't dequeue the result_q, which keeps growing.
So you end up storing in the result_q every object before starting to dequeue them, which represents roughly 4 * 3 * 1e8 = 1.2GB, which could explain the out-of-memory errors (and if it's Unicode string it's even much more)...
So the moral is: don't put() to much data to a queue without dequeuing them in a concurrent process...

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8426>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:10:29 2011
From: report at bugs.python.org (SilentGhost)
Date: Wed, 23 Feb 2011 23:10:29 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298502629.27.0.739034738841.issue11304@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Sandro, you didn't attach anything.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 00:57:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Feb 2011 23:57:51 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298505471.1.0.132824863285.issue11304@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:08:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2011 00:08:39 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298506119.59.0.143387191301.issue11304@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r88356, r88537, and r88538.
Thanks for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:18:03 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Feb 2011 00:18:03 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298506683.23.0.0610302383536.issue11304@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
Removed message: http://bugs.python.org/msg129230

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:18:30 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Feb 2011 00:18:30 +0000
Subject: [issue11304] Input/output tutorial - PI is rounded not truncated
In-Reply-To: <1298501891.64.0.374042391138.issue11304@psf.upfronthosting.co.za>
Message-ID: <1298506710.71.0.278661712845.issue11304@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy:  -SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11304>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:20:36 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 00:20:36 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298506836.17.0.847505339569.issue11303@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In issue11303.diff, I add similar optimization for encode('latin1') and for 'utf8' variant of utf-8.  I don't think dash-less variants of utf-16 and utf-32 are common enough to justify special-casing.

----------
Added file: http://bugs.python.org/file20872/issue11303.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:24:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 00:24:44 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298507084.3.0.122551796262.issue11303@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:40:31 2011
From: report at bugs.python.org (Michael Foord)
Date: Thu, 24 Feb 2011 00:40:31 +0000
Subject: [issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating
	extension module
In-Reply-To: <1284660526.13.0.672517649262.issue9878@psf.upfronthosting.co.za>
Message-ID: <1298508031.63.0.00467881787195.issue9878@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

And also issue 10764. This issue affects alternative implementations of Python.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9878>
_______________________________________

From report at bugs.python.org  Thu Feb 24 01:45:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 00:45:10 +0000
Subject: [issue10764] sysconfig and alternative implementations
In-Reply-To: <1293126984.08.0.755809334689.issue10764@psf.upfronthosting.co.za>
Message-ID: <1298508310.89.0.704684261635.issue10764@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: duplicate -> 
superseder: Avoid parsing pyconfig.h and Makefile by autogenerating extension module -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10764>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:12:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 01:12:57 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298509977.13.0.402041037422.issue11303@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:24:44 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Feb 2011 01:24:44 +0000
Subject: [issue11302] Add more tests to test_ast.py
In-Reply-To: <1298496457.65.0.147228634144.issue11302@psf.upfronthosting.co.za>
Message-ID: <1298510684.18.0.650837661651.issue11302@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please upload to Rietveld. I have a few comments to make.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11302>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:28:22 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Feb 2011 01:28:22 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
	specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1298510902.88.0.486293543667.issue11276@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm trying to remember if this was intentional or not...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:36:00 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2011 01:36:00 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298511360.97.0.732373514765.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patch looks great.
Please apply it.

----------
assignee: rhettinger -> eli.bendersky
resolution: later -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:37:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 01:37:39 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1298511459.72.0.999253381164.issue5902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

What is the status of this.  Status=open and Resolution=rejected contradict each other.

This discussion is relevant for issue11303.  Currently alias lookup incurs huge performance penalty in some cases.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:56:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 01:56:29 +0000
Subject: [issue9952] Martin Rinehart wants to stay in touch on LinkedIn
In-Reply-To: <139977402.6246160.1285498974918.JavaMail.app@ech3-cdn11.prod>
Message-ID: <1298512589.68.0.0508720755682.issue9952@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19023/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9952>
_______________________________________

From report at bugs.python.org  Thu Feb 24 02:56:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 01:56:33 +0000
Subject: [issue9952] Martin Rinehart wants to stay in touch on LinkedIn
Message-ID: <1298512593.28.0.714980556389.issue9952@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg117410

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9952>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:10:19 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 02:10:19 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1298513419.85.0.00455767376339.issue5902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Accepting all common forms for
> encoding names means that you can usually give Python an encoding name
> from, e.g. a HTML page, or any other file or system that specifies an
> encoding.

I don't buy this argument.  Running attached script on http://www.iana.org/assignments/character-sets shows that there are hundreds of registered charsets that are not accepted by python:

$ ./python.exe iana.py| wc -l
     413

Any serious HTML or XML processing software should be based on the IANA character-sets file rather than on the ad-hoc list of aliases that made it into encodings/aliases.py.

----------
Added file: http://bugs.python.org/file20873/iana.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:19:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Feb 2011 02:19:52 +0000
Subject: [issue11305] TextIOWrapper.readline and str.splitlines have different
	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

For example:
>>> 'print 1\n\x0cprint 2\n\n'.splitlines()
['print 1\n', '\x0cprint 2\n', '\n']
>>> list(io.StringIO('print 1\n\x0cprint 2\n\n'))


I'm not sure which is preferable.

----------
components: IO, Interpreter Core
messages: 129240
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: TextIOWrapper.readline and str.splitlines have different behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11305>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:29:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Feb 2011 02:29:46 +0000
Subject: [issue11305] TextIOWrapper.readline and str.splitlines have different
	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298514586.78.0.574372270332.issue11305@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Your example got a little messed up.

>>> list(io.StringIO('print 1\n\x0cprint 2\n\n'))
['print 1\n', '\x0cprint 2\n', '\n']
>>> 'print 1\n\x0cprint 2\n\n'.splitlines(True)
['print 1\n', '\x0c', 'print 2\n', '\n']
>>> list(io.StringIO('print 1\x0cprint 2\n\n'))
['print 1\x0cprint 2\n', '\n']
>>> 'print 1\x0cprint 2\n\n'.splitlines(True)
['print 1\x0c', 'print 2\n', '\n']

I think splitlines has it correct.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11305>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:31:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Feb 2011 02:31:22 +0000
Subject: [issue11305] TextIOWrapper.readline and str.splitlines have different
	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298514682.95.0.909094879363.issue11305@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On the other hand, I believe io is documented as only recognizing /r and /n, so its behavior matches its documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11305>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:33:07 2011
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 24 Feb 2011 02:33:07 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298514787.82.0.929093934779.issue10516@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Please modify the patch so that it can be applied to current py3k trunk cleanly. (Notice that Lib/collections.py has been changed to a package in #11085).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:33:43 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Feb 2011 02:33:43 +0000
Subject: [issue11305] TextIOWrapper.readline and str.splitlines have different
	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298514823.44.0.395235002445.issue11305@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't see that, but the chances of changing either of these is quite low, so I suppose we should just document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11305>
_______________________________________

From report at bugs.python.org  Thu Feb 24 03:45:04 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Feb 2011 02:45:04 +0000
Subject: [issue11305] TextIOWrapper.readline and str.splitlines have different
	behavior
In-Reply-To: <1298513992.9.0.559771255242.issue11305@psf.upfronthosting.co.za>
Message-ID: <1298515504.28.0.984800250555.issue11305@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"newline controls how universal newlines works (it only applies to text mode). It can be None, '', '\n', '\r', and '\r\n'..."

Whereas splitlines says:

"Return a list of the lines in the string, breaking at line boundaries."

So if we are fixing docs, we need to add that "line boundaries" are based on the relevant unicode properties (see issue 7643).

And, indeed, Antoine has already pronounced on this in issue 6664.

Since this has come up more than once, adding a note that they are not recognized by design in the io module to the io docs might be a good idea.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11305>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:26:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 03:26:53 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298518013.84.0.437828773479.issue10516@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ray: Eli can just refresh his patch and commit.  Note that the patch program will prompt you for a file name if it can?t find the file for a diff hunk, so it should be trivial to apply a patch across a rename.

Eli: Would you mind changing two nits before committing the nice patch?

+"L.clear() -> None -- remove all items from L");
It looks like other methods that return None just omit the ?-> type? part.

+      
 
+
That?s one new line too many.  Some trailing spaces are also included.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:45:38 2011
From: report at bugs.python.org (Guy Kloss)
Date: Thu, 24 Feb 2011 03:45:38 +0000
Subject: [issue5542] Socket is closed prematurely in httplib,
	if server sends response before request body has been sent
In-Reply-To: <1237800550.85.0.782891199129.issue5542@psf.upfronthosting.co.za>
Message-ID: <1298519138.61.0.873728459237.issue5542@psf.upfronthosting.co.za>


Guy Kloss <guy.kloss at arcor.de> added the comment:

I know this issue is marked as fixed, and won't be backported to 2.6. But the fix is simple enough to self perform on 2.6. Doing that I have discovered an issue that might still be present with the fix, as it was not discussed here, yet, but is still related.

Whenever one does the same thing, but uses an SSL connection (HTTPS), the socket.error is raised from within ssl.py (line 174).

Even though the send() call in httplib does not misbehave now, when using an SSL encrypted connection the ssl module still throws you in front of a bus.

----------
nosy: +guy.kloss

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5542>
_______________________________________

From report at bugs.python.org  Thu Feb 24 04:49:25 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 24 Feb 2011 03:49:25 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298519365.4.0.553044590821.issue11303@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 05:00:54 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 04:00:54 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1298520054.8.0.0591201159241.issue5902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ezio and I discussed on IRC the implementation of alias lookup and neither of us was able to point out to the function that strips non-alphanumeric characters from encoding names.

It turns out that there are three "normalize" functions that are successively applied to the encoding name during evaluation of str.encode/str.decode.

1. normalize_encoding() in unicodeobject.c
2. normalizestring() in codecs.c
3. normalize_encoding() in encodings/__init__.py

Each performs a slightly different transformation and only the last one strips non-alphanumeric characters.

The complexity of codec lookup is comparable with that of the import mechanism!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 06:40:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2011 05:40:02 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298526002.67.0.919037148865.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Eli doesn't need to post a new patch.  I'm sure he will fix any nits in his commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 06:55:21 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Feb 2011 05:55:21 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1298518013.84.0.437828773479.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTikWXKC6_QjPyU6HJ+uLrkxwD0z9VBF0qZy2-MW+@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Thu, Feb 24, 2011 at 05:26, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Ray: Eli can just refresh his patch and commit. ?Note that the patch program will prompt you for a file name if it can?t find the file for a diff hunk, so it should be trivial to apply a patch across a rename.
>
> Eli: Would you mind changing two nits before committing the nice patch?
>
> +"L.clear() -> None -- remove all items from L");
> It looks like other methods that return None just omit the ?-> type? part.
>
> +
>
> +
> That?s one new line too many. ?Some trailing spaces are also included.
>

I will fix and commit over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 06:57:12 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Feb 2011 05:57:12 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298527032.3.0.863317037228.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:01:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2011 07:01:19 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298530879.52.0.787690016686.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

[?ric Araujo]
> +"L.clear() -> None -- remove all items from L");
> It looks like other methods that return None 
> just omit the ?-> type? part.

These kind of nitty comments really aren't helpful.
It consumes more time to talk about them than they're worth.
In this case, Eli was modeling after the docstring in dictobject.c:

   PyDoc_STRVAR(clear__doc__,
   "D.clear() -> None.  Remove all items from D.");

Just because list.remove.__doc__ failed to consistently follow that convention doesn't make Eli's patch incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Thu Feb 24 08:03:32 2011
From: report at bugs.python.org (Matt Johnston)
Date: Thu, 24 Feb 2011 07:03:32 +0000
Subject: [issue11306] mailbox should test for errno.EROFS
In-Reply-To: <1298531012.94.0.719284706533.issue11306@psf.upfronthosting.co.za>
Message-ID: <1298531012.94.0.719284706533.issue11306@psf.upfronthosting.co.za>


New submission from Matt Johnston <matt at ucc.asn.au>:

When opening mailboxes the module checks for errno.EACCES. This doesn't help if the location is mounted read-only. Something like the following (against Python 2.6) would fix it, there are a few other checks in mailbox.py for EACCES too.

--- mailbox.py.orig	2011-02-24 15:02:22.000000000 +0800
+++ mailbox.py	2011-02-24 15:02:05.000000000 +0800
@@ -512,7 +512,7 @@ class _singlefileMailbox(Mailbox):
                     f = open(self._path, 'wb+')
                 else:
                     raise NoSuchMailboxError(self._path)
-            elif e.errno == errno.EACCES:
+            elif e.errno == errno.EACCES or e.errno == errno.EROFS:
                 f = open(self._path, 'rb')
             else:
                 raise

----------
components: Library (Lib)
messages: 129252
nosy: matt
priority: normal
severity: normal
status: open
title: mailbox should test for errno.EROFS
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11306>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:04:37 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 09:04:37 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298506836.17.0.847505339569.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D661F23.2070804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> In issue11303.diff, I add similar optimization for encode('latin1') and for 'utf8' variant of utf-8.  I don't think dash-less variants of utf-16 and utf-32 are common enough to justify special-casing.

Looks good.

Given that we are starting to have a whole set of such aliases
in the C code, I wonder whether it would be better to make the
string comparisons more efficient, e.g.
if "utf" matches, the checks could then continue with "8" or "-8"
instead of trying to match "utf" again and again.

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:05:46 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 09:05:46 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1298511459.72.0.999253381164.issue5902@psf.upfronthosting.co.za>
Message-ID: <4D661F69.9050804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> What is the status of this.  Status=open and Resolution=rejected contradict each other.

Sorry, forgot to close the ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:06:08 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 09:06:08 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1241251220.61.0.609037785801.issue5902@psf.upfronthosting.co.za>
Message-ID: <1298538368.76.0.182440024384.issue5902@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:20:45 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 09:20:45 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1298513419.85.0.00455767376339.issue5902@psf.upfronthosting.co.za>
Message-ID: <4D6622E4.7010003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
>> Accepting all common forms for
>> encoding names means that you can usually give Python an encoding name
>> from, e.g. a HTML page, or any other file or system that specifies an
>> encoding.
> 
> I don't buy this argument.  Running attached script on http://www.iana.org/assignments/character-sets shows that there are hundreds of registered charsets that are not accepted by python:
> 
> $ ./python.exe iana.py| wc -l
>      413
> 
> Any serious HTML or XML processing software should be based on the IANA character-sets file rather than on the ad-hoc list of aliases that made it into encodings/aliases.py.

Let's do a reality check:

How often do you see requests for additions to the aliases we
have in Python ? Perhaps one every year, if at all.

We take great care not to add aliases that are not in common
use or that do not have a proven track record of really being
compatible to the codec in question.

If you think we are missing some aliases, please open tickets
for them, indicating why these should be added.

If you really want complete IANA coverage, I suggest you create
a normalization module which maps the IANA names to our names
and upload it to PyPI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:21:03 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Feb 2011 09:21:03 +0000
Subject: [issue11295] On Windows,
	Python crashes on ANSI / Windows-formatted source files
In-Reply-To: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>
Message-ID: <1298539263.52.0.0915897469385.issue11295@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Python works fine with Notepad generated scripts. I think this is a
CGI issue. Try following this tutorial:

http://www.imladris.com/Scripts/PythonForWindows.html


If you still suspect a bug, you should provide the exact CGI script
and all details of the Apache configuration.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11295>
_______________________________________

From report at bugs.python.org  Thu Feb 24 10:29:14 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 09:29:14 +0000
Subject: [issue5902] Stricter codec names
In-Reply-To: <1298520054.8.0.0591201159241.issue5902@psf.upfronthosting.co.za>
Message-ID: <4D6624E8.9020508@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> Ezio and I discussed on IRC the implementation of alias lookup and neither of us was able to point out to the function that strips non-alphanumeric characters from encoding names.

I think you are misunderstanding the way the codec registry works.

You register codec search functions with it which then have to try
to map a given encoding name to a codec module.

The stdlib ships with one such function (defined in encodings/__init__.py).
This is registered with the codec registry per default.

The codec search function takes care of any normalization and conversion
to the module name used by the codecs from that codec package.

> It turns out that there are three "normalize" functions that are successively applied to the encoding name during evaluation of str.encode/str.decode.
> 
> 1. normalize_encoding() in unicodeobject.c

This was added to have the few shortcuts we have in the C code
for commonly used codecs match more encoding aliases.

The shortcuts completely bypass the codec registry and also
bypass the function call overhead incurred by codecs
run via the codec registry.

> 2. normalizestring() in codecs.c

This is the normalization applied by the codec registry. See PEP 100
for details:

"""
    Search functions are expected to take one argument, the encoding
    name in all lower case letters and with hyphens and spaces
    converted to underscores, ...
"""

> 3. normalize_encoding() in encodings/__init__.py

This is part of the stdlib encodings package's codec search
function.

> Each performs a slightly different transformation and only the last one strips non-alphanumeric characters.
> 
> The complexity of codec lookup is comparable with that of the import mechanism!

It's flexible, but not really complex.

I hope the above clarifies the reasons for the three normalization
functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5902>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:16:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Feb 2011 11:16:53 +0000
Subject: [issue11296] Possible error in What's new in Python 3.2 : duplication
	of rsplit() mention
In-Reply-To: <1298423429.64.0.239185638784.issue11296@psf.upfronthosting.co.za>
Message-ID: <1298546213.65.0.20201449916.issue11296@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Okay fixed.  The rsplit() method was mentioned in both underlying tracker issues, so it got mentioned twice when once would have been enough :-)

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11296>
_______________________________________

From report at bugs.python.org  Thu Feb 24 12:38:15 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 11:38:15 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298547495.11.0.706319063848.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I wonder what this normalize_encoding() does!  Here is a pretty standard version of mine which is a bit more expensive but catches match more cases!  This is stripped, of course, and can be rewritten very easily to Python's needs (i.e. using char[32] instead of char[11].

 * @@li If a character is either ::s_char_is_space() or ::s_char_is_punct():
 *      @@li    Replace with ASCII space (0x20).
 *      @@li    Squeeze adjacent spaces to a single one.
 * @@li Else if a character is ::s_char_is_alnum():
 *      @@li    ::s_char_to_lower() characters.
 *      @@li    Separate groups of alphas and digits with ASCII space (0x20).
 * @@li Else discard character.
 * E.g. "ISO_8859---1" becomes "iso 8859 1"
 * and "ISO8859-1" also becomes "iso 8859 1".

s_textcodec_normalize_name(s_CString *_name) {
        enum { C_NONE, C_WS, C_ALPHA, C_DIGIT } c_type = C_NONE;
        char *name, c;
        auto s_CString input;

        s_cstring_swap(s_cstring_init(&input), _name);
        _name = s_cstring_reserve(_name, 31, s_FAL0);
        name = s_cstring_cstr(&input);

        while ((c = *(name++)) != s_NUL) {
                s_si8 sep = s_FAL0;

                if (s_char_is_space(c) || s_char_is_punct(c)) {
                        if (c_type == C_WS)
                                continue;
                        c_type = C_WS;
                        c = ' ';
                } else if (s_char_is_alpha(c)) {
                        sep = (c_type == C_DIGIT);
                        c_type = C_ALPHA;
                        c = s_char_to_lower(c);
                } else if (s_char_is_digit(c)) {
                        sep = (c_type == C_ALPHA);
                        c_type = C_DIGIT;
                } else
                        continue;

                do
                        _name = s_cstring_append_char(_name, (sep ? ' ' : c));
                while (--sep >= s_FAL0);
        }

        s_cstring_destroy(&input);
        return _name;
}

----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 13:21:58 2011
From: report at bugs.python.org (david)
Date: Thu, 24 Feb 2011 12:21:58 +0000
Subject: [issue11197] information leakage with SimpleHTTPServer
In-Reply-To: <1297449971.18.0.229893361501.issue11197@psf.upfronthosting.co.za>
Message-ID: <1298550118.43.0.542781799153.issue11197@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

This may be stupid but...

shouldn't the example be:

lynx http://localhost:8000/../../../../../etc/passwd

... which does _not_ work.

----------
nosy: +db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11197>
_______________________________________

From report at bugs.python.org  Thu Feb 24 13:24:13 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 12:24:13 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298550253.74.0.149636422642.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(That is to say, i would do it.  But not if _cpython is thrown to trash ,-); i.e. not if there is not a slight chance that it gets actually patched in because this performance issue probably doesn't mean a thing in real life.  You know, i'm a slow programmer, i would need *at least* two hours to rewrite that in plain C in a way that can make it as a replacement of normalize_encoding().)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 13:57:47 2011
From: report at bugs.python.org (Niko Matsakis)
Date: Thu, 24 Feb 2011 12:57:47 +0000
Subject: [issue11307] re engine exhaustively explores more than necessary
In-Reply-To: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>
Message-ID: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>


New submission from Niko Matsakis <niko at alum.mit.edu>:

Executing code like this:

>>> r = re.compile(r'(\w+)*=.*')
>>> r.match("abcdefghijklmnopqrstuvwxyz")

takes a long time (around 12 seconds, on my machine).  Presumably this is because it is enumerating all the various ways to divvy up the alphabet for (\w+), even though there is no "=" sign to be found.  In contrast, in perl a regular expression like that seems to run instantly.

This could be optimized by recognizing that no "=" sign was found, and thus it does not matter how the first part of the regular expression matches, so there is no need to try additional possibilities.  To some extent, of course, the answer is just "don't write regular expressions like that."  This example is reduced down from a real regexp where the potential inefficiency was less obvious.  Nonetheless the general optimization of recognizing when further re-enumeration is not necessary makes sense more generally.

In any case, I am submitting the bug report merely to raise the issue as a possible future optimization, not to suggest that it must be addressed immediately (or even at all).

----------
components: Regular Expressions
messages: 129262
nosy: nikomatsakis
priority: normal
severity: normal
status: open
title: re engine exhaustively explores more than necessary
type: performance
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11307>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:36:27 2011
From: report at bugs.python.org (Graham Horler)
Date: Thu, 24 Feb 2011 14:36:27 +0000
Subject: [issue4350] Remove dead code from Tkinter.py
In-Reply-To: <1227053659.32.0.711141995765.issue4350@psf.upfronthosting.co.za>
Message-ID: <1298558187.09.0.193644423029.issue4350@psf.upfronthosting.co.za>


Graham Horler <tryexcept at gmail.com> added the comment:

Are we sure this is dead code, and not just out of date?

e.g. this works, and I use it in production with "if Tkinter.TkVersion >= 8.4":

b = Tkinter.Button(root)
b.tk.call('tk::ButtonEnter', b._w)

----------
nosy: +pysquared

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4350>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:42:44 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Feb 2011 14:42:44 +0000
Subject: [issue11308] extraneous link getit in the main website sidebar
In-Reply-To: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>
Message-ID: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>


New submission from SilentGhost <ghost.adh at gmail.com>:

There is an extraneous entry in sidebar of the www.python.org
It has some two chinese characters and leads to download page.

----------
messages: 129264
nosy: SilentGhost
priority: normal
severity: normal
status: open
title: extraneous link getit in the main website sidebar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11308>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:46:59 2011
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Feb 2011 14:46:59 +0000
Subject: [issue11308] extraneous link getit in the main website sidebar
In-Reply-To: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>
Message-ID: <1298558819.54.0.689023159893.issue11308@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Sorry, I realise that this is my mistake.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11308>
_______________________________________

From report at bugs.python.org  Thu Feb 24 15:51:44 2011
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Thu, 24 Feb 2011 14:51:44 +0000
Subject: [issue11309] #include <wctype.h> in Objects/unicodetype_db.h and
	Objects/unicodectype.c
In-Reply-To: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>
Message-ID: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

As of python 2.7.1 configured with "--enable-ipv6 --enable-unicode --with-system-expat --with-system-ffi --with-signal-module --with-threads --with-wctype-functions --enable-shared":

Please #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c

compilation produces the warnings:

In file included from Objects/unicodectype.c:34:0:
Objects/unicodetype_db.h: In function '_PyUnicodeUCS2_IsWhitespace':
Objects/unicodetype_db.h:3277:5: warning: implicit declaration of function 'iswspace'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsLowercase':
Objects/unicodectype.c:192:5: warning: implicit declaration of function 'iswlower'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsUppercase':
Objects/unicodectype.c:197:5: warning: implicit declaration of function 'iswupper'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToLowercase':
Objects/unicodectype.c:202:5: warning: implicit declaration of function 'towlower'
Objects/unicodectype.c:202:12: warning: incompatible implicit declaration of built-in function 'towlower'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToUppercase':
Objects/unicodectype.c:207:5: warning: implicit declaration of function 'towupper'
Objects/unicodectype.c:207:12: warning: incompatible implicit declaration of built-in function 'towupper'
Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsAlpha':
Objects/unicodectype.c:212:5: warning: implicit declaration of function 'iswalpha'

----------
components: Build
messages: 129266
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11309>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:01:51 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 15:01:51 +0000
Subject: [issue11309] #include <wctype.h> in Objects/unicodetype_db.h
	and	Objects/unicodectype.c
In-Reply-To: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>
Message-ID: <4D6672DB.3010501@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

????? ???????? wrote:
> 
> New submission from ????? ???????? <dilyan.palauzov at aegee.org>:
> 
> As of python 2.7.1 configured with "--enable-ipv6 --enable-unicode --with-system-expat --with-system-ffi --with-signal-module --with-threads --with-wctype-functions --enable-shared":
> 
> Please #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c
> 
> compilation produces the warnings:
> 
> In file included from Objects/unicodectype.c:34:0:
> Objects/unicodetype_db.h: In function '_PyUnicodeUCS2_IsWhitespace':
> Objects/unicodetype_db.h:3277:5: warning: implicit declaration of function 'iswspace'
> Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsLowercase':
> Objects/unicodectype.c:192:5: warning: implicit declaration of function 'iswlower'
> Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsUppercase':
> Objects/unicodectype.c:197:5: warning: implicit declaration of function 'iswupper'
> Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToLowercase':
> Objects/unicodectype.c:202:5: warning: implicit declaration of function 'towlower'
> Objects/unicodectype.c:202:12: warning: incompatible implicit declaration of built-in function 'towlower'
> Objects/unicodectype.c: In function '_PyUnicodeUCS2_ToUppercase':
> Objects/unicodectype.c:207:5: warning: implicit declaration of function 'towupper'
> Objects/unicodectype.c:207:12: warning: incompatible implicit declaration of built-in function 'towupper'
> Objects/unicodectype.c: In function '_PyUnicodeUCS2_IsAlpha':
> Objects/unicodectype.c:212:5: warning: implicit declaration of function 'iswalpha'

--with-wctype-functions will only work if you have configured Python
to use the Unicode variant which is used by wchar_t on your platform.

Given the warnings you are seeing, this appears to be UCS4,
so you have to add --enable-unicode=ucs4 to your configure line.

Please note that support for wctype functions is not being
actively supported in Python anymore. I'd suggest you remove
the --with-wctype-functions option altogether.

----------
nosy: +lemburg
title: #include <wctype.h> in Objects/unicodetype_db.h and Objects/unicodectype.c -> #include <wctype.h> in Objects/unicodetype_db.h and	Objects/unicodectype.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11309>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:07:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Feb 2011 15:07:10 +0000
Subject: [issue11306] mailbox should test for errno.EROFS
In-Reply-To: <1298531012.94.0.719284706533.issue11306@psf.upfronthosting.co.za>
Message-ID: <1298560030.09.0.737390688888.issue11306@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Creating a test for this may not be practical :(

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11306>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:14:08 2011
From: report at bugs.python.org (Jonas H.)
Date: Thu, 24 Feb 2011 15:14:08 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298560448.02.0.655589436774.issue11258@psf.upfronthosting.co.za>


Changes by Jonas H. <jonas at lophus.org>:


Added file: http://bugs.python.org/file20874/faster-find-library1-py3k-with-escaped-name.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:15:04 2011
From: report at bugs.python.org (Jonathan Hayward)
Date: Thu, 24 Feb 2011 15:15:04 +0000
Subject: [issue11295] On Windows,
	Python crashes on ANSI / Windows-formatted source files
In-Reply-To: <1298420546.44.0.149906656845.issue11295@psf.upfronthosting.co.za>
Message-ID: <1298560504.19.0.292701569984.issue11295@psf.upfronthosting.co.za>


Jonathan Hayward <jonathan.hayward at pobox.com> added the comment:

Thank you; noted. I'm closing the bug for now at least; I'll reopen it if need be.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11295>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:30:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 15:30:54 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298561454.43.0.304649761025.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also discussion on #5902.

Steffen, your normalization function looks similar to encodings.normalize_encoding, with just a few differences (it uses spaces instead of dashes, it divides alpha chars from digits).

If it doesn't slow down the normal cases (i.e. 'utf-8', 'utf8', 'latin-1', etc.), a more flexible normalization done earlier might be a valid alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:34:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 15:34:00 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298561640.18.0.0720397884217.issue11303@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:40:46 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 15:40:46 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298561454.43.0.304649761025.issue11303@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=kY1s-ScxjhKSAB9HWyTCdEGJxnMVuBYbso9X2@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 24, 2011 at 10:30 AM, Ezio Melotti <report at bugs.python.org> wrote:
..
> See also discussion on #5902.

Mark has closed #5902 and indeed the discussion of how to efficiently
normalize encoding names (without changing what is accepted) is beyond
the scope of that or the current issue.  Can someone open a separate
issue to see if we can improve the current situation?  I don't think
having three slightly different normalize functions is optimal.  See
msg129248.

----------
title: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:52:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 15:52:38 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298562758.61.0.242893446923.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

.. i don't have actually invented this algorithm (but don't ask me where i got the idea from years ago), i've just implemented the function you see.  The algorithm itself avoids some pitfalls in respect to combining numerics and significantly reduces the number of possible normalization cases:

        "ISO-8859-1", "ISO8859-1", "ISO_8859-1", "LATIN1"
        (+ think of additional mispellings)
all become
        "iso 8859 1", "latin 1"
in the end

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:55:20 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 15:55:20 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298562920.35.0.398514873617.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Everything else is beyond my scope.  But normalizing _ to - is possibly a bad idea as far as i can remember the situation three years ago.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:57:24 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 15:57:24 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298563044.84.0.929817374518.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

P.P.S.: separating alphanumerics is a win for things like, e.g. UTF-16BE: it gets 'utf 16 be' - think about the possible mispellings here and you see this algorithm is a good thing....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 16:58:11 2011
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 24 Feb 2011 15:58:11 +0000
Subject: [issue8036] Interpreter crashes on invalid arg to spawnl on Windows
In-Reply-To: <1267477949.48.0.216202239381.issue8036@psf.upfronthosting.co.za>
Message-ID: <1298563091.53.0.250957891258.issue8036@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8036>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:01:52 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:01:52 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <AANLkTi=kY1s-ScxjhKSAB9HWyTCdEGJxnMVuBYbso9X2@mail.gmail.com>
Message-ID: <4D6680ED.5090305@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Feb 24, 2011 at 10:30 AM, Ezio Melotti <report at bugs.python.org> wrote:
> ..
>> See also discussion on #5902.
> 
> Mark has closed #5902 and indeed the discussion of how to efficiently
> normalize encoding names (without changing what is accepted) is beyond
> the scope of that or the current issue.  Can someone open a separate
> issue to see if we can improve the current situation?  I don't think
> having three slightly different normalize functions is optimal.  See
> msg129248.

Please see my reply on this ticket: those three functions have
different application areas.

On this ticker, we're discussing just one application area: that
of the builtin short cuts.

To have more encoding name variants benefit from the optimization,
we might want to enhance that particular normalization function
to avoid having to compare against "utf8" and "utf-8" in the
encode/decode functions.

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:04:50 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:04:50 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298562758.61.0.242893446923.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D6681A0.9040608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Steffen Daode Nurpmeso wrote:
> 
> Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:
> 
> .. i don't have actually invented this algorithm (but don't ask me where i got the idea from years ago), i've just implemented the function you see.  The algorithm itself avoids some pitfalls in respect to combining numerics and significantly reduces the number of possible normalization cases:
> 
>         "ISO-8859-1", "ISO8859-1", "ISO_8859-1", "LATIN1"
>         (+ think of additional mispellings)
> all become
>         "iso 8859 1", "latin 1"
> in the end

Please don't forget that the shortcuts in questions are *optimizations*.

Programmers who don't use the encoding names triggering those
optimizations will still have a running program, it'll only be
a bit slower and that's perfectly fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:08:15 2011
From: report at bugs.python.org (Suresh Kalkunte)
Date: Thu, 24 Feb 2011 16:08:15 +0000
Subject: [issue11252] Handling statement OR assignment continuation '\' on
	Win32 platform
In-Reply-To: <1298173207.62.0.40270752033.issue11252@psf.upfronthosting.co.za>
Message-ID: <1298563695.77.0.161468007091.issue11252@psf.upfronthosting.co.za>


Suresh Kalkunte <sskalkunte at gmail.com> added the comment:

Thanks for the education (hopefully a slight detour for you 8-). I included '/' to convey uniform behavior across platforms.

I will take it that the difference in what os.path.split() returns on Win32 vs. Linux is not a bug in Python since its Win32 users have come to expect the response it gives ? if yes, please point me to a resource (i.e, if you are aware, else do not bother 8-) that identifies such other conundrums.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11252>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:15:38 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 16:15:38 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564138.33.0.872757008877.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

So, well, a-ha, i will boot my laptop this evening and (try to) write a patch for normalize_encoding(), which will match the standart conforming LATIN1 and also will continue to support the illegal latin-1 without actually changing the two users PyUnicode_Decode() and PyUnicode_AsEncodedString(), from which i better keep the hands off.  But i'm slow, it may take until tomorrow...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:15:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 16:15:58 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564158.23.0.687001993736.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If the first normalization function is flexible enough to match most of the spellings of the optimized encodings, they will all benefit of the optimization without having to go through the long path.

(If the normalized encoding name is then passed through, the following normalization functions will also have to do less work, but this is out of the scope of this issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:20:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 16:20:10 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564410.15.0.973479289946.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that the normalization function in unicodeobject.c (only used for internal functions) can skip any character different than a-z, A-Z and 0-9. Something like:

>>> import re
>>> def normalize(name): return re.sub("[^a-z0-9]", "", name.lower())
... 
>>> normalize("UTF-8")
'utf8'
>>> normalize("ISO-8859-1")
'iso88591'
>>> normalize("latin1")
'latin1'

So ISO-8859-1, ISO885-1, LATIN-1, latin1, UTF-8, utf8, etc. will be normalized to iso88591, latin1 and utf8.

I don't know any encoding name where a character outside a-z, A-Z, 0-9 means anything special. But I don't know all encoding names! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:22:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 16:22:05 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564525.15.0.0814204288901.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch implementing my suggestion.

----------
Added file: http://bugs.python.org/file20875/aggressive_normalization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:22:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 16:22:27 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564547.75.0.0843760695302.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

That will also accept invalid names like 'iso88591' that are not valid now, 'iso 8859 1' is already accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:26:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 16:26:15 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298564775.49.0.973192963867.issue11303@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file20875/aggressive_normalization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:30:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 16:30:03 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <4D6680ED.5090305@egenix.com>
Message-ID: <AANLkTika1J3zUHpfxGVHU_mx81tH6tpQBu+Y9bJt-GAm@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 24, 2011 at 11:01 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> On this ticker, we're discussing just one application area: that
> of the builtin short cuts.
>
Fair enough.  I was hoping to close this ticket by simply committing
the posted patch, but it looks like people want to do more.  I don't
think we'll get measurable performance gains but may improve code
understandability.

> To have more encoding name variants benefit from the optimization,
> we might want to enhance that particular normalization function
> to avoid having to compare against "utf8" and "utf-8" in the
> encode/decode functions.

Which function are you talking about?

1. normalize_encoding() in unicodeobject.c
2. normalizestring() in codecs.c

The first is s.lower().replace('-', '_') and the second is
s.lower().replace(' ', '_'). (Note space vs. dash difference.)

Why do we need both?  And why should they be different?

----------
title: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:30:20 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:30:20 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565020.92.0.453727756701.issue11303@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

As promised, here's the list of places where the wrong Latin-1 encoding spelling is used:

Lib//test/test_cmd_line.py:
--         for encoding in ('ascii', 'latin1', 'utf8'):
Lib//test/test_codecs.py:
--         ef = codecs.EncodedFile(f, 'utf-8', 'latin1')
Lib//test/test_shelve.py:
--         shelve.Shelf(d, keyencoding='latin1')[key] = [1]
--         self.assertIn(key.encode('latin1'), d)
Lib//test/test_uuid.py:
--             os.write(fds[1], value.hex.encode('latin1'))
--             child_value = os.read(fds[0], 100).decode('latin1')
Lib//test/test_xml_etree.py:
--     >>> ET.tostring(ET.PI('test', '<testing&>\xe3'), 'latin1')
--     b"<?xml version='1.0' encoding='latin1'?>\\n<?test <testing&>\\xe3?>"
Lib//urllib/request.py:
--             data = base64.decodebytes(data.encode('ascii')).decode('latin1')
Lib//asynchat.py:
--     encoding                = 'latin1'
Lib//sre_parse.py:
--         encode = lambda x: x.encode('latin1')
Lib//distutils/command/bdist_wininst.py:
--             # convert back to bytes. "latin1" simply avoids any possible
--                 encoding="latin1") as script:
--                 script_data = script.read().encode("latin1")
Lib//test/test_bigmem.py:
--         return s.encode("latin1")
--         return bytearray(s.encode("latin1"))
Lib//test/test_bytes.py:
--         self.assertRaises(UnicodeEncodeError, self.type2test, sample, "latin1")
--         b = self.type2test(sample, "latin1", "ignore")
--         b = self.type2test(sample, "latin1")
Lib//test/test_codecs.py:
--         self.assertEqual("\udce4\udceb\udcef\udcf6\udcfc".encode("latin1", "surrogateescape"),
Lib//test/test_io.py:
--     with open(__file__, "r", encoding="latin1") as f:
--         t.__init__(b, encoding="latin1", newline="\r\n")
--         self.assertEqual(t.encoding, "latin1")
--             for enc in "ascii", "latin1", "utf8" :# , "utf-16-be", "utf-16-le":
Lib//ftplib.py:
--     encoding = "latin1"

I'll fix those later today or tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:31:35 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:31:35 +0000
Subject: [issue11303] b'x'.decode('latin1') is much
	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298564410.15.0.973479289946.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D6687E2.20607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I think that the normalization function in unicodeobject.c (only used for internal functions) can skip any character different than a-z, A-Z and 0-9. Something like:
> 
>>>> import re
>>>> def normalize(name): return re.sub("[^a-z0-9]", "", name.lower())
> ... 
>>>> normalize("UTF-8")
> 'utf8'
>>>> normalize("ISO-8859-1")
> 'iso88591'
>>>> normalize("latin1")
> 'latin1'
> 
> So ISO-8859-1, ISO885-1, LATIN-1, latin1, UTF-8, utf8, etc. will be normalized to iso88591, latin1 and utf8.
> 
> I don't know any encoding name where a character outside a-z, A-Z, 0-9 means anything special. But I don't know all encoding names! :-)

I think rather than removing any hyphens, spaces, etc. the
function should additionally:

 * add hyphens whenever (they are missing and) there's switch
   from [a-z] to [0-9]

That way you end up with the correct names for the given set of
optimized encoding names.

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:35:39 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:35:39 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <AANLkTika1J3zUHpfxGVHU_mx81tH6tpQBu+Y9bJt-GAm@mail.gmail.com>
Message-ID: <4D6688D8.1020500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Feb 24, 2011 at 11:01 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> On this ticker, we're discussing just one application area: that
>> of the builtin short cuts.
>>
> Fair enough.  I was hoping to close this ticket by simply committing
> the posted patch, but it looks like people want to do more.  I don't
> think we'll get measurable performance gains but may improve code
> understandability.
> 
>> To have more encoding name variants benefit from the optimization,
>> we might want to enhance that particular normalization function
>> to avoid having to compare against "utf8" and "utf-8" in the
>> encode/decode functions.
> 
> Which function are you talking about?
> 
> 1. normalize_encoding() in unicodeobject.c
> 2. normalizestring() in codecs.c

The first one, since that's being used by the shortcuts.

> The first is s.lower().replace('-', '_') and the second is

It does this: s.lower().replace('_', '-')

> s.lower().replace(' ', '_'). (Note space vs. dash difference.)
> 
> Why do we need both?  And why should they be different?

Because the first is specifically used for the shortcuts
(which can do more without breaking anything, since it's
only used internally) and the second prepares the encoding
names for lookup in the codec registry (which has a PEP100
defined behavior we cannot easily change).

----------
title: b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:35:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 16:35:46 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565346.38.0.475538797853.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ooops, I attached the wrong patch. Here is the new fixed patch.

Without the patch:

>>> import timeit
>>> timeit.Timer("'a'.encode('latin1')").timeit()
3.8540711402893066
>>> timeit.Timer("'a'.encode('latin-1')").timeit()
1.4946870803833008

With the patch:

>>> import timeit
>>> timeit.Timer("'a'.encode('latin1')").timeit()
1.4461820125579834
>>> timeit.Timer("'a'.encode('latin-1')").timeit()
1.463456153869629

>>> timeit.Timer("'a'.encode('UTF-8')").timeit()
0.9479248523712158
>>> timeit.Timer("'a'.encode('UTF8')").timeit()
0.9208409786224365

----------
Added file: http://bugs.python.org/file20876/aggressive_normalization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:36:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 16:36:39 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <4D6687E2.20607@egenix.com>
Message-ID: <AANLkTimQJRjfgEEF0Ff1m8LHiQOSc=A+weAhdZ6AXsfr@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 24, 2011 at 11:31 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> I think rather than removing any hyphens, spaces, etc. the
> function should additionally:
>
> ?* add hyphens whenever (they are missing and) there's switch
> ? from [a-z] to [0-9]
>

This will do the wrong thing to the "cs" family of aliases:

"""
The aliases that start with "cs" have been added for use with the
IANA-CHARSET-MIB as originally defined in RFC3808, and as currently
maintained by IANA at http://www.iana.org/assignments/ianacharset-mib.
Note that the ianacharset-mib needs to be kept in sync with this
registry.  These aliases that start with "cs" contain the standard
numbers along with suggestive names in order to facilitate applications
that want to display the names in user interfaces.  The "cs" stands
for character set and is provided for applications that need a lower
case first letter but want to use mixed case thereafter that cannot
contain any special characters, such as underbar ("_") and dash ("-").
"""

----------
title: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:38:42 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 16:38:42 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565522.48.0.318870485094.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

So happy hacker haypo did it, different however.  It's illegal, but since this is a static function which only serves some specific internal strcmp(3)s it may do for the mentioned charsets.  I won't boot my laptop this evening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:39:09 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:39:09 +0000
Subject: [issue11303] b'x'.decode('latin1') is much
	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298565346.38.0.475538797853.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D6689A7.60907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Ooops, I attached the wrong patch. Here is the new fixed patch.

That won't work, Victor, since it makes invalid encoding
names valid, e.g. 'utf(=)-8'.

We really only want to add the functionality of matching
encodings names with hyphen or not.

Perhaps it's not really worth the trouble as Alexander suggests
and we should simply add the few extra cases where needed.

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:39:57 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 24 Feb 2011 16:39:57 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <AANLkTimQJRjfgEEF0Ff1m8LHiQOSc=A+weAhdZ6AXsfr@mail.gmail.com>
Message-ID: <4D6689DC.7060607@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Feb 24, 2011 at 11:31 AM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> I think rather than removing any hyphens, spaces, etc. the
>> function should additionally:
>>
>>  * add hyphens whenever (they are missing and) there's switch
>>   from [a-z] to [0-9]
>>
> 
> This will do the wrong thing to the "cs" family of aliases:

We don't support those for the shortcut optimizations.

----------
title: b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:41:46 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 16:41:46 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <4D6689A7.60907@egenix.com>
Message-ID: <AANLkTim4YTdcUuGnxk0q6fQXTK57AzTdmmRCR174iYJH@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 24, 2011 at 11:39 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
..
> That won't work, Victor, since it makes invalid encoding
> names valid, e.g. 'utf(=)-8'.
>

.. but this *is* valid:

b'abc'

----------
title: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:43:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 16:43:03 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565783.43.0.440088086062.issue11303@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>>> 'abc'.encode('utf(=)-8')
b'abc'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:43:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 16:43:39 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565819.8.0.0177119956545.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> That won't work, Victor, since it makes invalid encoding
> names valid, e.g. 'utf(=)-8'.

That already works in Python (thanks to encodings.normalize_encoding).
The problem with the patch is that it makes names like 'iso88591' valid.
Normalize to 'iso 8859 1' should solve this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:44:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 16:44:52 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298565892.41.0.223498946762.issue11303@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Marc-Andr?.  It seems too magic and error-prone to do anything else than stripping hyphens and spaces.

Steffen: This is a rather minor change in an area that is well known by several developers, so don?t take it personally that Victor went ahead and made a quick patch.  Patches for other bugs are welcome!  Thanks for your wanting to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:48:22 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Thu, 24 Feb 2011 16:48:22 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298566102.44.0.626168036016.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

That's ok by me.
And 'happy hacker haypo' was not ment unfriendly, i've only repeated the first response i've ever posted back to this tracker (guess who was very fast at that time :)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 17:48:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 16:48:53 +0000
Subject: [issue11234] Error in What's new 3.2rc3 with
	sysconfig.get_config_var('SO')
In-Reply-To: <1297970555.01.0.618977465642.issue11234@psf.upfronthosting.co.za>
Message-ID: <1298566133.81.0.177321867099.issue11234@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11234>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:10:56 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 24 Feb 2011 18:10:56 +0000
Subject: [issue11307] re engine exhaustively explores more than necessary
In-Reply-To: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>
Message-ID: <1298571056.68.0.96383502261.issue11307@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It's a known issue (see issue #1662581, for example).

There's a new implementation at PyPI which doesn't have this problem:

http://pypi.python.org/pypi/regex

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11307>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:18:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 18:18:29 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298571509.91.0.583290959842.issue10868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Committed to py3k as r88545.  You?ll notice that I fixed the nesting of the versionchanged directive and that I changed my mind about ?returns?.  Thanks again!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:28:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Feb 2011 18:28:59 +0000
Subject: [issue11310] Document byte[s|array]() and byte[s|array](count) in
	docstrings
In-Reply-To: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>
Message-ID: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The entry for bytearray(source...) says
"
The optional source parameter can be used to initialize the array in a few different ways:
...
If it is an integer, the array will have that size and will be initialized with null bytes. 
...
Without an argument, an array of size 0 is created.
"
[integer must be non-negative -- patch adds this]
The entry for bytes(source...) refers back to the bytearray entry.

The docstrings for bytes and bytearray omit both possibilities.
Attached is a possible patch to include them.

----------
assignee: docs at python
components: Documentation
files: zbytes.diff
keywords: patch
messages: 129299
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Document byte[s|array]() and byte[s|array](count) in docstrings
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20877/zbytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11310>
_______________________________________

From report at bugs.python.org  Thu Feb 24 19:37:25 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 24 Feb 2011 18:37:25 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298572645.45.0.0648588034832.issue10868@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

In what use-cases would you want to call MyABC.register() when defining a class instead of inheriting from MyABC?

I always thought of the register() as hack to make it possible to support types written in C, which can't inherit from the ABC.

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Thu Feb 24 20:33:43 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Feb 2011 19:33:43 +0000
Subject: [issue11309] #include <wctype.h> in Objects/unicodetype_db.h
	and	Objects/unicodectype.c
In-Reply-To: <1298559104.85.0.0545098544646.issue11309@psf.upfronthosting.co.za>
Message-ID: <1298576023.24.0.668282117.issue11309@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

--with-wctype-functions was removed in 3.2 (see issue9210, r84752)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11309>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:41:56 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 20:41:56 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298580116.67.0.0658455359827.issue11286@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r88546 (3.3) and r88548 (3.2).

Note that a simple work-around before 3.2.1 is to spell encoding as 'latin-1' or 'iso-8859-1' in pickle.loads().

----------
components: +Extension Modules -Library (Lib)
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:48:51 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 24 Feb 2011 20:48:51 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298580531.62.0.943812816926.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm going to commit the patch and then watch whether some of the buildbots turn red.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Thu Feb 24 21:54:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 20:54:29 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298580869.47.0.627728048896.issue11286@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the part of the patch which disallows a NULL data pointer with PyMemoryView_FromBuffer in r88550 and r88551.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:02:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 21:02:04 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298580869.47.0.627728048896.issue11286@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=9Aqr07Ez0133qbr+Wjbv6HTbo2XoR19g1w+Pz@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Feb 24, 2011 at 3:54 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> I've committed the part of the patch which disallows a NULL data pointer
> with PyMemoryView_FromBuffer in r88550 and r88551.

Is it possible to create such buffer in Python (other than by
exploiting a bug or writing a rogue extension module)?  If not, this
should be a SystemError or even just an assert() rather than
ValueError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:06:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 21:06:39 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298581599.76.0.248163906504.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch is a proof of concept to see if Steffen proposal might be viable.

I wrote another normalize_encoding function that implements the algorithm described in msg129259, adjusted the shortcuts and did some timings. (Note: the function is not tested extensively and might break. It might also be optimized further.)

These are the results:
# $ command
# result with my patch
# result without
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('latin1')"
1000000 loops, best of 3: 0.626 usec per loop
100000 loops, best of 3: 2.03 usec per loop
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('latin-1')"
1000000 loops, best of 3: 0.614 usec per loop
1000000 loops, best of 3: 0.616 usec per loop
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('iso-8859-1')"
1000000 loops, best of 3: 0.993 usec per loop
1000000 loops, best of 3: 0.649 usec per loop
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('iso8859_1')"
1000000 loops, best of 3: 1.01 usec per loop
100000 loops, best of 3: 2.08 usec per loop
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('iso_8859_1')"
1000000 loops, best of 3: 0.734 usec per loop
1000000 loops, best of 3: 0.694 usec per loop
wolf at hp:~/dev/py/py3k$ ./python -m timeit "b'x'.decode('utf8')"
1000000 loops, best of 3: 0.728 usec per loop
100000 loops, best of 3: 6.37 usec per loop

----------
Added file: http://bugs.python.org/file20878/issue11303.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:07:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 21:07:19 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <AANLkTi=9Aqr07Ez0133qbr+Wjbv6HTbo2XoR19g1w+Pz@mail.gmail.com>
Message-ID: <1298581635.3722.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I've committed the part of the patch which disallows a NULL data pointer
> > with PyMemoryView_FromBuffer in r88550 and r88551.
> 
> Is it possible to create such buffer in Python (other than by
> exploiting a bug or writing a rogue extension module)?  If not, this
> should be a SystemError or even just an assert() rather than
> ValueError.

I'm against asserts for such use, since they get disabled in non-debug
mode (which is the mode 99.99% of users run in).

As for SystemError, it means "Internal error in the Python interpreter",
which isn't the case here (most likely it's an error in an extension
module instead, possibly a third-party one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:10:04 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 21:10:04 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298581599.76.0.248163906504.issue11303@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=emjzW-v_8KtmzSu+FKxcudaXQe9SRL-JbdTd8@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+    char lower[strlen(encoding)*2];

Is this valid in C-89?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:17:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 21:17:42 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298582262.66.0.172322280183.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Probably not, but that part should be changed if possible, because is less efficient than the previous version that was allocating only 11 bytes.

The problem here is that the previous versions was only changing/removing chars, whereas this might add spaces too, so the string might get longer. E.g. 'utf8' -> 'utf 8'. The worst case is 'a1a1a1' -> 'a 1 a 1 a 1', and including the trailing \0, the result might end up being twice as long than the original encoding string. It can be fixed returning 0 as soon as the normalized string reaches a fixed threshold (something like 15 chars, depending on the longest normalized encoding name).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:20:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 24 Feb 2011 21:20:18 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298582418.18.0.169846402994.issue10868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Someone may want to register with an ABC but not inherit methods or add a class to the mro.  It?s always been allowed by the register method; the new decorator feature is just a very minor nicety on top of that.

Edoardo, was your request motivated by a real use case where you didn?t want to inherit from the ABC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:21:11 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 21:21:11 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298581635.3722.2.camel@localhost.localdomain>
Message-ID: <AANLkTi=7zVzeZaHkUMRQnaQKgNhMV=FFGygBw7X+n1Yr@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It seems appropriate to consult python-dev on this.  I thought
ValueError was for values that are valid Python objects but out of
acceptable range of the function.  Errors that can only be triggered
in C code normally handled with either assert() or raise SystemError.
I think you are splitting hairs too thin by distinguishing between
stdlib and 3rd party extensions.

On Thu, Feb 24, 2011 at 4:07 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> > I've committed the part of the patch which disallows a NULL data pointer
>> > with PyMemoryView_FromBuffer in r88550 and r88551.
>>
>> Is it possible to create such buffer in Python (other than by
>> exploiting a bug or writing a rogue extension module)? ?If not, this
>> should be a SystemError or even just an assert() rather than
>> ValueError.
>
> I'm against asserts for such use, since they get disabled in non-debug
> mode (which is the mode 99.99% of users run in).
>
> As for SystemError, it means "Internal error in the Python interpreter",
> which isn't the case here (most likely it's an error in an extension
> module instead, possibly a third-party one).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11286>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:25:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 21:25:01 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <AANLkTi=7zVzeZaHkUMRQnaQKgNhMV=FFGygBw7X+n1Yr@mail.gmail.com>
Message-ID: <1298582697.3722.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It seems appropriate to consult python-dev on this.  I thought
> ValueError was for values that are valid Python objects but out of
> acceptable range of the function.  Errors that can only be triggered
> in C code normally handled with either assert() or raise SystemError.
> I think you are splitting hairs too thin by distinguishing between
> stdlib and 3rd party extensions.

Hey, I'm not sure who's splitting hairs here... Nick was ok with the
initial patch and that was sufficient as far as I'm concerned, but you
can ask python-dev if you care.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:26:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 21:26:55 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298582815.12.0.789777486332.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the new patch. Looking again, I wonder if there's a reason the original regexp was so complicated. ldconfig output here has lines such as:

	libBrokenLocale.so.1 (libc6,x86-64, OS ABI: Linux 2.6.9) => /lib64/libBrokenLocale.so.1
	libBrokenLocale.so.1 (libc6, OS ABI: Linux 2.6.9) => /lib/libBrokenLocale.so.1
	libBrokenLocale.so (libc6,x86-64, OS ABI: Linux 2.6.9) => /usr/lib64/libBrokenLocale.so
	libBrokenLocale.so (libc6, OS ABI: Linux 2.6.9) => /usr/lib/libBrokenLocale.so

Ideally we would factor out the parsing to a separate private function, and have tests for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:32:22 2011
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 24 Feb 2011 21:32:22 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import StringIO
>>> StringIO.StringIO("foo").readline(0)
'foo'

I don't think this is the correct behavior, or at least it is not consistent with other file objects' readline() which return an empty string with .readline(0).

For example:

>>> import cStringIO
>>> cStringIO.StringIO("foo").readline(0)
''

...or:

>>> file("/usr/bin/python").readline(0)
''

----------
components: Library (Lib)
messages: 129314
nosy: scop
priority: normal
severity: normal
status: open
title: StringIO.readline(0) returns incorrect results
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11311>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:34:36 2011
From: report at bugs.python.org (Jonas H.)
Date: Thu, 24 Feb 2011 21:34:36 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298583276.33.0.277030785512.issue11258@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

As far as I can tell, it doesn't matter.

We're looking for the part after the => in any case - ignoring the ABI/architecture information - so the regex would chose the first of those entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Thu Feb 24 22:41:48 2011
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 24 Feb 2011 21:41:48 +0000
Subject: [issue11312] Confusing sentence in file.readline() doc
In-Reply-To: <1298583708.57.0.612051612173.issue11312@psf.upfronthosting.co.za>
Message-ID: <1298583708.57.0.612051612173.issue11312@psf.upfronthosting.co.za>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

http://docs.python.org/library/stdtypes.html#file.readline

"An empty string is returned only when EOF is encountered immediately."

I think this sentence is misleading especially because the word "only" in it is emphasized, because an empty string is also returned when the size argument is 0 (except for StringIO but I think that's a bug, see #11311).  I suggest rephrasing it as:

"An empty string is returned only when EOF is encountered immediately or the size argument is zero."

...or just removing the sentence altogether.  Text before it already covers the size=0 case.

----------
assignee: docs at python
components: Documentation
messages: 129316
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Confusing sentence in file.readline() doc
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11312>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:07:14 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 24 Feb 2011 22:07:14 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load in
	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298585234.51.0.396745568687.issue11286@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A SystemError indicates that an internal API was given bogus input or produces bogus output (i.e. we screwed up somewhere, or a third party is messing with interfaces they shouldn't be)

If data validation fails for part of the public C API (whether it is visible to Python code or not), then ValueError is the right thing to raise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:29:49 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Feb 2011 22:29:49 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

In Python 3.x default encoding is always utf-8, but encode()/decode() still try to look it up.  Attached patch eliminates a call to normalize_encoding and several strcmp() calls.

----------
files: default-encode.diff
keywords: patch
messages: 129318
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Speed up default encode()/decode()
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file20879/default-encode.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Thu Feb 24 23:30:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Feb 2011 22:30:30 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298586630.36.0.670407476775.issue11313@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:22:44 2011
From: report at bugs.python.org (Aaron Sherman)
Date: Thu, 24 Feb 2011 23:22:44 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>


New submission from Aaron Sherman <ajs at ajs.com>:

I wrote some code a while back which used os.popen. I recently got a warning about popen being deprecated so I tried a test with the new subprocess module. In that test, subprocess.Popen appears to have a 40% process creation overhead penalty over os.popen, which really isn't small. It seems that the difference may be made up of some heavy mmap-related work that's happening in my version of python, and that might be highly platform specific, but the mmap/mremap/munmap calls being made in my sample subprocess code aren't being made at all in the os.popen equivalent.

Now, before someone says, "process creation is trivial, so a 40% hit is acceptable because it's 40% of a trivial part of your execution time," keep in mind that many Python applications are heavily process-creation focused. In my case that means monitoring, but I could also imagine this having a substantial impact on Web services and other applications that spend almost all of their time creating child processes. For a trivial script, subprocess is fine as is, but for these demanding applications, subprocess represents a significant source of pain.

Anyway my testing, results and conclusions are written up here:

http://essays.ajs.com/2011/02/python-subprocess-vs-ospopen-overhead.html

----------
components: Library (Lib)
messages: 129319
nosy: Aaron.Sherman
priority: normal
severity: normal
status: open
title: Subprocess suffers 40% process creation overhead penalty
type: resource usage
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:38:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 23:38:23 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298590703.91.0.599622112886.issue11314@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:43:12 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 23:43:12 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298590992.74.0.290450427385.issue11314@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Python 3.2 has a _posixsubprocess: some parts of subprocess are implemented in C. Can you try it?

Python 3.2 uses also pipe2(), if available, to avoid the extra fcntl(4, F_GETFD)+fcntl(4, F_SETFD, FD_CLOEXEC).

I suppose that the pipe and mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) is used by subprocess to transfer a Python exception from the child process. Python 2.7 encodes the exception value, type and traceback using pickle, and the parent process calls os.read(1048576). Python 3.2 only encodes the exception value and type using a simple string, the parent process uses bytearray with chunks of 50,000 bytes (stop when the total size is bigger than 50,000 bytes). So I suppose that Python 3.2 allocates less memory in the parent process to read the child exception (if any).

You may also try to change Popen buffer size, but it should not change anything if you test "exit 0".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:44:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 24 Feb 2011 23:44:45 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298591085.7.0.176262469006.issue11314@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think your analysis is wrong. These mmap() calls are for anonymous memory, most likely they are emitted by the libc's malloc() to get some memory from the kernel. In other words they will be blazingly fast.

I would suggest you try to dig deeper. For example, how much CPU time does the parent process take (excluding its children).

Of course, I also disagree with the idea that spawning "exit 0" subprocesses is a performance critical operation ;) Therefore, it would be useful to know the absolute overhead difference (in milliseconds) between subprocess and os.popen(), to decide if there is really a problem.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:56:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 23:56:21 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298591781.45.0.843671847574.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

>> That won't work, Victor, since it makes invalid encoding
>> names valid, e.g. 'utf(=)-8'.

> .. but this *is* valid: ...

Ah yes, it's because of encodings.normalize_encoding(). It's funny: we have 3 functions to normalize an encoding name, and each function does something else :-) E.g. encodings.normalize_encoding() doesn't replace non-ASCII letters, and don't convert to lowercase.

more_aggressive_normalization.patch changes all of the 3 normalization functions and add tests on encodings.normalize_encoding().

I think that speed and backward compatibility is more important than conforming to IANA or other standards.

Even if "~~ utf#8 ~~" is ugly, I don't think that it really matter that we accept it.

--

If you don't want to touch the normalization functions and just add more aliases in C fast-paths: we should also add utf8, utf16 and utf32.

Use of "utf8" in Python: random.Random.seed(), smtpd.SMTPChannel.collect_incoming_data(), tarfile, multiprocessing.connection (xml serialization)

PS: On error, UTF-8 decoder raises a UnicodeDecodeError with "utf8" as the encoding name :-)

----------
Added file: http://bugs.python.org/file20880/more_aggressive_normalization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 00:58:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Feb 2011 23:58:13 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298591893.01.0.471280593336.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> more_aggressive_normalization.patch

Woops, normalizestring() comment points to itself.

normalize_encoding() might also points to the C implementations, at least in a "# comment".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 01:12:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Feb 2011 00:12:01 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298592721.2.0.169469262502.issue11313@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Patch looks good.
I checked the tests and couldn't fine any test for .encode()/.decode() without encoding, so I added them in the attached patch.

----------
components: +Interpreter Core
stage:  -> commit review
Added file: http://bugs.python.org/file20881/issue11313.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Fri Feb 25 01:26:00 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Feb 2011 00:26:00 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298593560.35.0.279090165097.issue11313@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Thanks for the review and the tests.  I have found one more place that can be easily optimized.  (See patch below.) The decode() methods in bytes and bytearray are not so easy unfortunately because for some reason they are written to accept any object as self, not only byte/bytearray.  As a result, it is not that easy to short-circuit default case in these instances.   With respect to the patch below, I'll make sure that there is a test for it.


===================================================================
--- Python/getargs.c	(revision 88545)
+++ Python/getargs.c	(working copy)
@@ -1010,8 +1010,6 @@
 
         /* Get 'e' parameter: the encoding name */
         encoding = (const char *)va_arg(*p_va, const char *);
-        if (encoding == NULL)
-            encoding = PyUnicode_GetDefaultEncoding();
 
         /* Get output buffer parameter:
            's' (recode all objects via Unicode) or
@@ -1051,9 +1049,12 @@
                     arg, msgbuf, bufsize);
 
             /* Encode object; use default error handling */
-            s = PyUnicode_AsEncodedString(u,
-                                          encoding,
-                                          NULL);
+            if (encoding == NULL)
+                s = PyUnicode_AsUTF8String(u);
+            else
+                s = PyUnicode_AsEncodedString(u,
+                                              encoding,
+                                              NULL);
             Py_DECREF(u);
             if (s == NULL)
                 return converterr("(encoding failed)",

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Fri Feb 25 01:35:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 00:35:11 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1298594111.2.0.767872019644.issue11171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Barry, could you try reproducing with distutils.sysconfig?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Fri Feb 25 02:21:20 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Feb 2011 01:21:20 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <1298596880.54.0.983743001922.issue11313@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed issue11313.diff in revision 88553.

On the second thought, the getargs optimization is not worth the trouble because in existing sources 'e' code is used with constant encodings and one is unlikely to pass NULL as an encoding because that is equivalent to eliding the 'e' code altogether.

I will keep this issue open to consider whether remaining  

        if (encoding == NULL)
            encoding = PyUnicode_GetDefaultEncoding();

clauses can be simply removed because the lower level code accepts NULL in encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Fri Feb 25 03:36:25 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Feb 2011 02:36:25 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1298594111.2.0.767872019644.issue11171@psf.upfronthosting.co.za>
Message-ID: <20110224213614.6cc6e3e2@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 25, 2011, at 12:35 AM, ?ric Araujo wrote:

>?ric Araujo <merwok at netwok.org> added the comment:
>
>Barry, could you try reproducing with distutils.sysconfig?

I'm not quite sure what you mean, but configuring Python 3.1 with different
--prefix and --exec-prefix works just fine.

----------
title: Python 2.7.1 does not start when "./configure" is used with  "--prefix" != "--exec-prefix" -> Python 2.7.1 does not start when "./configure" is used with "--prefix" != "--exec-prefix"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Fri Feb 25 04:55:12 2011
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 25 Feb 2011 03:55:12 +0000
Subject: [issue11287] Add context manager support to dbm modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298606112.37.0.385811947618.issue11287@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Here is the patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file20882/issue11287.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11287>
_______________________________________

From report at bugs.python.org  Fri Feb 25 05:05:03 2011
From: report at bugs.python.org (Alexander Tsepkov)
Date: Fri, 25 Feb 2011 04:05:03 +0000
Subject: [issue11315] Cookie.py breaks when passed unicode, fix included
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>


New submission from Alexander Tsepkov <atsepkov at gmail.com>:

in Lib/Cookie.py, BaseCookie load() method performs the following comparison on line 624:

str(rawdata) == str("")

This breaks when a unicode string is passed in for rawdata. I've included a patch that fixes this issue by using isinstance(rawdata, basestring) comparison instead. Additionally the patch encodes rawdata in ascii before sending it to __ParseString() since that method does not support unicode.

----------
components: Unicode
files: cookie_patch.patch
keywords: patch
messages: 129330
nosy: Alexander.Tsepkov
priority: normal
severity: normal
status: open
title: Cookie.py breaks when passed unicode, fix included
versions: Python 2.6
Added file: http://bugs.python.org/file20883/cookie_patch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Feb 25 05:26:57 2011
From: report at bugs.python.org (Alex)
Date: Fri, 25 Feb 2011 04:26:57 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1298608017.12.0.0202128387297.issue11311@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Fun fact: io.StringIO does the right thing, but _io and _pyio.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11311>
_______________________________________

From report at bugs.python.org  Fri Feb 25 06:51:50 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 05:51:50 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298613110.03.0.852516393346.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

A slightly revised patch committed in revision 88554:

1. Fixed ?ric's whitespace comment
2. Fixed a test in test_descrtut.py which was listing list's methods
3. Moved the change to collections.py onto Lib/collections/__init__.py
4. Added NEWS entry

?ric - as I mentioned earlier in this issue, I chose to leave the syntax of the docstring for the new methods similar to the same methods in dict (dict docstring look better and more internally consistent anyhow). I propose to move further discussion of this matter into a separate issue which will deal with the overall (in)consistency in the docstrings of list and dict.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 07:01:52 2011
From: report at bugs.python.org (Aaron Sherman)
Date: Fri, 25 Feb 2011 06:01:52 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298613712.05.0.128691321633.issue11314@psf.upfronthosting.co.za>


Aaron Sherman <ajs at ajs.com> added the comment:

"Python 3.2 has a _posixsubprocess: some parts of subprocess are implemented in C. Can you try it?"

I don't have a Python 3 installation handy, but I can see what I can do tomorrow evening to get one set up and try it out.

"disagree with the idea that spawning "exit 0" subprocesses is a performance critical operation ;)"

How else would you performance test process creation overhead? By introducing as little additional overhead as possible, it's possible for me to get fairly close to measuring just the subprocess module's overhead.

If you stop to think about it, though, this is actually a shockingly huge percent increase. In any process creation scenario I'm familiar with, its overhead should be so small that you could bump it up several orders of magnitude and still not compete with executing a shell and asking it to do anything, even just exit.

And yet, here we are. 40%

I understand that most applications won't be running massive numbers of external commands in parallel, and that's the only way this overhead will really matter (at least that I can think of). But in the two scenarios I mentioned (monitoring and Web services such as CGI, neither of which is particularly rare), this is going to make quite a lot of difference, and if you're going to deprecate os.popen, I would think that making sure your proposed replacement was at least nearly as performant would be standard procedure, no?

"I think your analysis is wrong. These mmap() calls are for anonymous memory, most likely they are emitted by the libc's malloc() to get some memory from the kernel. In other words they will be blazingly fast."

The mremap might be a bit of a performance hit, but it's true that these calls should not be substantially slowing execution... then again, they might indicate that there's substantial amounts of work being done for which memory allocation is required, and as such may simply be a symptom of the actual problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 08:36:34 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 07:36:34 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298619394.22.0.176823122667.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Following the python-dev discussion, attaching a patch for removing fcmp and replacing its uses with assertAlmostEqual when needed.

All tests pass and patchcheck is clean.

Please review before I commit.

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file20884/issue11015.py3k.remove_fcmp.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:08:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 08:08:40 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298621320.41.0.351652990717.issue11015@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The divmod() part of the patch is wrong: assertAlmostEqual does not support tuple arguments.

The test succeeds because it first does an exact equality check, which apparently is true on your platform.  But if it wasn't, you'd get TypeErrors.

Also, fcmp() has a different definition of what "almost equal" means, but I assume this has been regarded in the discussion.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:11:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 08:11:00 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298621460.51.0.289487812013.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reading "clear and copy are not supported by bytearray": shouldn't they be?  ("sort" probably really makes no sense on bytearrays.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:32:38 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 08:32:38 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <AANLkTi=9Aqr07Ez0133qbr+Wjbv6HTbo2XoR19g1w+Pz@mail.gmail.com>
Message-ID: <4D676923.6020505@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Thu, Feb 24, 2011 at 3:54 PM, Antoine Pitrou <report at bugs.python.org> wrote:
> ..
>> I've committed the part of the patch which disallows a NULL data pointer
>> with PyMemoryView_FromBuffer in r88550 and r88551.
> 
> Is it possible to create such buffer in Python (other than by
> exploiting a bug or writing a rogue extension module)?  If not, this
> should be a SystemError or even just an assert() rather than
> ValueError.

We normally raise a SystemError for invalid NULL pointers, not
ValueErrors.

SystemError is used for things that go wrong at the C level and
indicate a likely programming error at that level. The origin of
that error is not important, but the check will usually happen
in the interpreter.

FWIW, it's also used in C extensions for much the same reason,
so in the wild you'll also find SystemErrors raised by
3rd party extensions.

----------
title: Some "trivial" python 2.x pickles fails to load in Python 3.2 -> Some "trivial" python 2.x pickles fails to load in	Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Fri Feb 25 09:36:05 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 08:36:05 +0000
Subject: [issue11313] Speed up default encode()/decode()
In-Reply-To: <1298586589.12.0.407554806858.issue11313@psf.upfronthosting.co.za>
Message-ID: <4D6769F1.7090602@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
> 
> In Python 3.x default encoding is always utf-8, but encode()/decode() still try to look it up.  Attached patch eliminates a call to normalize_encoding and several strcmp() calls.

+1.

Please add a comment explaining why this can be done.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11313>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:30:01 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 09:30:01 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298626201.02.0.0537082771643.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg,

Good catch on the tuples in assertAlmostEqual, thanks! I see three methods of resolution:

1. Since the floats in this case are powers of 1/2, they could be tested for exact equality, or do you figure there are platforms where this is not guaranteed?
2. I can make a local change in the test to assertAlmostEqual on each member of the tuple
3. assertAlmostEqual on tuples can be added to the unittest module

Any ideas?

I can also commit (2) for the time being since it's the least dubious, and leave the resolution on 1 & 3 for later (and/or in separate issues).

Regarding fcmp being not exactly assertAlmostEqual - it was discussed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:36:53 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 09:36:53 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298626613.72.0.825083812537.issue11015@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(2) would be my choice.  (1) *should* be true, but this is a change in the test semantics.  (3) would be feature creep and I don't think it's a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:48:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 09:48:54 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298627334.08.0.292194098351.issue11015@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a revised patch with (2) implemented.

----------
Added file: http://bugs.python.org/file20885/issue11015.py3k.remove_fcmp.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:56:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 09:56:23 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1298621460.51.0.289487812013.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTimVCJ8mQwnyTZs=14daUdX252bFPt1=Xy2V2fNz@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Fri, Feb 25, 2011 at 10:11, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Reading "clear and copy are not supported by bytearray": shouldn't they be?

Perhaps they should, and it's not a big deal to implement. But I'm not
100% clear on the policy of how such changes are approved. Should this
be discussed in the list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 10:57:02 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 09:57:02 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1296009969.38.0.282241852849.issue11015@psf.upfronthosting.co.za>
Message-ID: <1298627822.58.0.957412344243.issue11015@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, that looks good now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:12:02 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2011 10:12:02 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298628722.9.0.617165020446.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Unless someone raises a controversial and non-trivial issue about adding clear() and copy() to bytearray, there is no need for a python-dev discussion on the subject.  Just post a patch to the tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:13:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 10:13:34 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298628814.9.0.568764605324.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, it should be discussed on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:15:44 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 25 Feb 2011 10:15:44 +0000
Subject: [issue11015] Bring test.support docs up to date
In-Reply-To: <1298627822.58.0.957412344243.issue11015@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=E995nQf+vb-CwNADXfYE4TSKUFPzn1i0j-WJA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

> Georg Brandl <georg at python.org> added the comment:
>
> Yes, that looks good now.
>

Thanks. fcmp & FUZZ removal committed in revision 88558

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11015>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:23:40 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 10:23:40 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1298629420.23.0.568578111447.issue11222@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Does this need to be backported?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:37:52 2011
From: report at bugs.python.org (Georges Martin)
Date: Fri, 25 Feb 2011 10:37:52 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>


New submission from Georges Martin <jrjsmrtn at gmail.com>:

Both httplib.HTTPMessage and email.message.Message classes[1] implements methods for RFC822 headers parsing. Unfortunately, they have different implementations and they do not provide the same level of functionality.

One example that is bugging me is that:

* httplib.HTTPMessage is missing the get_filename method present in email.message.Message, that allows you to easily retrieve the filename from a 'Content-disposition: attachment; filename="fghi.xyz"' header;

* httplib.HTTPMessage has getparam, getplist and parseplist methods but AFAIK, they are not and cannot be used outside of the 'content-type' header parsing;

* email.message.Message has a generic get_param method to parse any RFC822 header with parameters, such as 'content-disposition' or 'content-type'.

The workaround I'm using is to decorate an httplib.HTTPMessage with the missing methods from email.message.Message:

    def monkeypatch_http_message(obj):
        """ Decorate an httplib.HTTPMessage instance's class 
            with the RFC822 header parameters parsing methods 
            from email.message.Message. (thanks to ncoghlan)
        """
        import httplib
        assert isinstance(obj, httplib.HTTPMessage)
        cls = obj.__class__
    
        from email import utils
        from email.message import (
            _parseparam, 
            _unquotevalue, 
            Message
        )
        funcnames = (
            '_get_params_preserve', 
            'get_params', 
            'get_param',
            'get_filename'
        )
        for funcname in funcnames:
            cls.__dict__[funcname] = Message.__dict__[funcname]

So I can do:

    import mechanize
    from some.module import monkeypatch_http_message
    browser = mechanize.Browser()
    
    # in that form, browser.retrieve returns a temporary filename 
    # and an httplib.HTTPMessage instance
    (tmp_filename, headers) = browser.retrieve(someurl) 

    # monkeypatch the httplib.HTTPMessage instance
    monkeypatch_http_message(headers)

    # yeah... my original filename, finally
    filename = headers.get_filename()

----------
components: Library (Lib)
messages: 129348
nosy: jrjsmrtn
priority: normal
severity: normal
status: open
title: RFC822 header parsing API inconsistencies between httplib.HTTPMessage and email.message.Message
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:44:42 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 25 Feb 2011 10:44:42 +0000
Subject: [issue11222] Python3.2rc3 fails to build on Mac OS X with a
	non-framework build
In-Reply-To: <1297853647.12.0.982749449302.issue11222@psf.upfronthosting.co.za>
Message-ID: <1298630682.7.0.503835229594.issue11222@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

No backport is needed. The problem was introduced during the 3.2 development cycle by the ABI Version Tagged .so Files feature (PEP 3149).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11222>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:48:38 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 25 Feb 2011 10:48:38 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298630918.06.0.000134481049779.issue11314@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> If you stop to think about it, though, this is actually a shockingly huge percent increase. In any process creation scenario I'm familiar with, its overhead should be so small that you could bump it up several orders of magnitude and still not compete with executing a shell and asking it to do anything, even just exit.

os.popen just calls the popen(3) library call, which just performs a fork/execve and some dup/close in between.
subprocess.Popen is implemented in Python, so it doesn't come as a surprise that it's slower in your example.
But I think there's a point you're missing: you're not just creating a child process, but a shell.
subprocess is actually faster than popen to spawn executables (not scripts), because you don't have to spawn a shell.

For example:

$ cat /tmp/test.c 
int main(int argc, char *argv[])
{
        return 0;
}

$ cat /tmp/test_subprocess.py 
import subprocess

for i in range(10000):
    f = subprocess.Popen('/tmp/test')
    f.wait()

$ cat /tmp/test_popen.py 
import os

for i in range(10000):
    f = os.popen('/tmp/test')
    f.close()

$ time ./python /tmp/test_subprocess.py

real    0m13.933s
user    0m3.083s
sys     0m12.441s

$ time ./python /tmp/test_popen.py 

real    0m18.235s
user    0m4.293s
sys     0m15.176s

Given of important the subprocess overhead seems to you, I guess that the processes you're launching are not shell scripts, and thus you're probably better off using subprocess.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 11:57:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 10:57:49 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1298631469.65.0.849333371084.issue10360@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Backported to 3.1 in r88556, and 2.7 in r88564.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:07:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 11:07:01 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298632021.87.0.678352357367.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In any case, this issue can be closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:14:02 2011
From: report at bugs.python.org (Laurence Rowe)
Date: Fri, 25 Feb 2011 11:14:02 +0000
Subject: [issue11317] Documentation not updated to show string exceptions have
	been deprecated
In-Reply-To: <1298632442.51.0.260664855458.issue11317@psf.upfronthosting.co.za>
Message-ID: <1298632442.51.0.260664855458.issue11317@psf.upfronthosting.co.za>


New submission from Laurence Rowe <l at lrowe.co.uk>:

The documentation at http://docs.python.org/c-api/exceptions.html#deprecation-of-string-exceptions states that "String exceptions are still supported in the interpreter to allow existing code to run unmodified, but this will also change in a future release." String exceptions were removed in 2.6.

----------
assignee: docs at python
components: Documentation
messages: 129353
nosy: docs at python, lrowe
priority: normal
severity: normal
status: open
title: Documentation not updated to show string exceptions have been deprecated
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11317>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:20:29 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 11:20:29 +0000
Subject: [issue11317] Documentation not updated to show string exceptions have
	been deprecated
In-Reply-To: <1298632442.51.0.260664855458.issue11317@psf.upfronthosting.co.za>
Message-ID: <1298632829.37.0.677375027595.issue11317@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r88571.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11317>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:20:59 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 11:20:59 +0000
Subject: [issue941346] AIX shared library fix
Message-ID: <1298632859.89.0.910614434605.issue941346@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Backported to 3.1 in r88560, 2.7 in r88568.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue941346>
_______________________________________

From report at bugs.python.org  Fri Feb 25 12:21:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 11:21:15 +0000
Subject: [issue11184] Broken large file support on AIX
In-Reply-To: <1297424272.24.0.654682014672.issue11184@psf.upfronthosting.co.za>
Message-ID: <1298632875.06.0.614001873533.issue11184@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Backported to 3.1 in r88562, 2.7 in r88569.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11184>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:25:15 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 12:25:15 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

I have found a possible typo in an example code of Python 3.2. It's located on page 32 in the PDF version of the FAQ document. The code is:

class C:
    count = 0 # number of times C.__init__ called

def __init__(self):
    C.count = C.count + 1

def getcount(self):
    return C.count # or return self.count

The code block of the __init__ method is the thing that has the typo. Shouldn't  C.count = C.count + 1  be  c.count = C.count + 1 ?  Because the text after this code example says:

c.count also refers to C.count for any c such that isinstance(c, C) holds /.../.

How can c.count also refer to C.count if there is no c.count in the present code example in the FAQ of Python 3.2?

If this is a typo, please fix it for Python 3.2 and also for other Python versions with the same typo.

Else if this is not a typo, explain how can c.count refer to C.count if there is no c.count in the code example.

----------
assignee: docs at python
components: Documentation
messages: 129357
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python 3.2 FAQ example code typo?
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:31:44 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 12:31:44 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1298632021.87.0.678352357367.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTikb+VcxEUcL9qydHQKR_0hrM0_euBE=587MA6T-@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I have installed Python 3.2 final on my Windows machine and I get an
exception when doing list.copy or list.clear in the interpreter. Why is that
so?

----------
Added file: http://bugs.python.org/file20886/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
I have installed Python 3.2 final on my Windows machine and I get an exception when doing list.copy or list.clear in the interpreter. Why is that so?

From report at bugs.python.org  Fri Feb 25 13:38:10 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 12:38:10 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298637490.23.0.749092326815.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Because they got added *after* 3.2 was released?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 13:38:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Fri, 25 Feb 2011 12:38:45 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298637525.67.0.409758082019.issue11303@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Not issue related)
Ezio and Alexander: after reading your posts and looking back on my code: you're absolutely right.  Doing resize(31) is pointless: it doesn't save space (mempool serves [8],16,24,32 there; and: dynamic, normalized coded names don't exist that long in real life, too).  And append_char() is inlined but much more expensive than doing (register-loaded) *(target++)=char.  Thus i now do believe my code is a bug and i will rewrite doing *target=cstr(resize(len(input)*2)) ... truncate() instead!
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:05:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 13:05:56 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298639156.71.0.939517893896.issue11316@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:06:22 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 13:06:22 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298639182.15.0.64803626065.issue11316@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type: behavior -> feature request
versions: +Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:16:30 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 13:16:30 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1298639790.91.0.0754199791794.issue10743@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

I think that this issue needs to be reopened... since it never has been resolved...
I just downloaded the new version of Python 3.2 and tried to compile, install and use it on Redhat Linux.

Installation went fine (configure with --prefix=/usr/mysoft/python32)...

But when using Python I get the following error message:
Traceback (most recent call last):
  File "/usr/mysoft/python32/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/usr/mysoft/python32/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 'lib/python3.2/config-3.2m/Makefile'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/mysoft/python32/lib/python3.2/site.py", line 529, in <module>
    main()
  File "/usr/mysoft/python32/lib/python3.2/site.py", line 517, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/mysoft/python32/lib/python3.2/site.py", line 263, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/mysoft/python32/lib/python3.2/site.py", line 238, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/mysoft/python32/lib/python3.2/site.py", line 228, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/mysoft/python32/lib/python3.2/sysconfig.py", line 590, in get_config_var
    return get_config_vars().get(name)
  File "/usr/mysoft/python32/lib/python3.2/sysconfig.py", line 487, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/mysoft/python32/lib/python3.2/sysconfig.py", line 337, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open lib/python3.2/config-3.2m/Makefile (No such file or directory)

... I never heard about virtualenv before and I don't know what is the impact of that library, but I guess a just released version of Python should work out of the box?!? (Final 3.2 release)
(I was using Python 3.1.3 on the same machine without any hitch...)

----------
nosy: +palm.kevin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:23:28 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 13:23:28 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298640208.93.0.850735850736.issue11318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Read a little further:

    Caution: within a method of C, an assignment like ``self.count = 42`` creates a new and unrelated instance named "count" in ``self``'s own dict.

That is, c.count refers to C.count right up until the point where c.count is assigned a value.  So, c.count = c.count + 1 will add one to the current value of C.count, and assign it to the *instance* variable c.count.  c.count at that point no longer refers to the *class* variable C.count.  Thus your change to the __init__ function would completely defeat the purpose of the example (which is to show how to use a *class* variable.

If you can suggest a concise wording that would have made this clearer to you, we can consider a doc patch.

----------
nosy: +r.david.murray
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:27:40 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 13:27:40 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298640460.0.0.502426791959.issue11318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Rereading your message, is seems like you just didn't understand the statement "c.count refers to C.count for any...".  That is a statement about how the language behaves.  If there is not yet an instance variable 'count', but a class variable 'count' exists, then the value of the class variable is used when c.count is evaluated.  A class is a two level nested name space with a couple of special properties.

I don't really see any way to make that statement clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:34:14 2011
From: report at bugs.python.org (Georges Martin)
Date: Fri, 25 Feb 2011 13:34:14 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298640854.81.0.509944194672.issue11316@psf.upfronthosting.co.za>


Georges Martin <jrjsmrtn at gmail.com> added the comment:

Hello, David.

According to issue4773, httplib.HTTPMessage in Python 3.x is using email.message.Message underneath, so my issue is only with 2.6 (I've not checked 2.7).

Georges

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 14:51:24 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 13:51:24 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1298637490.23.0.749092326815.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTiko2VLZXkRDc52per0ZkRjYucCvsaUARYQ+5dD_@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Right, right. My bad. Can't wait for Python 3.3! ;)

----------
Added file: http://bugs.python.org/file20887/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
Right, right. My bad. Can&#39;t wait for Python 3.3! ;)

From report at bugs.python.org  Fri Feb 25 14:57:40 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 13:57:40 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298640460.0.0.502426791959.issue11318@psf.upfronthosting.co.za>
Message-ID: <AANLkTikGuEGJvr__xJs99eyMGJ0edOzPGSaGtdHOaWCu@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

>
> Caution: within a method of C, an assignment like ``self.count = 42``
> creates a new and unrelated instance named "count" in ``self``'s own dict.

More clear is to say *Caution: within a method of class C, an assignment
like ``self.count = 42`` creates a new and unrelated instance named "count"
in ``self``'s own dict.*
*
*

----------
Added file: http://bugs.python.org/file20888/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________
-------------- next part --------------
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(32, 32, 32); font-family: &#39;Droid Sans&#39;, arial, sans-serif; font-size: 13px; ">Caution: within a method of C, an assignment like ``self.count = 42`` creates a new and unrelated instance named &quot;count&quot; in ``self``&#39;s own dict.</span></blockquote>
<div><br></div><div>More clear is to say <span class="Apple-style-span" style="border-collapse: collapse; color: rgb(32, 32, 32); font-family: &#39;Droid Sans&#39;, arial, sans-serif; font-size: 13px; "><i>Caution: within a method of class C, an assignment like ``self.count = 42`` creates a new and unrelated instance named &quot;count&quot; in ``self``&#39;s own dict.</i></span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(32, 32, 32); font-family: &#39;Droid Sans&#39;, arial, sans-serif; font-size: 13px; "><i><br></i></span></div>

From report at bugs.python.org  Fri Feb 25 14:58:46 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 13:58:46 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1298642326.84.0.169634255431.issue10743@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

Please find here a small C app embedding python that shows  how to reproduce the problem (It turned out that the problem is caused by the new method "Py_SetPath"): 

#include "Python.h"

main(int argc, char **argv)
{
  Py_SetPath(Py_GetPath());
  printf("Init\n");
  Py_Initialize();
  printf("-- END\n");
}


--> Python crashes on Py_Initialize... only if the Py_SetPath is executed...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:00:59 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsO0bWUgUmFkaXg=?=)
Date: Fri, 25 Feb 2011 14:00:59 +0000
Subject: [issue11319] Command line option -t (and -tt) does not work for a
	particular case
In-Reply-To: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>
Message-ID: <1298642459.32.0.849604846008.issue11319@psf.upfronthosting.co.za>


New submission from J?r?me Radix <jerome.radix at gmail.com>:

The attached example mixes tabs and spaces but python does not report any warning when used with -t.

Line 4 contains 1 tab. Lines after line 4 contains spaces.

Tested using :
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on win32

C:\>python -t test_tt.py

C:\>

----------
components: Interpreter Core
files: test_tt.py
messages: 129368
nosy: jerome.radix
priority: normal
severity: normal
status: open
title: Command line option -t (and -tt) does not work for a particular case
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file20889/test_tt.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11319>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:06:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 14:06:41 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298642801.52.0.25077856188.issue11316@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, yes, you are correct.   We must reject this, then, since 2.7 is now feature frozen and this is a feature request.

----------
resolution:  -> out of date
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:18:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 14:18:38 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1298642326.84.0.169634255431.issue10743@psf.upfronthosting.co.za>
Message-ID: <1298643513.3739.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 25 f?vrier 2011 ? 13:58 +0000, Palm Kevin a ?crit :
> Palm Kevin <kevin.palm at labsolution.lu> added the comment:
> 
> Please find here a small C app embedding python that shows  how to
> reproduce the problem (It turned out that the problem is caused by the
> new method "Py_SetPath"): 

Can you open a separate issue?
Also, please include your error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:24:34 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Feb 2011 14:24:34 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
Message-ID: <1298643874.75.0.741568182299.issue11253@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Can you provide a patch, or show how to do it concretely?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11253>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:32:03 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 14:32:03 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
	Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>


New submission from Palm Kevin <kevin.palm at labsolution.lu>:

The new API method Py_SetPath seems bugged. When executing the following code, then the application crashes on Py_Initialize()-call:
#include "Python.h"

main(int argc, char **argv)
{
  Py_SetPath(Py_GetPath());
  printf("Init\n");
  Py_Initialize();
  printf("-- END\n");
}

The raised exception is the following:

Traceback (most recent call last):
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 332, in _init_posix
    _parse_makefile(makefile, vars)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 220, in _parse_makefile
    with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 'lib/python3.2/config-3.2m/Makefile'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 529, in <module>
    main()
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 517, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 263, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 238, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/labsolution/python32/lib/python3.2/site.py", line 228, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 590, in get_config_var
    return get_config_vars().get(name)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 487, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/labsolution/python32/lib/python3.2/sysconfig.py", line 337, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open lib/python3.2/config-3.2m/Makefile (No such file or directory)

(perhaps linked to issue #10743 ?!)

----------
components: Interpreter Core
messages: 129372
nosy: palm.kevin
priority: normal
severity: normal
status: open
title: Usage of API method Py_SetPath causes errors in Py_Initialize() (Posix ony))
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:32:29 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 14:32:29 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1298644349.84.0.901830741321.issue10743@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

Done: #11320

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:34:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 14:34:28 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
	Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1298644468.83.0.47970625405.issue11320@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, tarek
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:39:40 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 14:39:40 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298644780.98.0.479824721529.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r88580.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Feb 25 15:56:12 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 14:56:12 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1298645772.76.0.216003717708.issue11232@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:03:04 2011
From: report at bugs.python.org (Georges Martin)
Date: Fri, 25 Feb 2011 15:03:04 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298642801.52.0.25077856188.issue11316@psf.upfronthosting.co.za>
Message-ID: <AANLkTimg3wKZdj9UX98rJ=RsD6dx5-vurhOH6kLfdFkg@mail.gmail.com>


Georges Martin <jrjsmrtn at gmail.com> added the comment:

No problem. I thought important that the issue and a workaround were
documented somehow... :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:08:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 15:08:55 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298646535.19.0.0683447268801.issue11314@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> But in the two scenarios I mentioned (monitoring and Web services such 
> as CGI, neither of which is particularly rare), this is going to make
> quite a lot of difference

That's why I asked for absolute numbers for the overhead difference. A percentage doesn't tell me if launching a process costs 50?s more or 500ms more.

The only question is whether process launch overhead is significant compared to total process runtime (for non-trivial work, that is, not "echo 0" ;-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:11:07 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 15:11:07 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298646667.98.0.191042582695.issue11259@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Can you provide a patch including a test case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:11:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 15:11:25 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298646685.53.0.903130132949.issue11314@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:12:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 15:12:58 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298646778.29.0.990846926716.issue11314@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Okay, thanks to Charles-Fran?ois' measurements, we can deduce that each subprocess launch is at most 0.3ms of user CPU time and 1.2ms of system CPU time. IMO that's not a real problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:16:56 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 15:16:56 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1298647016.66.0.471829766565.issue11232@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please add the revision number when fixing.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:24:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 15:24:27 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298647467.71.0.185814773467.issue10882@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Three comments:

* When changing configure.in, you also should regenerate configure.  (Now done in r88584).

* PyParse_off_t is a bad name for this function.  It is not a new C API, so it should be static, and therefore there is no need for the Py prefix.
Changed this to _parse_off_t in r88585.

* The whitespace cleanup should have been committed separately.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:31:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 15:31:37 +0000
Subject: [issue11316] RFC822 header parsing API inconsistencies between
	httplib.HTTPMessage and email.message.Message
In-Reply-To: <1298630272.85.0.58708707749.issue11316@psf.upfronthosting.co.za>
Message-ID: <1298647897.8.0.891368673743.issue11316@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, thanks for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11316>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:43:06 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 15:43:06 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298648586.43.0.590678188608.issue11303@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

r88586: Normalized the encoding names for Latin-1 and UTF-8 to
'latin-1' and 'utf-8' in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:51:21 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 15:51:21 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>


New submission from Palm Kevin <kevin.palm at labsolution.lu>:

Please have a look to the following app:

#include "Python.h"

main(int argc, char **argv)
{
  int i;
  printf("START\n");
  for(i = 0; i < 20; i++){
    Py_Initialize();

    printf("Try import #%i ...", i);
    PyRun_SimpleString("import _pickle\n");

    printf("SUCCESS\n");
    Py_Finalize();
  }
  printf("END\n");
}


If I run that app (Linux), then I get the following output:

START
Try import #0 ...SUCCESS
Try import #1 ...SUCCESS
Try import #2 ...SUCCESS
Try import #3 ...SUCCESS
Try import #4 ...SUCCESS
Try import #5 ...SUCCESS
Try import #6 ...SUCCESS
Try import #7 ...SUCCESS
Segmentation fault


It systematically crashes on the 9th call ...
Does anybody know the reason of this segmentation fault problem??

----------
components: Interpreter Core
messages: 129384
nosy: palm.kevin
priority: normal
severity: normal
status: open
title: 9th import of module _pickle always crashes
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:51:44 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 15:51:44 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298649104.24.0.124655807824.issue11303@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think we should reset this whole discussion and just go with Alexander's original patch issue11303.diff.

I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation.

The original version used the .translate() method which is a lot faster.

I'll open a new issue for that part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:52:09 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 15:52:09 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298649129.14.0.857239850811.issue11321@psf.upfronthosting.co.za>


Changes by Palm Kevin <kevin.palm at labsolution.lu>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:55:32 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 15:55:32 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is too
	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation.

The original version used the .translate() method which is a lot faster and can be adapted to work with the Unicode variant of the .translate() method just as well.

_norm_encoding_map = ('                                              . '
                      '0123456789       ABCDEFGHIJKLMNOPQRSTUVWXYZ     '
                      ' abcdefghijklmnopqrstuvwxyz                     '
                      '                                                '
                      '                                                '
                      '                ')

def normalize_encoding(encoding):

    """ Normalize an encoding name.

        Normalization works as follows: all non-alphanumeric
        characters except the dot used for Python package names are
        collapsed and replaced with a single underscore, e.g. '  -;#'
        becomes '_'. Leading and trailing underscores are removed.

        Note that encoding names should be ASCII only; if they do use
        non-ASCII characters, these must be Latin-1 compatible.

    """
    # Make sure we have an 8-bit string, because .translate() works
    # differently for Unicode strings.
    if hasattr(__builtin__, "unicode") and isinstance(encoding, unicode):
        # Note that .encode('latin-1') does *not* use the codec
        # registry, so this call doesn't recurse. (See unicodeobject.c
        # PyUnicode_AsEncodedString() for details)
        encoding = encoding.encode('latin-1')
    return '_'.join(encoding.translate(_norm_encoding_map).split())

----------
components: Unicode
messages: 129386
nosy: lemburg
priority: normal
severity: normal
status: open
title: encoding package's normalize_encoding() function is too slow
type: performance
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Fri Feb 25 16:56:58 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 15:56:58 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298649104.24.0.124655807824.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D67D148.3000904@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> I don't know who changed the encoding's package normalize_encoding() function (wasn't me), but it's a really slow implementation.
> 
> The original version used the .translate() method which is a lot faster.

I guess that's one of the reasons why Alexander found such a dramatic
difference between the shortcut variant of the names and the ones
going through the registry.

> I'll open a new issue for that part.

issue11322

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:06:32 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Feb 2011 16:06:32 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1298639790.91.0.0754199791794.issue10743@psf.upfronthosting.co.za>
Message-ID: <20110225110626.62c6a231@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Feb 25, 2011, at 01:16 PM, Palm Kevin wrote:

>I think that this issue needs to be reopened... since it never has been
>resolved...  I just downloaded the new version of Python 3.2 and tried to
>compile, install and use it on Redhat Linux.
>
>Installation went fine (configure with --prefix=/usr/mysoft/python32)...

On Ubuntu 10.10, I built Python 3.2 from the svn head with
--prefix=/tmp/prefix, did a 'make install' and then ran
/tmp/prefix/bin/python.  It worked fine and I did not get the exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:12:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Feb 2011 16:12:54 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is too
	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298650374.53.0.4800614689.issue11322@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:34:59 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Feb 2011 16:34:59 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is too
	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298651699.02.0.133644747744.issue11322@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't think the normalize_encoding() function was the culprit for issue11303 because I measured timings with timeit which averages multiple runs while normalize_encoding() is called only the one time per encoding spelling due to caching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Fri Feb 25 17:54:30 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 16:54:30 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <AANLkTikGuEGJvr__xJs99eyMGJ0edOzPGSaGtdHOaWCu@mail.gmail.com>
Message-ID: <AANLkTimU_qcpKUuZDj5H7pD6cRxvGBQSFRpPaX9Qca+t@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

So you're saying that if a class' name is C, then c.count is the same as
C.count? I thought Python is case-sensitive. You know: c (small letter c) is
not equal to C (big letter C) in Python. I don't understand what you mean by
c.count because my intepreter always throws an exception that c is not
defined if I feed it with this code example and do   >>> c.count

----------
Added file: http://bugs.python.org/file20890/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________
-------------- next part --------------
So you&#39;re saying that if a class&#39; name is C, then c.count is the same as C.count? I thought Python is case-sensitive. You know: c (small letter c) is not equal to C (big letter C) in Python. I don&#39;t understand what you mean by c.count because my intepreter always throws an exception that c is not defined if I feed it with this code example and do ?? &gt;&gt;&gt; c.count

From report at bugs.python.org  Fri Feb 25 18:05:19 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Fri, 25 Feb 2011 17:05:19 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298465075.02.0.266967052498.issue11277@psf.upfronthosting.co.za>
Message-ID: <AANLkTimiG2bTumkvNbcWpcRJeVQHyS_Uc8pYBKFGMmXT@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

Could you try with this:

?def setUp(self):
? ? ? ? ? with open(support.TESTFN, "wb+") as f:
? ? ? ? ? ? ? f.seek(_4G)
? ? ? ? ? ? ? f.write(b"asdf")
? ? ? ? ? ? ? f.flush()
+? ? ? ? ? ? os.fsync(f.fileno())
? ? ? ? ? ? ? self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)

HFS+ doesn't seem to support sparse files, so the file is actually
zero-filled asynchronously.
Maybe the mapping gets done before the blocks have been allocated,
which triggers a segfault when the first page is accessed.
I'm not sure it'll make any difference, but I'm curious...

Also, I'd be curious to see the result of

"""
import os

name = '/tmp/foo'
f = open(name, 'wb')
f.seek(1 << 32)
f.write(b'asdf')
f.flush()
print(os.fstat(f.fileno()))
f.close()
print(os.stat(name))
"""

Thanks !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:06:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 17:06:21 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298653581.7.0.559370481093.issue11318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Now it's clear that David is right -- what "c" refers to is defined in this very sentence.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:24:00 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 17:24:00 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298653581.7.0.559370481093.issue11318@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=F1bcYaDADpJhmZLp8b2HB8mW2ztmDrM9ynsYi@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I don't understand it. My bad. Please explain to me exactly what "c" refers
to.

----------
Added file: http://bugs.python.org/file20891/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________
-------------- next part --------------
I don&#39;t understand it. My bad. Please explain to me exactly what &quot;c&quot; refers to.

From report at bugs.python.org  Fri Feb 25 18:25:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 17:25:57 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298654757.99.0.698293539874.issue11318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please consult the python tutor's list, the bug tracker is not the place to get introductory help with Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:34:09 2011
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 25 Feb 2011 17:34:09 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
	Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1298655249.06.0.197525048743.issue11320@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

This issue is potentially breaking virtualenv5,
http://code.google.com/p/virtualenv5/issues/detail?id=6

----------
nosy: +srid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Fri Feb 25 18:47:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 17:47:23 +0000
Subject: [issue11320] Usage of API method Py_SetPath causes errors in
	Py_Initialize() (Posix ony))
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1298656043.01.0.31961985502.issue11320@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you explain why this is a problem in Python?
Can't lib/python3.2/config-3.2m/Makefile simply be provided by virtualenv (by copying it, I guess)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11320>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:14:25 2011
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 25 Feb 2011 18:14:25 +0000
Subject: [issue5421] Irritating error message by socket's sendto method
In-Reply-To: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>
Message-ID: <1298657665.17.0.0717460449827.issue5421@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy: +anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5421>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:28:47 2011
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Feb 2011 18:28:47 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298658527.77.0.988091518584.issue11314@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - while I still need to update it now that 3.2 final has been released, the http://code.google.com/p/python-subprocess32/ project has a backport of the _posixsubprocess stuff from python 3.2 for use on Python 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:36:26 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 25 Feb 2011 18:36:26 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298658986.37.0.753760946681.issue11269@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Just some comments for the historical record:
During the discussion of issue 4953 research and testing revealed that browsers send back their cgi data using the same charset as the page that they are responding to.  So the only way that quoting would be necessary on field names would be if they were quoted funny, as in your example here.  It is somewhat unlikely that people would go to the trouble of coding field names that contain " and ' and % characters, just to mess themselves up (which ones do that, depend on which quote character is used for the name in the HTML and whether the enctype is "multipart/form-data" or URL encoding).

And Firefox 3.6... provides

name=""%22"

and that presently works with Python 3.2 CGI!  But that might mean that for Firefox 4.x, providing the "\"%22", CGI might pass through the "\"?  And really, the dequoting must be incorrectly coded for the Firefox 3.6 to "work".

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:36:43 2011
From: report at bugs.python.org (Palm Kevin)
Date: Fri, 25 Feb 2011 18:36:43 +0000
Subject: [issue10743] 3.2's sysconfig doesn't work with virtualenv
In-Reply-To: <1292882803.72.0.805823865383.issue10743@psf.upfronthosting.co.za>
Message-ID: <1298659003.29.0.926715655768.issue10743@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

@Barry: Yes python runs correctly.
The problem arises when you embed python in a C application when calling the Py_SetPath-method (see the follow up issue #11320)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10743>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:47:00 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Fri, 25 Feb 2011 18:47:00 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298659620.06.0.00772703045477.issue11269@psf.upfronthosting.co.za>


Sergey Schetinin <sergey at maluke.com> added the comment:

It does work (Python 2.7.1 here):

>>> import cgi
>>> cgi.parse_header('Content-Disposition: form-data; name=""%22"')
('Content-Disposition: form-data', {'name': '"%22'})
>>> cgi.parse_header('Content-Disposition: form-data; name="\\"%22"')
('Content-Disposition: form-data', {'name': '"%22'})

However as the unescaping is done sequential .replace, one can construct a header to make it unescape incorrectly:

>>> cgi.parse_header('Content-Disposition: form-data; name="\\\\"%22"')
('Content-Disposition: form-data', {'name': '"%22'})

Which should be:
('Content-Disposition: form-data', {'name': '\\"%22'})

That probably doesn't matter anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Fri Feb 25 19:58:42 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Fri, 25 Feb 2011 18:58:42 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298660322.03.0.625066514219.issue11269@psf.upfronthosting.co.za>


Sergey Schetinin <sergey at maluke.com> added the comment:

I wanted to add that the fact that browsers encode the field names in the page encoding does not change that they should escape the header according to RFC 2047.

The percent-encoding used in the field name has nothing to do with multipart/form-data or headers encoding or even html attribute value escaping. There's no reason for Chrome to percent-escape the quotation mark in the field name and my use of the percent sign in the field name is only to show that Chrome does not escape the percent sign itself and that there's no way to recover the data from the header sent by Chrome.

I imagine there could be a non-ASCII field name that, when encoded in some encoding, will produce something SQL-injection-like: '"; other="xx"'. That string would make the header parse into something completely different. With IE8 and FF 3.6 it looks like it would be very simple. The same applies to uploaded files names too, so it's not just a  matter of choosing sane field names.

That's all a browsers' problem though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:19:08 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 19:19:08 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298661548.73.0.264376383271.issue10882@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thanks Georg.

It seems we have a failure on Leopard:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/1411/steps/test/logs/stdio

Also, I think I can add support for AIX if someone gives me SSH access over an AIX box.
I'm maintaining a separate project to port sendfile() on python 2:
http://code.google.com/p/py-sendfile/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:27:31 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 19:27:31 +0000
Subject: [issue11232] asyncore - don't throw a traceback when a client
	disconnects in echo server example
In-Reply-To: <1297966962.24.0.99288850645.issue11232@psf.upfronthosting.co.za>
Message-ID: <1298662051.71.0.0721924950523.issue11232@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Sorry: fixed in r88581.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11232>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:34:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Feb 2011 19:34:02 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298662442.84.0.774661965718.issue11303@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed issue11303.diff and doc change in revision 88602.

I think the remaining ideas are best addressed in issue11322.

> Given that we are starting to have a whole set of such aliases
> in the C code, I wonder whether it would be better to make the
> string comparisons more efficient, e.g.

I don't think we can do much better than a string of strcmp()s.  Even if a more efficient algorithm can be found, it will certainly be less readable.  Moving strcmp()s before normalize_encoding() (and either forgoing optimization for alternative capitalizations or using case insensitive comparison) may be a more promising optimization strategy.  In any case all these micro-optimizations are dwarfed by that of bypassing Python calls and are probably not worth pursuing.

----------
assignee:  -> belopolsky
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
superseder:  -> encoding package's normalize_encoding() function is too slow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:40:00 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 19:40:00 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1298662800.58.0.267851669152.issue11245@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

imaplib has no particular maintainer and I know little about it.
Doc says it implements 'a large subset of the IMAP4rev1 client protocol as defined in RFC 2060." I do not remember any discussion on pydev, over the last several years, about imaplib. I presume just the subset was chosen because of some combination of necessity and feasibility, as judged by the implementors.  Hence the complement, the unimplemented subset, would be 'not done' rather than 'not wanted'. If your proposed new feature, an IDLE command, is part of this complement, then I would assume that a patch would, in principle, be acceptable.

I cannot comment on your particular proposal, but I hope the above helps as far as it goes.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11245>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:44:44 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2011 19:44:44 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298663084.27.0.672441563033.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Georg, what is the issue?  Is there some reason that bytearrays should not be copied or cleared?  Is there some reason to prefer the current:
  
  dup = b[:]   # copy
  del b[:]     # clear

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:45:40 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 19:45:40 +0000
Subject: [issue11284] slow close file descriptors in subprocess, popen2,
	os.popen*
In-Reply-To: <1298367491.02.0.82009440358.issue11284@psf.upfronthosting.co.za>
Message-ID: <1298663140.3.0.601213915903.issue11284@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +loewis
stage:  -> patch review
title: slow close file descriptors in subprocess, popen2, os.pepen* -> slow close file descriptors in subprocess, popen2, os.popen*
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11284>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:47:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Feb 2011 19:47:37 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1298663257.58.0.683906835125.issue11245@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I just wound up doing a bit of research on this for other reasons.  Piers Lauder was the original author of the imaplib module, and he is (as far as I can tell) currently maintaining an imaplib2 module that does support IDLE (but not, I think, python3).  But it does IDLE (and other things) via threads, and in the email I found announcing it he didn't think it was suitable for stdlib inclusion (because of the threading).  Piers hasn't contributed to core in quite a while as far as I can tell, but he was active in a bug report back in 2008 according to google, so I thought I'd add him to nosy and see if he has time for an opinion.

----------
nosy: +eric.smith, pierslauder, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11245>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:47:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 19:47:41 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <1298663261.82.0.8889398139.issue11283@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:52:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 19:52:39 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298663559.24.0.427145776473.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No -- but the question is if copy() and clear() mightn't be added to the (mutable) sequence ABC if we make all builtin such sequences implement them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 20:57:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 19:57:52 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298663872.36.0.741658838148.issue11282@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Georg, what is policy on removed features?
Remove doc or leave and state removed?

"Deprecated in version 3.2 and removed in 3.3."
 or just
"Removed in version 3.3"
(Once removed, does it really matter when deprecated?)

If left, should they be moved to separate section, especially when multiple? It could be a bit annoying for newcomers starting with 3.3 to read and struggle to understand and then read that they just wasted their time. There enough things already to learn and remember.

----------
nosy: +georg.brandl, terry.reedy
stage:  -> needs patch
title: unittest document not keep consist with code -> 3.3 unittest document not kept consist with code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:03:09 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Feb 2011 20:03:09 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298664189.14.0.101399203602.issue11282@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Actually I think these methods are going back in and staying deprecated, so hold off for a bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:03:18 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 20:03:18 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://www.python.org/dev/buildbot/all/builders/sparc%20solaris10%20gcc%203.x/builds/2658/steps/test/logs/stdio

Patch in attachment.

----------
files: sendfile-test.patch
keywords: patch
messages: 129411
nosy: giampaolo.rodola, loewis
priority: normal
severity: normal
status: open
title: os.sendfile() bo failure on solaris
versions: Python 3.3
Added file: http://bugs.python.org/file20892/sendfile-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:03:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 20:03:29 +0000
Subject: [issue11275] Linking to gcc's gomp causes crash later.
In-Reply-To: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>
Message-ID: <1298664209.91.0.249501605176.issue11275@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 is in security-fix only mode (though this might qualify as a security issue). Can you test with a current version (2.7.1, 3.2.0)?
That said, most problems with extensions crashing are with the extension, though hard to determine sometimes.

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11275>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:04:03 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 25 Feb 2011 20:04:03 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298664243.22.0.717605221527.issue11282@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee: docs at python -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:08:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Feb 2011 20:08:00 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298664480.51.0.77124524874.issue11282@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Removed things are also removed from the doc.  I just committed as much as was necessary to stop buildbot breakage, and notified Michael to take care of the rest (which he did, by explaining I removed the wrong thing :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:08:09 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 20:08:09 +0000
Subject: [issue11214] test_asyncore fails on AIX
In-Reply-To: <1297704969.57.0.151116878107.issue11214@psf.upfronthosting.co.za>
Message-ID: <1298664489.17.0.323306445854.issue11214@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed in r88604, r88605, r88606

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11214>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:09:40 2011
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 25 Feb 2011 20:09:40 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298664580.0.0.773612053993.issue11269@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Sergey says:
I wanted to add that the fact that browsers encode the field names in the page encoding does not change that they should escape the header according to RFC 2047.

I respond:
True, but RFC 2047 is _so_ weird, that it seems that browsers have a better solution.  RFC 2047 is needed for 7-bit mail servers, from which it seems to have been inherited by specs for HTTP (but I've never seen it used by a browser, have you?).  It would be nicer if HTTP had a header that allowed definition of the charset used for subsequent headers.  Right now, the code processing form data has to assume a particular encoding for headers & data, and somehow make sure that all the <form>s that use the same code have the same encoding.

Sergey says:
I imagine there could be a non-ASCII field name that, when encoded in some encoding, will produce something SQL-injection-like: '"; other="xx"'. That string would make the header parse into something completely different. With IE8 and FF 3.6 it looks like it would be very simple. The same applies to uploaded files names too, so it's not just a  matter of choosing sane field names.

That's all a browsers' problem though.

I respond:
Perhaps there is, although it depends on how the parser is written what injection techniques would work, and it also depends on having a followon parameter with dangerous semantics to incorrectly act on.

It isn't just a problem for the browsers, but for every CGI script that parses such parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:13:15 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 20:13:15 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298654757.99.0.698293539874.issue11318@psf.upfronthosting.co.za>
Message-ID: <AANLkTi==TjRSb_qN2HqhWH2a1eGYm1iYwtuPDV5KXJnP@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

How awful! A little pointer to the tutorial where this is explained would be
also quite smashing.

----------
Added file: http://bugs.python.org/file20893/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________
-------------- next part --------------
How awful! A little pointer to the tutorial where this is explained would be also quite smashing.

From report at bugs.python.org  Fri Feb 25 21:24:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 20:24:57 +0000
Subject: [issue11290] ttk.Combobox['values'] String Conversion to Tcl
In-Reply-To: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>
Message-ID: <1298665497.16.0.396153885945.issue11290@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With 3.2, (Winxp) I get combobox with first line,
input as
r'C:\Python31\Lib\tkinter\test\test_ttk',
displayed as
"C:Python31Lib	kinter	est	est_ttk"
Something either deleted \ or converted \t to tab.
Indeed, adding a space to the end of the string or enclosing as you specify inhibits deletion/conversion, so this seems like an error.

With imports fixed
from Tkinter import *
import ttk
the file runs fine in 2.7, so this seems 3.x specific problem.

----------
nosy: +gpolo, terry.reedy
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11290>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:29:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 20:29:37 +0000
Subject: [issue11114] TextIOWrapper.tell extremely slow
In-Reply-To: <1296809557.13.0.428368709297.issue11114@psf.upfronthosting.co.za>
Message-ID: <1298665777.78.0.183355451744.issue11114@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88607 (3.3).

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11114>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:31:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 20:31:30 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298665890.6.0.698312115101.issue11299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Test cases always help when appropriate.
A link to the Pypy code that does this might also help.
Or perhaps ask them to submit a patch to this issue.

----------
nosy: +alexandre.vassalotti, pitrou, terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:34:30 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 20:34:30 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1298666070.99.0.157498260887.issue9795@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.

----------
keywords: +patch
versions: +Python 3.3 -Python 3.2
Added file: http://bugs.python.org/file20894/nntplib-context-manager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:37:08 2011
From: report at bugs.python.org (Tobias Brink)
Date: Fri, 25 Feb 2011 20:37:08 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>


New submission from Tobias Brink <tobias.brink at gmail.com>:

The docs for Python 3.2 say that p = configparser.ConfigParser(interpolation=None) disables interpolation.  Instead it gives this traceback when calling p.read():

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/configparser.py", line 688, in read
    self._read(fp, filename)
  File "/usr/lib/python3.2/configparser.py", line 1081, in _read
    self._join_multiline_values()
  File "/usr/lib/python3.2/configparser.py", line 1091, in _join_multiline_values
    options[name] = self._interpolation.before_read(self,
AttributeError: 'NoneType' object has no attribute 'before_read'

The attached patch should fix it.

----------
components: Library (Lib)
files: configparser_interpolation.patch
keywords: patch
messages: 129421
nosy: tbrink
priority: normal
severity: normal
status: open
title: ConfigParser(interpolation=None) doesn't work
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20895/configparser_interpolation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:38:36 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 25 Feb 2011 20:38:36 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <1298666316.59.0.171282740982.issue11324@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:39:52 2011
From: report at bugs.python.org (Clayton Darwin)
Date: Fri, 25 Feb 2011 20:39:52 +0000
Subject: [issue11290] ttk.Combobox['values'] String Conversion to Tcl
In-Reply-To: <1298394325.28.0.0845611659637.issue11290@psf.upfronthosting.co.za>
Message-ID: <1298666392.76.0.692688250745.issue11290@psf.upfronthosting.co.za>


Clayton Darwin <claytondarwin at gmail.com> added the comment:

This is a simple work around.  

def fix_tcl_error(s):

    if '\\' in s and not ' ' in s:
        s = '{'+s+'}'

    return s

You can get the text from the Combobox with no issues.  The error is in posting it to the Combobox when you have backslashes and no spaces (I think).  I have just been running everything through this def before adding it.  It has worked with no problems so far using Windows paths and grep-type search strings.

CD

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11290>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:42:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 20:42:33 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1298666553.38.0.421994736069.issue1662581@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Another example from #11307
import re
r = re.compile(r'(\w+)*=.*')
r.match("abcdefghijklmnopqrstuvwxyz")

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:42:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Feb 2011 20:42:49 +0000
Subject: [issue11307] re engine exhaustively explores more than necessary
In-Reply-To: <1298552267.25.0.174570607151.issue11307@psf.upfronthosting.co.za>
Message-ID: <1298666569.72.0.0818438265012.issue11307@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

13 secs on my 7 year old windows machine.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> the re module can perform poorly: O(2**n) versus O(n**2)
versions: +Python 2.7, Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11307>
_______________________________________

From report at bugs.python.org  Fri Feb 25 21:50:15 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 20:50:15 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <AANLkTi==TjRSb_qN2HqhWH2a1eGYm1iYwtuPDV5KXJnP@mail.gmail.com>
Message-ID: <AANLkTi=4AsAjxxN_DbGTCt754jZLdLV_RRk0ZCRmJoy9@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

"c.count also refers to C.count"  Where in the code is "c.count"? Please
explain this for the sake of really closing this issue.

----------
Added file: http://bugs.python.org/file20896/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________
-------------- next part --------------
&quot;<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(32, 32, 32); font-family: &#39;Droid Sans&#39;, arial, sans-serif; font-size: 13px; ">c.count also refers to C.count&quot; ??Where in the code is &quot;c.count&quot;? Please explain this for the sake of really closing this issue.</span>

From report at bugs.python.org  Fri Feb 25 21:58:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 20:58:43 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1298667523.71.0.626254497385.issue10784@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r88608 including Py_RETURN_NONE and Py_BEGIN/END_ALLOW_THREADS changes.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:00:27 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 21:00:27 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1298667627.76.0.14001791429.issue10784@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Misc/NEWS updated in r88609.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:06:56 2011
From: report at bugs.python.org (Sergey Schetinin)
Date: Fri, 25 Feb 2011 21:06:56 +0000
Subject: [issue11269] cgi.FieldStorage forgets to unquote field names when
	parsing multipart/form-data
In-Reply-To: <1298283503.56.0.721990279389.issue11269@psf.upfronthosting.co.za>
Message-ID: <1298668016.05.0.721220304577.issue11269@psf.upfronthosting.co.za>


Sergey Schetinin <sergey at maluke.com> added the comment:

I don't think that's a security issue, just something that would break with certain filenames. And I said that it's a browsers' problem in the sense that it can only be fixed / caught on their side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11269>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:08:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 21:08:40 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298668120.88.0.142307118365.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch has tests and is also able to constant-fold tuples larger than 256 elements.

----------
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:09:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 21:09:17 +0000
Subject: [issue11244] Negative tuple elements produce inefficient code.
In-Reply-To: <1298050865.48.0.559427704302.issue11244@psf.upfronthosting.co.za>
Message-ID: <1298668157.83.0.261670927448.issue11244@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Forgot to attach new patch, sorry.

----------
Added file: http://bugs.python.org/file20897/constfold2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11244>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:20:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:20:17 +0000
Subject: [issue11308] extraneous link getit in the main website sidebar
In-Reply-To: <1298558564.87.0.309481947326.issue11308@psf.upfronthosting.co.za>
Message-ID: <1298668817.65.0.331951442282.issue11308@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, bug reports about the website should be directed to webmaster@ or pydotorg-www at .  This tracker is used for bugs in the CPython source distribution only, not anything related to Python.  PEP bugs are sometimes appropriate here too, depending on the triager.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11308>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:30:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:30:29 +0000
Subject: [issue11279] test_posix and lack of "id -G" support - less noise
	required?
In-Reply-To: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>
Message-ID: <1298669429.31.0.00843238511403.issue11279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The correct spelling of that is os.devnull.  platform.DEV_NULL exists only for backwards compatibility (not sure platform.py still has standalone releases).  It is not documented and only used internally.  For a POSIX-only test like this one, hard-coding /dev/null is the simplest thing that works.

Thanks for the patch; our Mac experts will get to it.  Please generate unified diffs in the future.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11279>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:31:14 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:31:14 +0000
Subject: [issue11279] test_posix and lack of "id -G" support - less noise
	required?
In-Reply-To: <1298336144.58.0.789244414117.issue11279@psf.upfronthosting.co.za>
Message-ID: <1298669474.7.0.0235552958125.issue11279@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Oops, this is for Solaris, not Mac.  I?m always confused about those funny OSes.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11279>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:36:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 21:36:29 +0000
Subject: [issue10956] file.write and file.read don't handle EINTR
In-Reply-To: <1295532751.32.0.53142512873.issue10956@psf.upfronthosting.co.za>
Message-ID: <1298669789.74.0.549671810932.issue10956@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88610 (3.3), r88611 (3.2) and r88612 (2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10956>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:37:09 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:37:09 +0000
Subject: [issue11287] Add context manager support to dbm modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298669829.93.0.701944969223.issue11287@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+        try:
+            with f: pass
+        except Exception as e:
+            self.assertIsInstance(e, ValueError)
+        else:
+            self.assertFailed()

I find this form easier to read:

    with self.assertRaises(ValueError):
        with f:
            pass

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11287>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:47:22 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 21:47:22 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298670442.94.0.750722847007.issue11323@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r88616.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:53:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:53:03 +0000
Subject: [issue11293] Distutils - read the file when using it in
	long_description
In-Reply-To: <1298408262.52.0.851871312997.issue11293@psf.upfronthosting.co.za>
Message-ID: <1298670783.21.0.999618586411.issue11293@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I had a better patch pending for that, thanks for the reminder.  Fixed in r88613 (py3k), r88614 (3.2), r88615 (3.1) and r88617 (2.7).  I took the time machine and fixed it six months ago in distutils2 in [c03dd6283e94].

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11293>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:54:37 2011
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 25 Feb 2011 21:54:37 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298670877.82.0.285105242049.issue11299@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Tests attached.

----------
Added file: http://bugs.python.org/file20898/test_live_generator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:56:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 21:56:06 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298670966.55.0.555992663053.issue11297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Minor doc issue: s/__builtin__/builtins/

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Fri Feb 25 22:56:56 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2011 21:56:56 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298671016.82.0.705467197926.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The ABCs are subset of the methods for the concrete APIs.  We've avoided the likes of copy() because it requires knowledge of the constructor's signature -- for example, MutableMapping does not cover copy().

It is okay for Eli to add MutableSequence.clear() because it can be implemented in terms of pop(), much like we do for MutableMapping.clear().

Eli, feel free to create a patch to add clear() and copy() to bytearray and to add clear() to MutableSequence.  Assign the patch to me for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:00:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:00:01 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298671201.33.0.127297511733.issue11298@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m not sure what?s best between the proposed addition and a link to the definition of module/importable.  I think that programmers should know that not all file names are valid module names, so I wouldn?t want us to copy the definition all over the docs.  Thoughts?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:02:09 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 25 Feb 2011 22:02:09 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298671329.7.0.136069006284.issue11299@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Although, I would really like to see support of pickling generators. It is not really possible in CPython. This is recurrent request. I even wrote a small article about it.

http://peadrop.com/blog/2009/12/29/why-you-cannot-pickle-generators/

Looking how PyPy did it, I see portability problems with the fact it dumps the byte-code of the generator to disk. Python's documentation clearly states that the byte-code is an implementation details and can (and does) change between releases. Hence, this method is not really suitable for pickle which needs to remain compatible across releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:08:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 22:08:29 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1242760441.53.0.863717257975.issue6064@psf.upfronthosting.co.za>
Message-ID: <1298671709.53.0.43851491177.issue6064@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I corrected the patches (they were breaking the property of inheriting daemon by default) and committed them in r88618. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:15:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Feb 2011 22:15:31 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298672131.58.0.548882693596.issue11298@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What about something like
"""
In order to be compatible with test discovery, all the test modules must be importable from the top level directory of the project (in other words, they must be part of the project :ref:`package <tut-packages>`, and their name must be valid :ref:`identifiers <identifiers>`).
"""
?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:21:53 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 22:21:53 +0000
Subject: [issue11177] Set asyncore create_socket default argument
In-Reply-To: <1297362824.83.0.287442069461.issue11177@psf.upfronthosting.co.za>
Message-ID: <1298672513.74.0.212028020774.issue11177@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed in r88619.

----------
nosy: +josiah.carlson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11177>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:28:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 22:28:52 +0000
Subject: [issue11291] poplib suppresses exception on QUIT
In-Reply-To: <1298404361.7.0.353311049952.issue11291@psf.upfronthosting.co.za>
Message-ID: <1298672932.7.0.491549804978.issue11291@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Fixed in r88620.

----------
components: +Library (Lib)
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11291>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:31:34 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 25 Feb 2011 22:31:34 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298673094.92.0.87683838816.issue11281@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

You are right, I haven't thought about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:43:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:43:51 +0000
Subject: [issue11315] Fix/add unicode support in Cookie module?
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1298673831.83.0.934833587189.issue11315@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  This is not as easy as it sounds: The doc ambiguously uses ?string?; the code clearly wants only byte strings (str); in the 3.x version, only character strings (unicode) are accepted; ?raw? would suggest to me than only bytes make sense.

I would tend to edit the documentation but no the behavior, given that 2.7 is stable and this behavior has been present and documented for a long time.  Senthil, what?s your opinion?

----------
nosy: +eric.araujo
title: Cookie.py breaks when passed unicode, fix included -> Fix/add unicode support in Cookie module?
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:43:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:43:57 +0000
Subject: [issue11315] Fix/add unicode support in Cookie module?
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1298673837.11.0.979700976296.issue11315@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:46:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 22:46:09 +0000
Subject: [issue1554] socketmodule cleanups: allow the use of keywords in
	socket functions
In-Reply-To: <1196784173.07.0.425557098914.issue1554@psf.upfronthosting.co.za>
Message-ID: <1298673969.15.0.210987081093.issue1554@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch needs updating for latest 3.x.

----------
assignee: loewis -> 
nosy: +giampaolo.rodola, pitrou
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1554>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:50:29 2011
From: report at bugs.python.org (Aaron Sherman)
Date: Fri, 25 Feb 2011 22:50:29 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298589764.8.0.472079473316.issue11314@psf.upfronthosting.co.za>
Message-ID: <1298674229.69.0.698157336902.issue11314@psf.upfronthosting.co.za>


Aaron Sherman <ajs at ajs.com> added the comment:

"That's why I asked for absolute numbers for the overhead difference."

Did you not follow the link in my first post? I got pretty detailed, there.

"os.popen just calls the popen(3) library call, which just performs a fork/execve and some dup/close in between. subprocess.Popen is implemented in Python, so it doesn't come as a surprise that it's slower in your example."

Well, of course. I don't think I was ever trying to claim that os.popen vs. subprocess without a shell was going to compare favorably. I'm not advocating os.popen, here, I'm just trying to figure out where this massive overhead is coming from. I think the answer is just, "pure Python is fundamentally slower, and that's not a surprise."

Now, if the 3.x subprocess work that was described here, gets back-ported into 2.x and is included with future releases, that will definitely serve to improve the situation, and might well render much of this moot (testing will tell).

However, I do think that doing the performance testing before deprecating the previous interface would have been a good idea...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:15 2011
From: report at bugs.python.org (Miki Tebeka)
Date: Fri, 25 Feb 2011 22:51:15 +0000
Subject: [issue6064] Add "daemon" argument to threading.Thread constructor
In-Reply-To: <1298671709.53.0.43851491177.issue6064@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0+Nj0Wm1otFWNA9=_PTZjS8neV0pwCdyg+y4j@mail.gmail.com>


Miki Tebeka <miki.tebeka at gmail.com> added the comment:

Thank you!

On Fri, Feb 25, 2011 at 2:08 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> I corrected the patches (they were breaking the property of inheriting daemon by default) and committed them in r88618. Thank you!
>
> ----------
> resolution: ?-> fixed
> stage: patch review -> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6064>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6064>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:51:30 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674290.15.0.0604242600776.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20888/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:51:32 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674292.87.0.716555335987.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20890/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:51:38 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674298.21.0.231878070412.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20891/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:40 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:51:40 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674300.51.0.760092455409.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20893/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:51:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:51:42 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674302.82.0.423944532587.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20896/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:52:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2011 22:52:23 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298674343.43.0.620018615761.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> r88586: Normalized the encoding names for Latin-1 and UTF-8 to
> 'latin-1' and 'utf-8' in the stdlib.

Why did you do that? We are trying to find a solution together, and you change directly the code without any review. Your commit doesn't solve this issue.

Your commit is now useless, can you please revert it?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:53:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:53:18 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298674398.58.0.375533475235.issue11318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If the tutorial is not clear enough, try for example <http://diveintopython.org/object_oriented_framework/class_attributes.html>.  Please ask on a suitable venue if you don?t understand instead of this tracker.

(Please don?t send HTML email to this tracker, it creates false attachments.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:55:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:55:45 +0000
Subject: [issue11253] autodocument first appearance of ctypes.wintypes
	constants
In-Reply-To: <1298182426.14.0.687578094658.issue11253@psf.upfronthosting.co.za>
Message-ID: <1298674545.98.0.903827827216.issue11253@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11253>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:58:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Feb 2011 22:58:13 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower
	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298674693.07.0.933678151252.issue11303@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

What's wrong with Marc's commit?  He's using the standard names.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:58:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 22:58:39 +0000
Subject: [issue11255] 2to3 throws AttributeError during distutils installation
	with -O
In-Reply-To: <1298197687.53.0.332108526066.issue11255@psf.upfronthosting.co.za>
Message-ID: <1298674719.18.0.796991386176.issue11255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This does not look specific to distutils.  Can you reproduce with bare 2to3?  If so, can you attach the test script of unit test diff? :)

(P.S. ?crash? is used for segfaults, not unhandled exceptions.)

----------
nosy: +benjamin.peterson, eric.araujo
stage:  -> test needed
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11255>
_______________________________________

From report at bugs.python.org  Fri Feb 25 23:59:51 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 22:59:51 +0000
Subject: [issue11303] b'x'.decode('latin1') is much
	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298674343.43.0.620018615761.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D683464.2010500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> r88586: Normalized the encoding names for Latin-1 and UTF-8 to
>> 'latin-1' and 'utf-8' in the stdlib.
> 
> Why did you do that? We are trying to find a solution together, and you change directly the code without any review. Your commit doesn't solve this issue.

As discussed on python-dev, the stdlib should use Python's
default names for encodings and that's what I changed.

> Your commit is now useless, can you please revert it?

This ticket was mainly discussing use cases in
3rd party applications, not code that we have control over
in the stdlib - we can easily fix that and that's what I did
with the above checkin.

----------
title: b'x'.decode('latin1') is much slower than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:00:40 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 23:00:40 +0000
Subject: [issue11303] b'x'.decode('latin1') is much
	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298674840.38.0.270410529985.issue11303@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Closing the ticket again.

The problem in question is solved.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:02:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 23:02:33 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298674953.62.0.811202531969.issue11257@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, isn?t WeakRefDictionary faster than a dict here?

----------
nosy: +eric.araujo
stage:  -> patch review
type: behavior -> performance
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:02:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 23:02:54 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298674974.01.0.248363270772.issue11257@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

WeakValue*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:03:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Feb 2011 23:03:06 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is too
	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298674986.91.0.66075330086.issue11322@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

We should first implement the same algorithm of the 3 normalization functions and add tests for them (at least for the function in normalization):

 - normalize_encoding() in encodings: it doesn't convert to lowercase and keep non-ASCII letters
 - normalize_encoding() in unicodeobject.c
 - normalizestring() in codecs.c

normalize_encoding() in encodings is more laxist than the two other functions: it normalizes "  utf   8  " to 'utf_8'. But it doesn't convert to lowercase and keeps non-ASCII letters: "UTF-8?" is normalized "UTF_8?".

I don't know if the normalization functions have to be more or less strict, but I think that they should all give the same result.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:03:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:03:29 +0000
Subject: [issue11303] b'x'.decode('latin1') is much
	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298675009.25.0.420873900032.issue11303@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What's wrong with Marc's commit?  He's using the standard names.

That's a pretty useless commit and it will make applying patches and backports more tedious, for no obvious benefit.
Of course that concern will be removed if Marc-Andr? also backports it to 3.2 and 2.7.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:06:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:06:44 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298675204.58.0.588751263259.issue11257@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

?ric, the weak dicts are implemented in pure Python while built-in dicts are in C. That can make quite a difference.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:06:54 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 23:06:54 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
	too	slow
In-Reply-To: <1298674986.91.0.66075330086.issue11322@psf.upfronthosting.co.za>
Message-ID: <4D683608.1070702@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> We should first implement the same algorithm of the 3 normalization functions and add tests for them (at least for the function in normalization):
> 
>  - normalize_encoding() in encodings: it doesn't convert to lowercase and keep non-ASCII letters
>  - normalize_encoding() in unicodeobject.c
>  - normalizestring() in codecs.c
> 
> normalize_encoding() in encodings is more laxist than the two other functions: it normalizes "  utf   8  " to 'utf_8'. But it doesn't convert to lowercase and keeps non-ASCII letters: "UTF-8?" is normalized "UTF_8?".
> 
> I don't know if the normalization functions have to be more or less strict, but I think that they should all give the same result.

Please see this message for an explanation of why we have those
three functions, why they are different and what their application
space is:

http://bugs.python.org/issue5902#msg129257

This ticket is just about the encoding package's codec search
function, not the other two, and I don't want to change
semantics, just its performance.

----------
title: encoding package's normalize_encoding() function is too slow -> encoding package's normalize_encoding() function is too	slow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:11:03 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 23:11:03 +0000
Subject: [issue11303] b'x'.decode('latin1') is
	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298675009.25.0.420873900032.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D683705.2020405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I guess you could regard the wrong encoding name use as bug - it
slows down several stdlib modules for no apparent reason.

If you agree, Raymond, I'll backport the patch.

----------
title: b'x'.decode('latin1') is much slower	than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much	slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:11:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Feb 2011 23:11:53 +0000
Subject: [issue11303] b'x'.decode('latin1') is
	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298675513.2.0.50229240094.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1 on the backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:13:29 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Feb 2011 23:13:29 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <4D683705.2020405@egenix.com>
Message-ID: <4D683797.2090007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> I guess you could regard the wrong encoding name use as bug - it
> slows down several stdlib modules for no apparent reason.
> 
> If you agree, Raymond, I'll backport the patch.

We might actually backport Alexander's patch as well - for much
the same reason.

----------
title: b'x'.decode('latin1') is much	slower	than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is	much	slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:13:51 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 25 Feb 2011 23:13:51 +0000
Subject: [issue11260] smtpd-as-a-script feature should be documented and
	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1298675631.81.0.638688523505.issue11260@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Meta-bugs are useful for bookkeeping purposes like the implementation of a PEP or a broad feature like ?bytes/text model in email? <wink at David>.  Just open one report for each module you want to add doc for.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11260>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:15:22 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:15:22 +0000
Subject: [issue7322] Socket timeout can cause file-like readline() method to
	lose data
In-Reply-To: <1258218993.08.0.764402701678.issue7322@psf.upfronthosting.co.za>
Message-ID: <1298675722.09.0.590565232171.issue7322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88622 (3.3) and r88623 (3.2). The 2.7 implementation is too different for the patch to apply, so if you want to fix it too, feel free to upload a patch. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:26:45 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:26:45 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1298676405.76.0.466812490401.issue4761@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have committed the patch in r88624. Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:39:29 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:39:29 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ make
gcc -pthread  -g -O0 -Wall -Wstrict-prototypes    -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ?posix_sendfile?:
./Modules/posixmodule.c:6025: attention : implicit declaration of function ?sendfile?

----------
assignee: giampaolo.rodola
components: Extension Modules
messages: 129470
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: compilation warning with sendfile
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:41:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Feb 2011 23:41:47 +0000
Subject: [issue10755] Add posix.fdlistdir
In-Reply-To: <1293002775.56.0.279049090331.issue10755@psf.upfronthosting.co.za>
Message-ID: <1298677307.61.0.907411914322.issue10755@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88625. Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10755>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:42:58 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 25 Feb 2011 23:42:58 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298677378.58.0.246555506386.issue11318@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Eric, the thing I don't understand is why is there that "c.count" thing. How is it possible for "c.count" to be the same reference as "C.count"? Where is "c" defined?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 00:55:51 2011
From: report at bugs.python.org (wesley chun)
Date: Fri, 25 Feb 2011 23:55:51 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298663261.85.0.408308250566.issue11283@psf.upfronthosting.co.za>
Message-ID: <AANLkTinpuMPQG6_Qe3NCJ18vUZP8Jx_901_2JoX8pBYk@mail.gmail.com>


wesley chun <wescpy at gmail.com> added the comment:

i wanted to add one additional comment that it would be nice to have a
regex that works with search() (in addition to match()) because such
an email address may appear in the middle of a line, say a From: or
To: email header.

the fix of using a '$' prevents this from happening, so i'm not 100%
satisfied with the patch although it does fix the regex to get it
working with match().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:11:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:11:10 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1298679070.13.0.199705269956.issue10784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

======================================================================
ERROR: test_set_get_priority (test.test_os.ProgramPriorityTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_os.py", line 1283, in test_set_get_priority
    os.setpriority(os.PRIO_PROCESS, os.getpid(), base)
OSError: [Errno 13] Permission denied

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_os.py", line 1285, in test_set_get_priority
    if err.errno != errno.EACCESS:
AttributeError: 'module' object has no attribute 'EACCESS'

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:14:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:14:19 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298679259.9.0.569750978305.issue11325@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps (probably?) related to the crash in http://www.python.org/dev/buildbot/all/builders/PPC64%20Ubuntu%203.x/builds/655

./Modules/posixmodule.c:5909: warning: implicit declaration of function ?sendfile?

----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:20:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 00:20:00 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298679600.06.0.482460291039.issue11257@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Oh, I guess I didn?t understand at all what the numbers meant.  I shouldn?t have compared the values and assumed that less was better, my bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:31:13 2011
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 26 Feb 2011 00:31:13 +0000
Subject: [issue11326] Asynchronous ssl handshakes fails for asynchronously
	connected sockets.
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>


New submission from Florian Mayer <flormayer at aim.com>:

The asynchronous do_handshakes fails for sockets that were connected asynchronously. Tested on 2.6, 3.1 and 3.2.

Traceback (most recent call last):
  File "handshake.py", line 17, in <module>
    s.do_handshake()
  File "/usr/lib/python2.6/ssl.py", line 279, in do_handshake
    self._sslobj.do_handshake()
AttributeError: 'NoneType' object has no attribute 'do_handshake'

----------
components: Library (Lib)
files: handshake.py
messages: 129477
nosy: segfaulthunter
priority: normal
severity: normal
status: open
title: Asynchronous ssl handshakes fails for asynchronously connected sockets.
type: behavior
versions: Python 2.6, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20899/handshake.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:39:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:39:54 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298680794.36.0.15439781076.issue11326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, one issue is that connect_ex() isn't implemented for SSL sockets, so it defers to the normal implementation instead, which is wrong.

But your still is wrong too. connect_ex() returns an error, meaning the socket isn't connected and you must retry. Here is a working snippet using connect():


def connect():
    try:
        s.connect(('people.csail.mit.edu', 443))
    except socket.error as e:
        if e.errno != errno.EINPROGRESS:
            raise
        return False
    else:
        return True

while not connect():
    select.select([s], [s], [])

while True:
    try:
        select.select([s], [s], [])
        s.do_handshake()
        break
    except ssl.SSLError as err:
        if err.args[0] == ssl.SSL_ERROR_WANT_READ:
            select.select([s], [], [])
        elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
            select.select([], [s], [])
        else:
            raise

----------
nosy: +pitrou
stage:  -> needs patch
title: Asynchronous ssl handshakes fails for asynchronously connected sockets. -> connect_ex() implementation missing for SSL sockets
versions: +Python 2.7, Python 3.3 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:40:59 2011
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 26 Feb 2011 00:40:59 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298680859.32.0.143409759816.issue11326@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

A workaround would be exposing _ssl.wrapssl in ssl so that it can be called once the socket is connected and no non-public API had to be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:43:29 2011
From: report at bugs.python.org (Florian Mayer)
Date: Sat, 26 Feb 2011 00:43:29 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298681009.28.0.226637012956.issue11326@psf.upfronthosting.co.za>


Florian Mayer <flormayer at aim.com> added the comment:

The select call after the connect_ex waits until the connection is done, for the first write event is fired then, so the socket is connected afterwards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:56:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:56:56 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298681816.23.0.62495161994.issue11326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The select call after the connect_ex waits until the connection is
> done, for the first write event is fired then, so the socket is
> connected afterwards.

You are right. Here is a patch for py3k implementing connect_ex() and solving the issue with the missing "_sslobj" attribute. It makes your script run fine.

(ideally I should add some tests to the patch, at least for connect_ex)

----------
keywords: +patch
nosy: +giampaolo.rodola
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20900/ssl_connect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:58:20 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:58:20 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298681900.13.0.0531448181721.issue11326@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file20900/ssl_connect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 01:58:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 00:58:59 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298681939.83.0.609662291394.issue11326@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file20901/ssl_connect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:08:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Feb 2011 01:08:12 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298682492.08.0.759553398553.issue11297@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Antoine.  Thanks.  I put in a paragraph re-emphasizing that ChainMap is a view and that changes in the underlying mappings get reflected in the ChainMap.  Also, the first sentence says that ChainMap groups multiple dicts or other mappings.  So, any mapping-like object will work.

?ric, I changed built-in to builtin.  It is used as an adjetive, not as a module reference (that's the usual practice when referring the builtin functions).

See r88628.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:13:04 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Feb 2011 01:13:04 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298682784.22.0.640219863058.issue11297@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I was thinking of adding a recipes section to show how to extend or override the class:

class DjangoContext(ChainMap):
   def push(self):
       self.maps.insert(0, {})
   def pop(self):
       self.maps.pop(0)

class NestedScope(ChainMap):
   'Mutating methods that write to first matching dict'

    def __setitem__(self, key, value):
        '''Find the first matching *key* in chain and set its value.
        If not found, sets in maps[0].

        '''
        for m in self.maps:
            if key in m:
                break
        else:
            m = self.maps[0]
        try:
            cs = m.chain_set
        except AttributeError:
            m[key] = value
        else:
            cs(key, value)

    def __delitem__(self, key):
        '''Find and delete the first matching *key* in the chain.
        Raise KeyError if not found.

        '''
        for m in self.maps:
            if key in m:
                break
        try:
            cd = m.chain_del
        except AttributeError:
            del m[key]
        else:
            cd(key)

    def popitem(self):
        for m in self.maps:
            if m:
                break
        return m.popitem()

    def clear(self):
        for m in self.maps:
            m.clear()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:20:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 01:20:33 +0000
Subject: [issue11297] Make ChainMap() public in the collections module.
In-Reply-To: <1298456556.38.0.797949345188.issue11297@psf.upfronthosting.co.za>
Message-ID: <1298683233.77.0.455885608616.issue11297@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Raymond: Sorry I was imprecise.  I was referring specifically to ?import __builtin__? in collections.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11297>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:26:13 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Feb 2011 01:26:13 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298683573.26.0.881371064369.issue11303@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> If you agree, Raymond, I'll backport the patch.

Yes.  That will address Antoine's legitimate concern about making other backports harder, and it will get all the Python's to use the canonical spelling.

For other spellings like "utf8" or "latin1", I wonder if it would be useful to emit a warning/suggestion to use the standard spelling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:27:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 01:27:34 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298683654.05.0.500719275473.issue11303@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Such warnings about performance seem to me to be the domain of code analysis or lint tools, not the interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:28:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 01:28:56 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298683736.1.0.728046989161.issue11318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What this part means is: ?If you create an instance of C named c, and get c.count, it will get the attribute count defined on C.?  IOW: You can get a class variable from any instance.

In the example, the code in __init__ cannot assign to self.count, because it wants to increment the attribute on the class, not on the instance.  This is very well explained in Dive Into Python.

Please experiment in a shell and ask on appropriate venues after this message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:29:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 01:29:10 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298683750.59.0.313085841642.issue11303@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For other spellings like "utf8" or "latin1", I wonder if it would be
> useful to emit a warning/suggestion to use the standard spelling.

No, it would be an useless annoyance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:29:39 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 01:29:39 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298683779.52.0.628933106158.issue11318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> 
nosy:  -docs at python, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:30:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 01:30:36 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298683836.22.0.0535273662759.issue11298@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I like that.  Is it true that test discovery requires tests to be in a Python package, as opposed to top-level modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:31:25 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Feb 2011 01:31:25 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298683885.85.0.94182840738.issue11303@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For other spellings like "utf8" or "latin1", I wonder 
> if it would be useful to emit a warning/suggestion to use 
> the standard spelling.

Why do you want to emit a warning? utf8 is now as fast as utf-8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:39:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Feb 2011 01:39:05 +0000
Subject: [issue11303] b'x'.decode('latin1')
	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298684345.88.0.568485988805.issue11303@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> For other spellings like "utf8" or "latin1", I wonder if it would be
> useful to emit a warning/suggestion to use the standard spelling.

It would prefer to see the note added by Alexander in the doc mention *only* the preferred spellings (i.e. 'utf-8' and 'iso-8859-1') rather than all the variants that are actually optimized. One of the reasons that lead me to open #5902 is that I didn't like the inconsistencies in the encoding names (utf-8 vs utf8 vs UTF8 etc). Suggesting only one spelling per encoding will fix the problem.

FWIW, the correct spelling is 'latin1', not 'latin-1', but I still prefer 'iso-8859-1' over the two.

(The note could also use some more ``'markup'`` for the encoding names.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:39:39 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Feb 2011 01:39:39 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298683750.59.0.313085841642.issue11303@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=z4oRgU72wtj-yV_M_0nWx5H7GBuPzAuSLdMw4@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Feb 25, 2011 at 8:29 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> For other spellings like "utf8" or "latin1", I wonder if it would be
>> useful to emit a warning/suggestion to use the standard spelling.
>
> No, it would be an useless annoyance.

If we ever decide to get rid of codec aliases in the core and require
users to translate names found in various internet standards to
canonical Python spellings, we will have to issue deprecation warnings
before that.

As long as we recommend using say XML encoding metadata as is, we
cannot standardize on Python spellings because they differ from XML
standard.  (For example, Python uses "latin-1" and proper XML only
accepts "latin1". Of course, we can ask everyone to use iso-8859-1
instead, but how many users can remember that name?)

----------
title: b'x'.decode('latin1') is	much	slower	than	b'x'.decode('latin-1') -> b'x'.decode('latin1') is much slower than b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:40:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 01:40:28 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298500498.32.0.859922693155.issue11303@psf.upfronthosting.co.za>
Message-ID: <1298684428.78.0.308418010719.issue11303@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If we ever decide to get rid of codec aliases in the core

"If".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 02:50:02 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Feb 2011 01:50:02 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298684345.88.0.568485988805.issue11303@psf.upfronthosting.co.za>
Message-ID: <AANLkTimJVvos=w=Qr4WHyOojnzjBYunxqVLGuKZ1UuyS@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Feb 25, 2011 at 8:39 PM, Ezio Melotti <report at bugs.python.org> wrote:
..
> It would prefer to see the note added by Alexander in the doc mention *only* the preferred spellings
> (i.e. 'utf-8' and 'iso-8859-1') rather than all the variants that are actually optimized. One of the reasons
> that lead me to open #5902 is that I didn't like the inconsistencies in the encoding names (utf-8 vs utf8 vs
> UTF8 etc). Suggesting only one spelling per encoding will fix the problem.

I am fine with trimming the list.  In fact I deliberately did not
mention say UTF-8 variant even though it is also optimized.
Unfortunately, I don't think we have a choice between 'latin-1',
'latin1', and 'iso-8859-1'.  I don't think we should recommend
'latin-1' because this may cause people adding '-' to a very popular
and IANA registered 'latin1' variant and while 'iso-8859-1' is the
most pedantically correct spelling, it is very user unfriendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:31:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Feb 2011 03:31:23 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1298691083.18.0.884885059166.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

After a mail I sent to the Unicode Consortium about the corner case I found, they updated the "Best Practices for Using U+FFFD"[0] and now it says:
"""
 Another example illustrates the application of the concept of maximal subpart for UTF-8 continuation bytes outside the allowable ranges defined in Table 3-7. The UTF-8 sequence <41 E0 9F 80 41> is ill-formed, because <9F> is not an allowed second byte of a UTF-8 sequence commencing with <E0>. In this case, there is an unconvertible offset at <E0> and the maximal subpart at that offset is also <E0>. The subsequence <E0 9F> cannot be a maximal subpart, because it is not an initial subsequence of any well-formed UTF-8 code unit sequence.
"""

The result of decoding that string with Python is:
>>> b'\x41\xE0\x9F\x80\x41'.decode('utf-8', 'replace')
'A??A'
i.e. the bytes <E0 9F> are wrongly considered as a maximal subpart and replaced with a single '?' (the second ? is the \x80).

I'll work on a patch and see how it comes out.

[0]: http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf - page 96

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:44:15 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Sat, 26 Feb 2011 03:44:15 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298691855.36.0.114752283692.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Giampaolo,

Thanks for your kind review, I will send a patch with suggested changes this weekend.

Grazie,
--
Paulo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Sat Feb 26 04:44:55 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Feb 2011 03:44:55 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1298691895.41.0.632906746922.issue10228@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 88631

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:14:23 2011
From: report at bugs.python.org (Ray.Allen)
Date: Sat, 26 Feb 2011 06:14:23 +0000
Subject: [issue11287] Add context manager support to dbm modules
In-Reply-To: <1298383106.44.0.402041562416.issue11287@psf.upfronthosting.co.za>
Message-ID: <1298700863.31.0.651730248769.issue11287@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Update: change unittest code following eric's comments.

----------
Added file: http://bugs.python.org/file20902/issue11287.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11287>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:31:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:31:55 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1298701915.12.0.345770374653.issue10228@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you backport to 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:33:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:33:21 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298702001.04.0.700301026832.issue11325@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r88626, and it *did* fix the buildbot crash!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:34:39 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Feb 2011 06:34:39 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1298679070.13.0.199705269956.issue10784@psf.upfronthosting.co.za>
Message-ID: <20110226063431.GC2737@kevin>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Feb 26, 2011 at 12:11:10AM +0000, Antoine Pitrou wrote:
>     if err.errno != errno.EACCESS:
> AttributeError: 'module' object has no attribute 'EACCESS'

That was one 'S' too many.  Should be errno.EACCES
Looks like Antoine has fixed it in r88627.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:37:38 2011
From: report at bugs.python.org (Anthony Long)
Date: Sat, 26 Feb 2011 06:37:38 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>


New submission from Anthony Long <antlong at gmail.com>:

I ran 

python test_time.py 

and python immediately crashed.

This is the trace from mac's error reporter: 

http://dpaste.de/Jsw7/

----------
components: Tests
messages: 129502
nosy: antlong
priority: normal
severity: normal
status: open
title: Running test_time.py in python27 caused python to unexpectedly quit
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:39:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:39:09 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298702349.38.0.899292644891.issue11325@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r88626, and it *did* fix the buildbot crash!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:40:27 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:40:27 +0000
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
Message-ID: <1298702427.05.0.876358565334.issue10784@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10784>
_______________________________________

From report at bugs.python.org  Sat Feb 26 07:40:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 06:40:54 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298702454.66.0.0777134835955.issue11325@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: http://bugs.python.org/msg129503

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From orsenthil at gmail.com  Sat Feb 26 07:34:31 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 26 Feb 2011 14:34:31 +0800
Subject: [issue10784] os.getpriority() and os.setpriority()
In-Reply-To: <1298679070.13.0.199705269956.issue10784@psf.upfronthosting.co.za>
References: <1293500810.54.0.0610321482452.issue10784@psf.upfronthosting.co.za>
	<1298679070.13.0.199705269956.issue10784@psf.upfronthosting.co.za>
Message-ID: <20110226063431.GC2737@kevin>

On Sat, Feb 26, 2011 at 12:11:10AM +0000, Antoine Pitrou wrote:
>     if err.errno != errno.EACCESS:
> AttributeError: 'module' object has no attribute 'EACCESS'

That was one 'S' too many.  Should be errno.EACCES
Looks like Antoine has fixed it in r88627.

From report at bugs.python.org  Sat Feb 26 08:11:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Feb 2011 07:11:50 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1298701915.12.0.345770374653.issue10228@psf.upfronthosting.co.za>
Message-ID: <20110226071142.GD2737@kevin>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Done in r88634.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Sat Feb 26 08:58:41 2011
From: report at bugs.python.org (Dmitry Negius)
Date: Sat, 26 Feb 2011 07:58:41 +0000
Subject: [issue11328] NESTED WHILE CYCLES ERROR
In-Reply-To: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>
Message-ID: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>


New submission from Dmitry Negius <dmitrygenius6 at gmail.com>:

Nested "while" cycles does not work. This make impossible to write a class of programs with nested while cycles.

----------
components: Interpreter Core
files: bug.py
messages: 129506
nosy: negius
priority: normal
severity: normal
status: open
title: NESTED WHILE CYCLES ERROR
type: compile error
versions: Python 2.6, Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20903/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11328>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:00:44 2011
From: report at bugs.python.org (Alex)
Date: Sat, 26 Feb 2011 08:00:44 +0000
Subject: [issue11328] NESTED WHILE CYCLES ERROR
In-Reply-To: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>
Message-ID: <1298707244.02.0.439885639575.issue11328@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

This is invalid, there's no bug.  j doesn't get magically reinitialized to 0, in fact this code would do the same thing in any language I can think of.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11328>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:03:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 08:03:18 +0000
Subject: [issue11328] NESTED WHILE CYCLES ERROR
In-Reply-To: <1298707121.29.0.0280209437162.issue11328@psf.upfronthosting.co.za>
Message-ID: <1298707398.63.0.19772631224.issue11328@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11328>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:11:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 08:11:07 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298707867.81.0.604079085855.issue10866@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure why you use PyTuple_Size() and PyTuple_GetItem().
You should be able to do a first call to PyArg_ParseTuple() (using the "S" specifier to mandate a bytes object), and call PyErr_Clear() and fallback to the second PyArg_ParseTuple() if the first one fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:13:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 08:13:30 +0000
Subject: [issue11172] Avoid '.' as runpath on AIX
In-Reply-To: <1297346581.12.0.969527890029.issue11172@psf.upfronthosting.co.za>
Message-ID: <1298708010.74.0.813392731162.issue11172@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now backported as part of issue 941346.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> AIX shared library fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11172>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:14:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 08:14:40 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1298708080.4.0.410529695396.issue9795@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure that silencing errors from quit() is the right thing. Is there any reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:34:41 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 26 Feb 2011 08:34:41 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298709281.54.0.650314309267.issue10866@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

Here is a simplified version.

----------
Added file: http://bugs.python.org/file20904/sethostname_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:46:41 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 08:46:41 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298710001.51.0.429954095113.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I think you're right.
I've committed the patch to 3.3 in r88639 after having added a minimal test. Is there a full name I should credit?
Thank you for contributing!

----------
assignee: theller -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sat Feb 26 09:51:01 2011
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sat, 26 Feb 2011 08:51:01 +0000
Subject: [issue11318] Python 3.2 FAQ example code typo?
In-Reply-To: <1298636715.79.0.945833742805.issue11318@psf.upfronthosting.co.za>
Message-ID: <1298710261.67.0.445684900835.issue11318@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Understood. Now I get it. If you create an instance "c" of the class "C" (so c = C() ) and try to get the variable "count" from that class, then "c.count" is the same reference as "C.count".

Please make that clearer in the FAQ by saying "If you create an instance "c" of the class "C", then "c.count" is the same reference as "C.count".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11318>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:40:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 09:40:35 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298713235.98.0.995755035423.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening and reverted the commit in r88640. The patch changes behaviour by turning the previous unrooted filename ('libc.so.6') into a full path ('/lib64/libc.so.6'). This breaks builds where multiple versions of a library are available and only one is loadable, e.g. 32-bit builds on 64-bit machines:

======================================================================
ERROR: test_load (ctypes.test.test_loading.LoaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/hg-3.x.loewis-parallel/build/Lib/ctypes/test/test_loading.py", line 26, in test_load
    CDLL(libc_name)
  File "/home2/buildbot2/slave/hg-3.x.loewis-parallel/build/Lib/ctypes/__init__.py", line 340, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: /lib64/libc.so.6: wrong ELF class: ELFCLASS64

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:50:07 2011
From: report at bugs.python.org (Juraj Ivancic)
Date: Sat, 26 Feb 2011 09:50:07 +0000
Subject: [issue11329] PyEval_InitThreads() not safe before Py_Initialize()
In-Reply-To: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>
Message-ID: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>


New submission from Juraj Ivancic <juraj.ivancic at gmail.com>:

It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation

http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads

Minimal repro:

#include "Python.h"
int main()
{
     PyEval_InitThreads();
     return 0;
}

Everything works if Py_Initialize() is called first.

----------
components: Interpreter Core
messages: 129515
nosy: Juraj.Ivancic
priority: normal
severity: normal
status: open
title: PyEval_InitThreads() not safe before Py_Initialize()
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11329>
_______________________________________

From report at bugs.python.org  Sat Feb 26 10:59:18 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 26 Feb 2011 09:59:18 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298714358.61.0.669852394722.issue11299@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Hi Alexandre,

I read your blog post, but I don't understand-- Why does bytecode need to be pickled in order to pickle live generators? I understand that the local variables need to be pickled, (and let's assume they're all pickleable,) and that a pointer to the current instruction needs to be pickled, but why the bytecode? When you pickle a normal function or a class, no bytecode gets pickled, so why does it have to be pickled here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:01:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 10:01:54 +0000
Subject: [issue11329] PyEval_InitThreads() not safe before Py_Initialize()
In-Reply-To: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>
Message-ID: <1298714514.34.0.192806357972.issue11329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the way the new GIL works, I'm afraid it's not really possible to support this (it needs some thread-state to be available).
Note that there is no reason, AFAIK, why you would want to call PyEval_InitThreads() before Py_Initialize().

----------
assignee:  -> docs at python
components: +Documentation
nosy: +amaury.forgeotdarc, docs at python, pitrou
type: crash -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11329>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:02:16 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 10:02:16 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298714536.78.0.15160141905.issue11327@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Python crashes when dereferencing 0x0000000000000018, which is NULL + 24

This means that it crashes here:

     p = asctime(&buf);
     if (p[24] == '\n')
         p[24] = '\0';

No check is made on asctime(3) return's value, so if it returns NULL, we'll segfault.

I think the problem is that gettmarg doesn't check its returned struct tm.

Also, in time_strtime, there's this comment:

 Checks added to make sure strftime() does not crash Python by
 
414        indexing blindly into some array for a textual representation
 
415        by some bad index (fixes bug #897625).
 
416  

Is there any good reason why those checks aren't performed directly in 
gettmarg ?

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:09:45 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 26 Feb 2011 10:09:45 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
	too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1298714985.78.0.683275987536.issue11322@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
nosy: +sdaoden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:33:37 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2011 10:33:37 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298716417.21.0.342778200364.issue11327@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>From the path names in the trace you appear to have a MacPorts Python 2.7 installed.  For what it's worth, the standard library test_time works for me on OS X 10.6.6 with a current MacPorts 2.7.1 as well as a python.org 2.7.1.  Exactly how did you try to run this, i.e. what are the results of:
   $ which python
   $ echo $pwd
   $ ls -l test_time.py

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:34:10 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 26 Feb 2011 10:34:10 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <AANLkTimiG2bTumkvNbcWpcRJeVQHyS_Uc8pYBKFGMmXT@mail.gmail.com>
Message-ID: <20110226103021.GA19885@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

11:12 ~/tmp $ python3 ~/usr/opt/py3k/lib/python3.3/test_zlib.py
Bus error

Your code snippet:

11:21 ~/tmp $ /usr/bin/time -lp python3 test.py

posix.stat_result(st_mode=33184, st_ino=10066605, st_dev=234881025, st_nlink=1, st_uid=502, st_gid=20, st_size=4294967300, st_atime=1298715813, st_mtime=1298715813, st_ctime=1298715813)
posix.stat_result(st_mode=33184, st_ino=10066605, st_dev=234881025, st_nlink=1, st_uid=502, st_gid=20, st_size=4294967300, st_atime=1298715813, st_mtime=1298715813, st_ctime=1298715813)
real        71.66
user         0.06
sys          3.71
          0  maximum resident set size
          0  average shared memory size
          0  average unshared data size
          0  average unshared stack size
          0  page reclaims
          0  page faults
          0  swaps
          0  block input operations
         57  block output operations
          0  messages sent
          0  messages received
          0  signals received
       2112  voluntary context switches
          0  involuntary context switches

On Fri, Feb 25, 2011 at 05:05:19PM +0000, Charles-Francois Natali wrote:
>
>Charles-Francois Natali <neologix at free.fr> added the comment:
>
>Could you try with this:
>
>?def setUp(self):
>? ? ? ? ? with open(support.TESTFN, "wb+") as f:
>? ? ? ? ? ? ? f.seek(_4G)
>? ? ? ? ? ? ? f.write(b"asdf")
>? ? ? ? ? ? ? f.flush()
>+? ? ? ? ? ? os.fsync(f.fileno())
>? ? ? ? ? ? ? self.mapping = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
>
>HFS+ doesn't seem to support sparse files, so the file is actually
>zero-filled asynchronously.
>Maybe the mapping gets done before the blocks have been allocated,
>which triggers a segfault when the first page is accessed.
>I'm not sure it'll make any difference, but I'm curious...
>
>Also, I'd be curious to see the result of
>
>"""
>import os
>
>name = '/tmp/foo'
>f = open(name, 'wb')
>f.seek(1 << 32)
>f.write(b'asdf')
>f.flush()
>print(os.fstat(f.fileno()))
>f.close()
>print(os.stat(name))
>"""
>
>Thanks !
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue11277>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:35:41 2011
From: report at bugs.python.org (Edoardo Spadolini)
Date: Sat, 26 Feb 2011 10:35:41 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298716541.71.0.142555633219.issue10868@psf.upfronthosting.co.za>


Edoardo Spadolini <kerio00 at gmail.com> added the comment:

Not really, but putting something in your inheritance lattice only to mark a class as providing an interface just doesn't seem right to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:39:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 26 Feb 2011 10:39:46 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1298716786.12.0.00289552847104.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch adding copy() and clear() to bytearrays, with tests and doc.

I didn't add the methods to MutableSequence because I have a doubt about it - in particular which exception get raised by .pop if it's empty. Curiously, lists and bytearrays raise different exceptions in this case - IndexError and OverflowError, respectively.

----------
assignee: eli.bendersky -> rhettinger
stage: commit review -> patch review
status: closed -> open
Added file: http://bugs.python.org/file20905/issue10516.bytearray.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:50:12 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 10:50:12 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298717412.35.0.483532562607.issue11327@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

True with the following:

import time

time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))

You'll get a segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:52:27 2011
From: report at bugs.python.org (akira)
Date: Sat, 26 Feb 2011 10:52:27 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

Since Python 3.2 logging package doesn't support formatting flags for the `asctime` keyword, but the documentation uses them. For example in Doc/library/logging.rst:

  FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'

should be replaced by:

  FORMAT = '%(asctime)s %(clientip)s %(user)-8s %(message)s'

The attached file 'doc-logging-asctime-r88640.patch' contains necessary changes.

An alternative solution would be to fix the logging package to restore the support.

----------
assignee: docs at python
components: Documentation
files: doc-logging-asctime-r88640.patch
keywords: patch
messages: 129524
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: logging doesn't support format flags for asctime keyword, but the docs use them
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20906/doc-logging-asctime-r88640.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:54:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 10:54:14 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298717654.11.0.865864411827.issue11330@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:54:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 10:54:54 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298717694.71.0.10994662103.issue11327@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 11:58:34 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2011 10:58:34 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298717914.29.0.115968949696.issue11327@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

$ /opt/local/bin/python2.7
Python 2.7.1 (r271:86832, Dec 31 2010, 11:59:23) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))
'Mon Feb 26 -1:00:00 2011'
>>> ^D
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Python 2.7.1+ (release27-maint, Jan 29 2011, 13:55:30) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime((2011, 2, 26, -1, 0, 0, 0, 0, 0))
'Mon Feb 26 -1:00:00 2011'
>>> ^D

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:01:20 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 11:01:20 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298718080.93.0.912478220071.issue11327@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

This explains why you don't get a segfault: your libc is broken ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:06:15 2011
From: report at bugs.python.org (akira)
Date: Sat, 26 Feb 2011 11:06:15 +0000
Subject: [issue11331] unused line in the logging-cookbook example
In-Reply-To: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>
Message-ID: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

The line with `LoggerAdapter` is not used in http://docs.python.org/dev/howto/logging-cookbook.html#using-filters-to-impart-contextual-information

Here's a patch for Doc/howto/logging-cookbook.rst: doc-logging-cookbook-unused-line-r88640.patch

----------
assignee: docs at python
components: Documentation
files: doc-logging-cookbook-unused-line-r88640.patch
keywords: patch
messages: 129527
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: unused line in the logging-cookbook example
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20907/doc-logging-cookbook-unused-line-r88640.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11331>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:07:30 2011
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Feb 2011 11:07:30 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298718450.72.0.603491374925.issue11327@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If it's broken, complain to Apple.

$ otool -L $(/opt/local/bin/python2.7 -c 'import time;print(time.__file__)')
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

That still doesn't explain the OP's crash on OS X 10.6.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:16:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Feb 2011 11:16:04 +0000
Subject: [issue11286] Some "trivial" python 2.x pickles fails to load
	in	Python 3.2
In-Reply-To: <1298382970.2.0.426359598125.issue11286@psf.upfronthosting.co.za>
Message-ID: <1298718964.54.0.0936253296452.issue11286@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

People may use SystemError for other purposes, but the docs are pretty clear it is only for internal errors that indicate an interpreter bug: http://docs.python.org/dev/library/exceptions.html#SystemError

Extension modules or an embedding application passing in bad data that fails a validation check isn't such a situation, so raising TypeError or ValueError is more appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11286>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:16:11 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 26 Feb 2011 11:16:11 +0000
Subject: [issue11331] unused line in the logging-cookbook example
In-Reply-To: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>
Message-ID: <1298718971.09.0.246607858973.issue11331@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11331>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:18:05 2011
From: report at bugs.python.org (Oliver Drake)
Date: Sat, 26 Feb 2011 11:18:05 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>


New submission from Oliver Drake <obdrake11 at gmail.com>:

Purely a modification to test_logging.py with the focus being to increase coverage. coverage.py now measures 97% (when running test_logging.py by itself). I'm not sure if I've followed py-dev unit test conventions exactly, I've created quite a few new test case classes, going by the model of having one unittest test case class for each class defined in the module under test. Comments welcome :)

----------
components: Tests
files: test_logging.diff
keywords: patch
messages: 129530
nosy: drakeol
priority: normal
severity: normal
status: open
title: Increase logging/__init__.py coverage to 97%
versions: Python 3.2
Added file: http://bugs.python.org/file20908/test_logging.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:30:28 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 26 Feb 2011 11:30:28 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <AANLkTimiG2bTumkvNbcWpcRJeVQHyS_Uc8pYBKFGMmXT@mail.gmail.com>
Message-ID: <20110226113018.GA38708@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

I'll give you the same result again but with additional clock(), 
just for a heart's pleasure:

clock(): 0.100958 , fstat(): posix.stat_result(st_mode=33184, st_ino=10075508, st_dev=234881025, st_nlink=1, st_uid=502, st_gid=20, st_size=4294967300, st_atime=1298719201, st_mtime=1298719305, st_ctime=1298719305)
> f.close()
> print('clock():', time.clock(), ', stat():', os.stat(name))
clock(): 3.75792 , stat(): posix.stat_result(st_mode=33184, st_ino=10075508, st_dev=234881025, st_nlink=1, st_uid=502, st_gid=20, st_size=4294967300, st_atime=1298719201, st_mtime=1298719305, st_ctime=1298719305)

Please don't assume i go for Mac OS X ... 
In the end you *always* need to implement an expensive state 
machine to get around long-known bugs, mis-implementations or 
other poops there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:41:10 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 11:41:10 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298720470.13.0.824951769799.issue11327@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> If it's broken, complain to Apple.

Actually, I checked glibc's asctime, and it has the same behaviour. But the point is that asctime can return NULL.

> That still doesn't explain the OP's crash on OS X 10.6.6.

Yes it does. If asctime returns NULL, you'll segfault.
Now, if you ask me why he's encoutering this bug, I'd guess that he's using py3k' test_time.py, which added tests feeding invalid tuples to time.asctime. But it's just a wild guess.

Anyway, the code in python 2.7 is buggy, and must be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 12:41:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 11:41:17 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298720477.08.0.0926913239132.issue11332@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> vinay.sajip
nosy: +brett.cannon, vinay.sajip
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:18:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 12:18:49 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298722729.29.0.121828230821.issue10866@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

New patch including a check for PyObject_GetBuffer()'s return value, the missing declaration of HAVE_SETHOSTNAME in pyconfig.h.in, and a test for giving a bytes values to the function.

----------
Added file: http://bugs.python.org/file20909/sethostname_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:24:34 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 26 Feb 2011 12:24:34 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

Currently instances of classes which inherit an ABC in collections.abc will have a __dict__.  This can be a problem for example a tree-like data structure. It would make sense to inherit for example MutableMapping, but that would possibly mean, that every node in the tree would have a __dict__, which is probably a waste of memory.

A workaround for this problem is not inheriting the ABC, and using ABCMeta.register (and optionally adding the mixin methods explicitly), but this feels like a hack.

The attached patch adds an empty __slots__ to the ABCs in collections.abc.  I excluded the mapping views (MappingView, KeysView, ItemsView and ValuesView), because they can't have an empty __slots__, and I think using a nonempty __slots__ possibly can cause problems in some cases with multiple inheritance.

----------
components: Library (Lib)
files: collections_abc_slots.diff
keywords: patch
messages: 129534
nosy: durban, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: Add empty __slots__ to collections.abc abstract base classes
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20910/collections_abc_slots.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:24:54 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 12:24:54 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298723094.38.0.279066758343.issue11327@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

I updated my local svn checkout, and the code has been fixed recently:


  r87648 | alexander.belopolsky | 2011-01-02 15:48:22 -0500 (Sun, 02 Jan 2011) | 1 line
  
  Issue #8013: Fixed time.asctime segfault when OS's asctime fails


    p = asctime(&buf);
    if (p == NULL) {
        PyErr_SetString(PyExc_ValueError, "invalid time");
        return NULL;
    }
    if (p[24] == '\n')
        p[24] = '\0';


So I'd suggest to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:32:16 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 26 Feb 2011 12:32:16 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298723536.85.0.171027197563.issue10868@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

> In what use-cases would you want to call MyABC.register() when defining
> a class instead of inheriting from MyABC?

For example if you don't want to inherit a __dict__ for a tree-like data structure (see also issue11333).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:42:14 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 26 Feb 2011 12:42:14 +0000
Subject: [issue11303] b'x'.decode('latin1') is much slower than
	b'x'.decode('latin-1')
In-Reply-To: <1298648586.43.0.590678188608.issue11303@psf.upfronthosting.co.za>
Message-ID: <20110226124204.GB38708@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

On Fri, Feb 25, 2011 at 03:43:06PM +0000, Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> r88586: Normalized the encoding names for Latin-1 and UTF-8 to
> 'latin-1' and 'utf-8' in the stdlib.

Even though - or maybe exactly because - i'm a newbie, i really 
want to add another message after all this biting is over. 
I've just read PEP 100 and msg129257 (on Issue 5902), and i feel 
a bit confused.

> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> It turns out that there are three "normalize" functions that are 
> successively applied to the encoding name during evaluation of 
> str.encode/str.decode.
> 
> 1. normalize_encoding() in unicodeobject.c
>
> This was added to have the few shortcuts we have in the C code
> for commonly used codecs match more encoding aliases.
>
> The shortcuts completely bypass the codec registry and also
> bypass the function call overhead incurred by codecs
> run via the codec registry.

The thing that i don't understand the most is that illegal 
(according to IANA standarts) names are good on the one hand 
(latin-1, utf-16-be), but bad on the other, i.e. in my 
group-preserving code or haypos very fast but name-joining patch 
(the first): a *local* change in unicodeobject.c, which' result is 
*only* used for the two users PyUnicode_Decode() and 
PyUnicode_AsEncodedString().  However:

> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> Programmers who don't use the encoding names triggering those
> optimizations will still have a running program, it'll only be
> a bit slower and that's perfectly fine.

> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> think rather than removing any hyphens, spaces, etc. the
> function should additionally:
>
>  * add hyphens whenever (they are missing and) there's switch
>     from [a-z] to [0-9]
>
> That way you end up with the correct names for the given set 
> of optimized encoding names.

haypos patch can easily be adjusted to reflect this, resulting in 
a much cleaner code in the two mentioned users, because 
normalize_encoding() did the job it was ment for. 
(Hmmm, and my own code could also be adjusted to match Python 
semantics (using hyphen instead of space as a group-separator), 
so that an end-user has the choice in between *all* IANA standart 
names (e.g. "ISO-8859-1", "ISO8859-1", "ISO_8859-1", "LATIN1"), 
and would gain the full optimization benefit of using latin-1, 
which seems to be pretty useful for limburger.)

> Ezio Melotti wrote:
> Marc-Andre Lemburg wrote:
>> That won't work, Victor, since it makes invalid encoding
>> names valid, e.g. 'utf(=)-8'.
>
> That already works in Python (thanks to encodings.normalize_encoding)

*However*: in PEP 100 Python has decided to go its own way 
a decade ago.

> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 2. normalizestring() in codecs.c
>
> This is the normalization applied by the codec registry. See PEP 100
> for details:
>
> """
>    Search functions are expected to take one argument, 
>    the encoding name in all lower case letters and with hyphens 
>    and spaces converted to underscores, ...
> """

> 3. normalize_encoding() in encodings/__init__.py
>
> This is part of the stdlib encodings package's codec search function.

First: *i* go for haypo:

> It's funny: we have 3 functions to normalize an encoding name, and
> each function does something else :-)

(that's Issue 11322:)
> We should first implement the same algorithm of the 3 normalization
> functions and add tests for them

And *i* don't understand anything else (*i* do have *my* - now 
furtherly optimized, thanks - s_textcodec_normalize_name()). 
However, two different ones (very fast thing which is enough to 
meet unicodeobject.c and a global one for anything else) may also do.
Isn't anything else a maintenance mess?  Where is that database, 
are there any known dependencies which are exposed to end-users?
Or the like.

I'm much too loud, and have a nice weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:54:19 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 26 Feb 2011 12:54:19 +0000
Subject: [issue11256] inspect.getcallargs raises TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298724859.97.0.715474215372.issue11256@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Updated patch with extra tests.

----------
Added file: http://bugs.python.org/file20911/issue11256_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11256>
_______________________________________

From report at bugs.python.org  Sat Feb 26 13:55:23 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 26 Feb 2011 12:55:23 +0000
Subject: [issue11303]
	b'x'.decode('latin1')	is	much	slower	than	b'x'.decode('latin-1')
In-Reply-To: <1298683573.26.0.881371064369.issue11303@psf.upfronthosting.co.za>
Message-ID: <4D68F839.4080603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Raymond Hettinger wrote:
> 
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
>> If you agree, Raymond, I'll backport the patch.
> 
> Yes.  That will address Antoine's legitimate concern about making other backports harder, and it will get all the Python's to use the canonical spelling.

Ok, I'll backport both the normalization and Alexander's patch.

> For other spellings like "utf8" or "latin1", I wonder if it would be useful to emit a warning/suggestion to use the standard spelling.

While it would make sense for Python programs, it would not for
cases where the encoding is read from some other source, e.g.
an XML encoding declaration.

However, perhaps we could have a warning which is disabled
per default and can be enabled using the -W option.

----------
title: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1') -> b'x'.decode('latin1')	is	much	slower	than	b'x'.decode('latin-1')

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11303>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:04:15 2011
From: report at bugs.python.org (Michael Foord)
Date: Sat, 26 Feb 2011 13:04:15 +0000
Subject: [issue11298] unittest discovery needs better explanation
In-Reply-To: <1298461373.56.0.0867432714067.issue11298@psf.upfronthosting.co.za>
Message-ID: <1298725455.78.0.483904637562.issue11298@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

No, tests as top level modules work fine too. Importability is the only requirement. (Projects themselves are not typically packages but contain packages - so the wording needs to change slightly but I like the rest.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11298>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:29:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 13:29:02 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298726942.99.0.382934160681.issue11323@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It still fails under AMD64 OpenIndiana:

======================================================================
ERROR: test_offset_overflow (test.test_os.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_os.py", line 1473, in test_offset_overflow
    sent = os.sendfile(self.sockno, self.fileno, offset, 4096)
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: test_send_at_certain_offset (test.test_os.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_os.py", line 1456, in test_send_at_certain_offset
    sent = self.sendfile_wrapper(self.sockno, self.fileno, offset, nbytes)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_os.py", line 1419, in sendfile_wrapper
    return os.sendfile(sock, file, offset, nbytes)
OSError: [Errno 22] Invalid argument

======================================================================
ERROR: test_send_whole_file (test.test_os.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_os.py", line 1436, in test_send_whole_file
    sent = self.sendfile_wrapper(self.sockno, self.fileno, offset, nbytes)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_os.py", line 1419, in sendfile_wrapper
    return os.sendfile(sock, file, offset, nbytes)
OSError: [Errno 22] Invalid argument


According to the man page, EINVAL means:

     EINVAL          The offset  cannot  be  represented  by  the
                     off_t  structure,  or the length is negative
                     when cast to ssize_t.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:31:02 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:31:02 +0000
Subject: [issue9795] nntplib.NNTP should support the context protocol
In-Reply-To: <1283899375.28.0.82339837152.issue9795@psf.upfronthosting.co.za>
Message-ID: <1298727062.49.0.582918847633.issue9795@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

(socket.error, EOFError) after quit() indicates that the socket is disconnected, in which case we should not raise any error (or at least, this is the approach we're using in ftplib) while all other NNTPError related errors are not suppressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9795>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:33:25 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:33:25 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298727205.13.0.0881794824099.issue11323@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:35:50 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:35:50 +0000
Subject: [issue11325] compilation warning with sendfile
In-Reply-To: <1298677169.65.0.896765267808.issue11325@psf.upfronthosting.co.za>
Message-ID: <1298727350.69.0.587540841861.issue11325@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11325>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:41:52 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:41:52 +0000
Subject: [issue11257] asyncore stores unnecessary object references
In-Reply-To: <1298216646.94.0.460064768402.issue11257@psf.upfronthosting.co.za>
Message-ID: <1298727712.4.0.311743212945.issue11257@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Unless there's a way to automatically call close() when a dispatcher instance is no longer referenced (and I can't think of anything to do that) I'd say we better close this as rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11257>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:56:30 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:56:30 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1230476318.95.0.898909480668.issue4761@psf.upfronthosting.co.za>
Message-ID: <1298728590.97.0.237980895004.issue4761@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

What about Doc/whatsnew/3.3.rst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:58:20 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 13:58:20 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298728700.98.0.0458578282328.issue11333@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:59:14 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 26 Feb 2011 13:59:14 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298728754.08.0.458234430807.issue11259@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

Real patch is the first hunk of attached file. Other 2 hunks are optimizations..

----------
keywords: +patch
Added file: http://bugs.python.org/file20912/z.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 26 14:59:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 13:59:41 +0000
Subject: [issue11082] ValueError: Content-Length should be specified
In-Reply-To: <1296501492.73.0.362770141375.issue11082@psf.upfronthosting.co.za>
Message-ID: <1298728781.98.0.759966237782.issue11082@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

BTW, there was no entry in Misc/NEWS, so this was not in whatsnew/3.2.rst.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11082>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:00:19 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 26 Feb 2011 14:00:19 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298728819.22.0.957303108427.issue11259@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


Removed file: http://bugs.python.org/file20912/z.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:01:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 14:01:18 +0000
Subject: [issue4761] create Python wrappers for openat() and others
In-Reply-To: <1298728590.97.0.237980895004.issue4761@psf.upfronthosting.co.za>
Message-ID: <1298728874.3704.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What about Doc/whatsnew/3.3.rst?

This is filled by Raymond (or other people) when the release nears.
No need to care about it in regular commits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4761>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:04:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 14:04:15 +0000
Subject: [issue11171] Python 2.7.1 does not start when "./configure" is used
	with "--prefix" != "--exec-prefix"
In-Reply-To: <1297345666.23.0.22592660459.issue11171@psf.upfronthosting.co.za>
Message-ID: <1298729055.19.0.559878478211.issue11171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I was unclear.  distutils.sysconfig does not play a role in the startup of python anymore.  My question was: does distutils.sysconfig._get_makefile_filename have the same bug as the one that was fixed in sysconfig._get_makefile_filename?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11171>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:16:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 14:16:44 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298729804.36.0.280162377116.issue11323@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, so the root cause is that sendfile() under Solaris can fail with EINVAL when the offset is past the end of file (but only on 64-bit builds, strangely :-)). Here is a patch, tested under Linux, 32-bit OpenSolaris and 64-bit OpenSolaris. It also uses a more reasonable data size for the tests, since 10MB makes it annoying to trace problems.

----------
stage:  -> patch review
versions: +Python 3.2 -Python 3.3
Added file: http://bugs.python.org/file20913/test_sendfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:18:29 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 14:18:29 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298729909.12.0.991162883756.issue11330@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release32-maint (r88644). Support was reinstated - the docs weren't changed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:19:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 14:19:16 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1298729956.68.0.674983257673.issue11085@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Some missed doc changes.

----------
keywords: +patch
Added file: http://bugs.python.org/file20914/collections.abc-in-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11085>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:25:56 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 14:25:56 +0000
Subject: [issue11331] unused line in the logging-cookbook example
In-Reply-To: <1298718374.95.0.797465744013.issue11331@psf.upfronthosting.co.za>
Message-ID: <1298730356.74.0.876437903257.issue11331@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into py3k and release32-maint (r88645), thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11331>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:27:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 14:27:06 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298730426.13.0.10162618077.issue11330@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Shouldn?t there be a regression test for this?

----------
components: +Library (Lib) -Documentation
nosy: +eric.araujo -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:28:13 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 14:28:13 +0000
Subject: [issue10882] Add os.sendfile()
In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za>
Message-ID: <1298730493.52.0.656630623352.issue10882@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It seems we have a failure on Leopard:

I think the issue is you request a 4096 transfer near the end of file, but there aren't that many bytes remaining. Apparently OS X then doesn't transfer anything and returns 0. Hint:

>>> 10485760. / 4096
2560.0
>>> 10486272. / 4096
2560.125

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10882>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:34:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 14:34:34 +0000
Subject: [issue11071] What's New review comments
In-Reply-To: <1296394185.46.0.874389567772.issue11071@psf.upfronthosting.co.za>
Message-ID: <1298730874.77.0.0465446798617.issue11071@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The section about os.environb talks about unencoded bytes and unencoded environment variables instead of undecoded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11071>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:39:28 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 14:39:28 +0000
Subject: [issue11323] os.sendfile() bo failure on solaris
In-Reply-To: <1298664198.03.0.51207778362.issue11323@psf.upfronthosting.co.za>
Message-ID: <1298731168.9.0.71430532315.issue11323@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be fixed in r88647.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11323>
_______________________________________

From report at bugs.python.org  Sat Feb 26 15:39:28 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 26 Feb 2011 14:39:28 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298731168.89.0.871889793332.issue11259@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

only first hunk is really the patch. 2 next hunks are optimizations.

----------
Added file: http://bugs.python.org/file20915/z.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:14:21 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 26 Feb 2011 15:14:21 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298733261.01.0.864041716258.issue11259@psf.upfronthosting.co.za>


???? ????????? <socketpair at gmail.com> added the comment:

===== ORIGINAL ===========
$ ./qwe.py 10
read length: 10
read data: "xxxxxxxxxx"
should read "test". read: "test"

$ ./qwe.py -10
read length: -10
read data: "xxxxxx"
should read "test". read: "xxxxtest"

===== PATCHED ===========
$ ./qwe.py 10
read length: 10
read data: "xxxxxxxxxx"
should read "test". read: "test"

$ ./qwe.py -10
read length: -10
error: uncaptured python exception, closing channel <__main__.http_request_handler connected '' at 0x7fe69b9bf878> (<type 'exceptions.ValueError'>:Negative terminator value is not allowed [/usr/lib/python2.6/asyncore.py|read|78] [/usr/lib/python2.6/asyncore.py|handle_read_event|428] [/tmp/qwe/asynchat.py|handle_read|160] [./qwe.py|found_terminator|19] [/tmp/qwe/asynchat.py|set_terminator|98])
root at fad:/tmp/qwe#

----------
Added file: http://bugs.python.org/file20916/qwe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:14:54 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 26 Feb 2011 15:14:54 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1298733294.61.0.573385145394.issue11259@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


Added file: http://bugs.python.org/file20917/shorttest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:25:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 15:25:19 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298733919.33.0.303303366382.issue11332@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Thanks for doing this, I appreciate the effort you've put into it. My comments:

1. Each test class ought to be independent, but they aren't - for example, if I comment out all of your test classes other than LoggerTest, it fails.
2. I try and avoid modifying the handler list across tests. Rather than running test_logging.py by itself, it should run cleanly when run using

pythonX.Y regrtest.py test_logging test_logging

in the Lib/test folder. (That's right, I invoke it twice because that sometimes flushes out bugs which don't show up with a single invocation.)
3. I'm not if it's worth it to monkey-patch stuff (such as the _log method in test_log_invalidLevel), or even patching io.StringIO in test_findCaller. In general more coverage is good, but I also favour being pragmatic about tests. IMO, testing at too low a level can incur unnecessary overhead in re-implementing tests if some internals are refactored. Some of your tests do fall into that category, e.g. checking that the "parent" attribute is polled is an implementation detail, though checking hasHandlers() isn't (in test_hasHandlers_breakOnPropagateFalse). Another example: that logging.disable sets logging.root.manager.disable is an implementation detail, and so not worth checking as much as checking the *effect* of the disable call on logging output.

ISTM other tests in the stdlib test suite do not go to the low level that yours do - essentially mocking parts of the system. Although undoubtedly I should incorporate some of your tests to fill in gaps in coverage, I am not sure I want to just accept the patch as it is, for the reasons I have given above.  (Notwithstanding that, please understand that I still appreciate the effort you've put into this somewhat unglamorous activity.)

As a matter of interest, what was the coverage percentage *before* you made your changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:34:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 26 Feb 2011 15:34:34 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298734474.78.0.715999861325.issue11236@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I fail to see the bug here. Python's getpass.py is mimicing the                                                                                                        
behavior of getpass.c                                                                                                                                                  
                                                                                                                                                                       
Your patch tries to remove, termios.ISIG , but it was specifically                                                                                                     
added so that getpass.py is closer to the POSIX's getpass                                                                                                              
                                                                                                                                                                       
http://mail.python.org/pipermail/python-dev/2003-December/040579.html                                                                                                  
                                                                                                                                                                       
Also, try an example program which uses getpass.c                                                                                                                      
http://www.koders.com/c/fidFB8B9443522DCC3CC53ECCC0FFED861FE898F3A1.aspx?s=%22unknown%22                                                                               
                                                                                                                                                                       
And try ctrl-c and ctrl-z for those, the behavior is same what you                                                                                                     
decribe in this bug-report.                                                                                                                                            
                                                                                                                                                                       
So, having the function behavior sames as POSIX one is really not a                                                                                                    
bug and just a change from the previous behavior. Would you agree to                                                                                                   
this stance and shall we close the bug?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:37:08 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 15:37:08 +0000
Subject: [issue9441] increase logging handlers test coverage
In-Reply-To: <1280597180.41.0.450800729974.issue9441@psf.upfronthosting.co.za>
Message-ID: <1298734628.02.0.225999256014.issue9441@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into release32-maint (r88651).

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9441>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:46:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 15:46:19 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298735179.64.0.435891070683.issue11330@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

There should, and I'm looking at some additional tests suggested for inclusion in #11332. I'll mark the issue as pending to remind me to ensure that the test gets added soon.

----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 16:59:08 2011
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 26 Feb 2011 15:59:08 +0000
Subject: [issue11236] getpass.getpass does not respond to ctrl-c or ctrl-z
In-Reply-To: <1297976188.87.0.766078134711.issue11236@psf.upfronthosting.co.za>
Message-ID: <1298735948.14.0.953054748186.issue11236@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

No, I do not, for several reasons.

First of all, this is not a change *from* previous behaviour, but a change *back to* previous behaviour. And sensible behaviour, too.

Secondly, I have tested what getpass does on windows (Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32). There, I get a KeyboardInterrupt when pressing ctrl-c. So for the simple reason of having consistend cross-platform behaviour, either the linux or the windows implementation should change.

Thirdly, the reason for adding the ISIG flag was that it is 'a possible security hole' - but no-one actually mentions *what* that hole would be. As Guido notes (in that same thread!): "Sorry, but this just doesn't make sense.  There are so many differences between C and Python that you can't just compare a C and a Python version of a function and pointing at the differences as possible security holes or bugs.".

Lastly, I see no reason to mimic POSIX behaviour per se. Why not use the POSIX getpass function in the first place, then? 

By the way - even with ISIG on, it should be possible to support KeyboardInterrupts - just read per-character instead of per-line (cf. the windows getpass).

[1] http://mail.python.org/pipermail/python-dev/2003-December/040583.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11236>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:03:38 2011
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 26 Feb 2011 16:03:38 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298736218.15.0.74616521234.issue11299@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

The value of the instruction pointer depends on the byte-code. So it's not portable either.

But, the bigger issue is the fact generator objects do not have names we can refer to, unlike top-level functions and classes which pickle supports. Similarly, we can't pickle lambdas and nested-functions for this exact reason.

Personally, I haven't found a way around this. But, that doesn't mean there isn't one. If you find one, I will more than pleased to review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:06:49 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 16:06:49 +0000
Subject: [issue11330] logging doesn't support format flags for asctime keyword,
	but the docs use them
In-Reply-To: <1298717547.6.0.165595547047.issue11330@psf.upfronthosting.co.za>
Message-ID: <1298736409.66.0.108717025382.issue11330@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Regression test added to py3k and release32-maint (r88654). I just had to modify an existing test case.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11330>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:07:49 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 26 Feb 2011 16:07:49 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298736469.96.0.962069044942.issue10866@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

The patch looks good.

Just to be clear, on my system running "autoreconf" adds the correct stuff to pyconfig.h.in

Isn't it best to leave it up to the committer to generate "configure" and "pyconfig.h.in", especially since different autoconf versions can create a lot of differences?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:13:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 16:13:40 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1298736469.96.0.962069044942.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298736818.3704.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch looks good.
> 
> Just to be clear, on my system running "autoreconf" adds the correct
> stuff to pyconfig.h.in

Ah, strange. I used "autoconf" and it didn't...

> Isn't it best to leave it up to the committer to generate "configure"
> and "pyconfig.h.in", especially since different autoconf versions can
> create a lot of differences?

Right, but in this case the version was the same and it was easier to
create the patch that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:18:04 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 26 Feb 2011 16:18:04 +0000
Subject: [issue10866] Add sethostname()
In-Reply-To: <1294474577.93.0.97800635081.issue10866@psf.upfronthosting.co.za>
Message-ID: <1298737084.85.0.363440041551.issue10866@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> Ah, strange. I used "autoconf" and it didn't...

>From the man page of autoreconf:
 Run  `autoconf'  (and  `autoheader', `aclocal', `automake', `autopoint'    
 (formerly `gettextize'), and `libtoolize' where appropriate) repeatedly
 to  remake  the GNU Build System files in the DIRECTORIES or the direc?
 tory trees driven by CONFIGURE-AC (defaulting to `.').

I guess it autoheader that regenerates pyconfig.h.in

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10866>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:31:08 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 16:31:08 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298737868.68.0.901548670059.issue11333@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

+1.  I've bumped into exactly this problem (https://github.com/DanielStutzbach/blist/issues/closed#issue/29)

I'm not intimately familiar with how __slots__ works.  Are there any drawbacks to adding an empty __slots__ to the ABCs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:32:13 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 16:32:13 +0000
Subject: [issue10868] ABCMeta.register() should work as a decorator
In-Reply-To: <1294529533.15.0.442078735636.issue10868@psf.upfronthosting.co.za>
Message-ID: <1298737933.04.0.536803100349.issue10868@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Sounds good to me.  Thanks for the clarifications and satisfying my curiosity! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10868>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:36:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 16:36:32 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298738192.63.0.0449753822422.issue11333@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:45:22 2011
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 26 Feb 2011 16:45:22 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298738722.13.0.933703628255.issue11299@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

*"generator objects do not have names we can refer to"*

How about referring to the generator function that created them and to all the arguments?

Regarding instruction pointer, I really don't know the internals of how this works. Can we make some arrangement so we can specify line number (and possibly column number too) as a cross-interpreter instruction pointer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:53:01 2011
From: report at bugs.python.org (dave)
Date: Sat, 26 Feb 2011 16:53:01 +0000
Subject: [issue11334] Failed to build _multiprocessing on Mac OS X
In-Reply-To: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>
Message-ID: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>


New submission from dave <dev66 at gmx.de>:

hi community,

i cannot import multiprocessing since it fails(?) during build.
could someone point out a solution for me?

thanks a lot in advance.
dave



$ python
Python 2.7.1 (r271:86832, Feb 26 2011, 17:19:29) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> import multiprocessing
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tools/python/lib/python2.7/multiprocessing/__init__.py", line 83, in <module>
    import _multiprocessing
ImportError: No module named _multiprocessing




This is what i did to compile python 2.7:

export MACOSX_DEPLOYMENT_TARGET=10.6
export ARCHFLAGS="-arch i386"
export CXXFLAGS="-arch i386"
export CFLAGS="-arch i386"
export FFLAGS="-arch i386"
export LDFLAGS="-Wall -undefined dynamic_lookup -arch i386"

./configure
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... darwin
checking EXTRAPLATDIR... $(PLATMACDIRS)
checking machine type as reported by uname -m... i386
checking for --without-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for --with-cxx-main=<compiler>... no
checking for g++... g++
[...]
config.status: pyconfig.h is unchanged
creating Modules/Setup
creating Modules/Setup.local
creating Makefile


make -j 4
[...]
/private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c: In function 'semlock_acquire':
/private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c:314: warning: implicit declaration of function 'sem_timedwait'
*** WARNING: renaming "_multiprocessing" since importing it failed: dlopen(build/lib.macosx-10.6-i386-2.7/_multiprocessing.so, 2): Symbol not found: _sem_timedwait
  Referenced from: /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so
  Expected in: flat namespace
 in /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so
[...]
ranlib libpython2.7.a
gcc -Wall -undefined dynamic_lookup -arch i386 -u _PyMac_Error -o python.exe \
                        Modules/python.o \
                        libpython2.7.a -ldl  -framework CoreFoundation     
building dbm using ndbm

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             gdbm               linuxaudiodev   
ossaudiodev        sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

Failed to build these modules:
_multiprocessing   spwd

----------
assignee: ronaldoussoren
components: Macintosh
messages: 129573
nosy: dev66, ronaldoussoren
priority: normal
severity: normal
status: open
title: Failed to build _multiprocessing on Mac OS X
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11334>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:54:07 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 16:54:07 +0000
Subject: [issue11334] Failed to build _multiprocessing on Mac OS X
In-Reply-To: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>
Message-ID: <1298739247.41.0.814204626799.issue11334@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: ronaldoussoren -> 
nosy: +asksol, jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11334>
_______________________________________

From report at bugs.python.org  Sat Feb 26 17:54:30 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 16:54:30 +0000
Subject: [issue11334] Failed to build _multiprocessing on Mac OS X
In-Reply-To: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>
Message-ID: <1298739270.48.0.57766296348.issue11334@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11334>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:02:25 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 17:02:25 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

In list.sort, if a key function throws an exception, the memory to store the keys is never freed.  I introduced the bug in r86937.  I'll upload a patch for review shortly.

----------
assignee: stutzbach
components: Interpreter Core
messages: 129574
nosy: pitrou, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak after key function failure in sort
type: resource usage
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11335>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:12:56 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 26 Feb 2011 17:12:56 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1298740376.32.0.0675869797368.issue11335@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Below is a link to the code where leak occurs and the patch goes:

http://svn.python.org/view/python/branches/py3k/Objects/listobject.c?view=markup&pathrev=88554#l1944

----------
keywords: +3.2regression, needs review, patch
Added file: http://bugs.python.org/file20918/plug-leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11335>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:28:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Feb 2011 17:28:42 +0000
Subject: [issue11299] Allow deepcopying and pickling paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1298741322.31.0.522103999517.issue11299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Alexandre,
Do the considerations against pickling apply to deep copying? It would seem that copying bytecode and pointer within a run should be ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:28:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 17:28:46 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298741326.45.0.0570207309409.issue11321@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +alexandre.vassalotti, brett.cannon, ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:30:25 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 26 Feb 2011 17:30:25 +0000
Subject: [issue11174] add argparse formatting option to display type names for
	metavar
In-Reply-To: <1297352753.29.0.422535680818.issue11174@psf.upfronthosting.co.za>
Message-ID: <1298741425.06.0.879646820394.issue11174@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

First draft of patch with this functionality. Test, patch and docs are included. I'll gladly work further on this, so I would appreciate some advice and suggestions.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file20919/11174.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11174>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:31:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Feb 2011 17:31:51 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298741511.2.0.40548897823.issue11333@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:33:55 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Feb 2011 17:33:55 +0000
Subject: [issue11335] Memory leak after key function failure in sort
In-Reply-To: <1298739745.54.0.516903833906.issue11335@psf.upfronthosting.co.za>
Message-ID: <1298741635.63.0.970211728926.issue11335@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

LGTM

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11335>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:45:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Feb 2011 17:45:20 +0000
Subject: [issue11324] ConfigParser(interpolation=None) doesn't work
In-Reply-To: <1298666228.44.0.489583826736.issue11324@psf.upfronthosting.co.za>
Message-ID: <1298742320.57.0.33157047369.issue11324@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Could you also add a test?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11324>
_______________________________________

From report at bugs.python.org  Sat Feb 26 18:58:18 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 17:58:18 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1298743098.29.0.77598708216.issue9931@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r88652 (3.3) and r88655 (3.2). Unfortunately, Paul's buildbot seems a bit stuck in a previous build...
(I didn't commit to 2.7 since things look fine there)

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:26:55 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 26 Feb 2011 18:26:55 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1298744815.66.0.592343465287.issue8594@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment set source_address attribute and updates doc.
It still keeps using support.find_unused_port() which is also used in test_socket.py though [1], so it shouldn't cause problems.

http://svn.python.org/view/python/trunk/Lib/test/test_socket.py?r1=77263&r2=77262&pathrev=77263

----------
Added file: http://bugs.python.org/file20920/ftplib_source_address.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8594>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:35:16 2011
From: report at bugs.python.org (blokeley)
Date: Sat, 26 Feb 2011 18:35:16 +0000
Subject: [issue11336] Typo in patch.rst
In-Reply-To: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>
Message-ID: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>


New submission from blokeley <blokeley at gmail.com>:

I think that a typographical error was made in patch.rst.

Should "(do not that not all checks apply to non-core developers)"
read "(note that not all checks apply to non-core developers)"?

Patch attached.

----------
assignee: docs at python
components: Documentation
files: grammar_fix.patch
keywords: patch
messages: 129583
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: Typo in patch.rst
type: behavior
Added file: http://bugs.python.org/file20921/grammar_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11336>
_______________________________________

From report at bugs.python.org  Sat Feb 26 19:37:39 2011
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 26 Feb 2011 18:37:39 +0000
Subject: [issue11337] Nothing refers to footnote [1] on page "6. Simple
	Statements" in Language Reference
In-Reply-To: <1298745459.54.0.732710965592.issue11337@psf.upfronthosting.co.za>
Message-ID: <1298745459.54.0.732710965592.issue11337@psf.upfronthosting.co.za>


New submission from Mitchell Model <mlm at acm.org>:

I can't find a reference to footnote [1] on page "6. Simple Statements" in Language Reference. Either the footnote should be removed or a [1] link to it should appear on the page.

----------
assignee: docs at python
components: Documentation
messages: 129584
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: Nothing refers to footnote [1] on page "6. Simple Statements" in Language Reference
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11337>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:13:47 2011
From: report at bugs.python.org (blokeley)
Date: Sat, 26 Feb 2011 19:13:47 +0000
Subject: [issue11338] No list of Python hg repositories
In-Reply-To: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>
Message-ID: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>


New submission from blokeley <blokeley at gmail.com>:

Recently, I've logged a few issues on http://bugs.python.org/ and tried to submit patches where possible.

However, I have not been able to find any documentation that states where the hg repositories are. There are some under http://hg.python.org/ and some under http://code.python.org/hg

Please could the documentation somewhere list the official repos and what they are used for.

I have attached a patch to the devguide repo which probably has:
 * The wrong list of repos (I still don't know what the correct list is); and
 * The list in the wrong part of the documentation.

Nevertheless, I hope this helps.

----------
assignee: docs at python
components: Documentation
files: repo_locations.patch
keywords: patch
messages: 129585
nosy: blokeley, docs at python
priority: normal
severity: normal
status: open
title: No list of Python hg repositories
type: behavior
Added file: http://bugs.python.org/file20922/repo_locations.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11338>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:35:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 19:35:14 +0000
Subject: [issue11338] No list of Python hg repositories
In-Reply-To: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>
Message-ID: <1298748914.07.0.509755119079.issue11338@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the suggestion. We are actually starting our official transition to hg, which makes things a bit unstable.

The final URL (http://hg.python.org/cpython/) is currently a test repo, while the "usable for work right now" (http://code.python.org/hg/) repositories are temporary mirrors which will get dismantled once the transition is over. Meaning we probably want to adapt your patch a bit, once the dust settles ;)

----------
nosy: +brett.cannon, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11338>
_______________________________________

From report at bugs.python.org  Sat Feb 26 20:39:45 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 19:39:45 +0000
Subject: [issue11277] test_zlib crashes under Snow Leopard buildbot
In-Reply-To: <1298326395.85.0.760673741294.issue11277@psf.upfronthosting.co.za>
Message-ID: <1298749185.77.0.125437903665.issue11277@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11277>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:23:40 2011
From: report at bugs.python.org (Andy Harrington)
Date: Sat, 26 Feb 2011 20:23:40 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>


New submission from Andy Harrington <aharrin at luc.edu>:

You cannot make a self-referential annotation like

class Graph:
    def reverse(self) -> Graph:
       # ...

This corresponds to a common coding situation.

----------
components: Interpreter Core
messages: 129587
nosy: andyharrington
priority: normal
severity: normal
status: open
title: annotation for class being defined
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:27:41 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 20:27:41 +0000
Subject: [issue11327] Running test_time.py in python27 caused python to
	unexpectedly quit
In-Reply-To: <1298702258.76.0.565935725786.issue11327@psf.upfronthosting.co.za>
Message-ID: <1298752061.57.0.93545468533.issue11327@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11327>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:30:00 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 20:30:00 +0000
Subject: [issue11340] test_distutils fails
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>


New submission from Westley Mart?nez <anikom15 at gmail.com>:

test_compressed_deprecated failed

----------
components: Tests
files: test_distutils
messages: 129588
nosy: anikom15
priority: normal
severity: normal
status: open
title: test_distutils fails
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file20923/test_distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11340>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:31:33 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 20:31:33 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>


New submission from Westley Mart?nez <anikom15 at gmail.com>:

test_invalid_offset failed on linux2.

----------
components: Tests
files: test_os
messages: 129589
nosy: anikom15
priority: normal
severity: normal
status: open
title: test_os fails
versions: Python 3.3
Added file: http://bugs.python.org/file20924/test_os

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:32:08 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 20:32:08 +0000
Subject: [issue11336] Typo in patch.rst
In-Reply-To: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>
Message-ID: <1298752328.61.0.592783707898.issue11336@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Thanks for the patch, but the wording was completely changed a little while ago so the error has been dealt with.

----------
nosy: +brett.cannon
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11336>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:36:15 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Feb 2011 20:36:15 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298752575.71.0.533997998505.issue11339@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This has been true forever. I suggest you try python-ideas.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:51:02 2011
From: report at bugs.python.org (blokeley)
Date: Sat, 26 Feb 2011 20:51:02 +0000
Subject: [issue11336] Typo in patch.rst
In-Reply-To: <1298745316.5.0.407434560155.issue11336@psf.upfronthosting.co.za>
Message-ID: <1298753462.24.0.634359564849.issue11336@psf.upfronthosting.co.za>


blokeley <blokeley at gmail.com> added the comment:

I updated to the tip of http://hg.python.org/devguide on the hg_transition branch. If this isn't the latest dev guide, what is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11336>
_______________________________________

From report at bugs.python.org  Sat Feb 26 21:57:13 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Feb 2011 20:57:13 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298753833.34.0.415658373164.issue11332@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just to give an opinion (which can be ignored), I see no issue with mocking if done carefully and properly. It should just be kept to a minimum (and typically be privately exposing certain things that can be overridden).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:19:45 2011
From: report at bugs.python.org (SilentGhost)
Date: Sat, 26 Feb 2011 21:19:45 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298755185.49.0.35494439555.issue11341@psf.upfronthosting.co.za>


SilentGhost <ghost.adh at gmail.com> added the comment:

Which revision are you trying with? I cannot reproduce this with r88656

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:25:11 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 21:25:11 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298755511.45.0.382994157028.issue11341@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Errno 75 is EOVERFLOW here (Linux), which doesn't seem to be mentioned in sendfile's man page.
Can you describe your system? (CPU architecture, bitness, endianness, glibc/kernel version, etc.)

----------
assignee:  -> giampaolo.rodola
nosy: +giampaolo.rodola, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:31:41 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 21:31:41 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298755901.79.0.826105601743.issue11341@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

rev 88657
Arch Linux 2.6.37 x86_64 with glibc2.6
64-bit, little endian

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:35:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 21:35:55 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298755901.79.0.826105601743.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298756151.3704.32.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> rev 88657
> Arch Linux 2.6.37 x86_64 with glibc2.6
> 64-bit, little endian

You are not running under a VM or something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:39:02 2011
From: report at bugs.python.org (LW)
Date: Sat, 26 Feb 2011 21:39:02 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>


New submission from LW <cjejuni2000 at yahoo.com>:

1 test failed:
    test_urllib2_localnet
1 test altered the execution environment:
    test_urllib2
21 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_gdb
    test_kqueue test_ossaudiodev test_smtpnet test_socketserver
    test_startfile test_timeout test_tk test_ttk_guionly
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64
1 skip unexpected on linux2:
    test_ttk_guionly
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='UTF-8'>
make: *** [test] Error 1

----------
components: IO
messages: 129598
nosy: cjejuni2000
priority: normal
severity: normal
status: open
title: ResourceWarning: unclosed file <_io.TextIOWrapper
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:42:01 2011
From: report at bugs.python.org (LW)
Date: Sat, 26 Feb 2011 21:42:01 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298756521.71.0.235203204908.issue11342@psf.upfronthosting.co.za>


LW <cjejuni2000 at yahoo.com> added the comment:

[ 92/349] test_distutils
/home/les/Downloads/Python-3.2/Lib/distutils/command/sdist.py:197: ResourceWarning: unclosed file <_io.TextIOWrapper name='MANIFEST.in' mode='r' encoding='UTF-8'>
  self.read_template()
unknown, 0: Warning: using regular magic file `/etc/magic'
unknown, 0: Warning: using regular magic file `/etc/magic'

----------
assignee:  -> tarek
components: +Distutils -IO
nosy: +eric.araujo, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:43:20 2011
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 26 Feb 2011 21:43:20 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298756600.76.0.443139916078.issue11341@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

> You are not running under a VM or something?

No

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 22:45:35 2011
From: report at bugs.python.org (dave)
Date: Sat, 26 Feb 2011 21:45:35 +0000
Subject: [issue11334] Failed to build _multiprocessing on Mac OS X
In-Reply-To: <1298739181.17.0.400956610125.issue11334@psf.upfronthosting.co.za>
Message-ID: <1298756735.54.0.731141469437.issue11334@psf.upfronthosting.co.za>


dave <dev66 at gmx.de> added the comment:

seems the multiprocessing issue was produced by the dynamic_lookup 
parameter in the LDFLAGS...
after removing this, "import multiprocessing" works...

thanks


> export LDFLAGS="-Wall -undefined dynamic_lookup -arch i386"

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11334>
_______________________________________

From report at bugs.python.org  Sat Feb 26 23:06:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Feb 2011 22:06:50 +0000
Subject: [issue11250] 2to3 truncates files at formfeed character
In-Reply-To: <1298159845.78.0.925914963765.issue11250@psf.upfronthosting.co.za>
Message-ID: <1298758010.0.0.191198090059.issue11250@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r88661

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11250>
_______________________________________

From report at bugs.python.org  Sat Feb 26 23:21:45 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sat, 26 Feb 2011 22:21:45 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298752293.07.0.502448238318.issue11341@psf.upfronthosting.co.za>
Message-ID: <1298758905.8.0.691563693808.issue11341@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Errno 75 is EOVERFLOW here (Linux), which doesn't seem to be mentioned in sendfile's man page.
> Can you describe your system? (CPU architecture, bitness, endianness, glibc/kernel version, etc.)

Just checked the source code:
in fs/read_write.c:do_sendfile

 841         pos = *ppos;
 842         if (unlikely(pos + count > max)) {
 843                 retval = -EOVERFLOW;
 844                 if (pos >= max)
 845                         goto fput_out;
 846                 count = max - pos;
 847         }

and 

 869         if (*ppos > max)
 870                 retval = -EOVERFLOW;

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Sat Feb 26 23:39:52 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 26 Feb 2011 22:39:52 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>
Message-ID: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Currently, if the parser's internal stack is full (as it happens when
the parser tries to parse a deeply nested structure), the parser
writes an error message to stderr and a bare MemoryError is
raised. That way, it is really hard for REPLs do handle input that
causes the parser to exhaust its stack correctly (see e.g. ``python -c
"print '(' * 100 + ')' * 100" | python -c "import code;
code.interact()"``).

In my opinion, a SyntaxError would be great because that way one can
easily see where in the source code the error is caused. One reason
against that (stated by MvL in msg1687) is that it's really
syntactically correct Python and only the parser can't parse it. But
then, the same is also true when there are too many indentation levels
in which case an `IndentationError` is raised (which is a subclass of
`SyntaxError`).

I have attached two patches: The first still raises a `MemoryError`
(for the sake of backward compatibility) but adds a message ("too many
opening parens") to it. The second raises a `SyntaxError` instead.

----------
components: Interpreter Core
files: parser_nested_MemoryError.patch
keywords: patch
messages: 129604
nosy: Trundle, marienz
priority: normal
severity: normal
status: open
title: Make errors due to full parser stack identifiable
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file20925/parser_nested_MemoryError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sat Feb 26 23:40:29 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 26 Feb 2011 22:40:29 +0000
Subject: [issue11343] Make errors due to full parser stack identifiable
In-Reply-To: <1298759991.59.0.16834388397.issue11343@psf.upfronthosting.co.za>
Message-ID: <1298760029.62.0.0134718316984.issue11343@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


Added file: http://bugs.python.org/file20926/parser_nested_SyntaxError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11343>
_______________________________________

From report at bugs.python.org  Sun Feb 27 00:36:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Feb 2011 23:36:34 +0000
Subject: [issue11326] connect_ex() implementation missing for SSL sockets
In-Reply-To: <1298680273.55.0.581698432494.issue11326@psf.upfronthosting.co.za>
Message-ID: <1298763394.39.0.145692662623.issue11326@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch + some tests in r88664 (3.3), r88665 (3.2) and r88666 (2.7). Thanks for reporting this!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11326>
_______________________________________

From report at bugs.python.org  Sun Feb 27 00:57:10 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Feb 2011 23:57:10 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298764630.81.0.800513653472.issue11332@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@Brett: I've no religious/dogmatic objection to mocking, either, so I agree with your comment. I merely observed that it's not generally implemented in the Python test suite (not that I've made an exhaustive study of it, so I'm open to being corrected on this point). Also, I don't see much value in some of the low-level tests in the patch. For example: logging.disable is defined as

def disable(level):
    """
    Disable all logging calls less severe than 'level'.
    """
    root.manager.disable = level

The test for it is:

    def test_disable(self):
        disableBackup = logging.root.manager.disable
        logging.disable(10)
        self.assertEqual(logging.root.manager.disable, 10)
        logging.root.manager.disable = disableBackup

which is really just testing at a low level - that the attribute was set - but not more usefully, at a higher level, the practical effect of the disable call.

I appreciate the value that tests bring, but I'm just being a bit wary of letting the tail wag the dog too much in the interests of higher coverage ;-) So, I suppose my test case preferences tend more towards an acceptance test style rather than a "pure" unit test style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sun Feb 27 01:45:16 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Feb 2011 00:45:16 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298767516.92.0.858721206638.issue11332@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, but acceptance tests do not need to not try to get higher test coverage. For instance, for testing disable() simply using it and making sure the outcome is as expected also works.

I can understand wanting to avoid some low-level whitebox testing, but I don't think that precludes getting better coverage results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sun Feb 27 04:20:33 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 27 Feb 2011 03:20:33 +0000
Subject: [issue11256] inspect.getcallargs raises TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298776833.3.0.497906398478.issue11256@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Confirmed under Python 2.7, 3.2 and 3.3. Patch looks good to me. Attached is a patch for 2.7.

----------
nosy: +Trundle
Added file: http://bugs.python.org/file20927/issue11256_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11256>
_______________________________________

From report at bugs.python.org  Sun Feb 27 04:22:08 2011
From: report at bugs.python.org (Dj Gilcrease)
Date: Sun, 27 Feb 2011 03:22:08 +0000
Subject: [issue968063] Add fileinput.islastline()
Message-ID: <1298776928.94.0.121803773064.issue968063@psf.upfronthosting.co.za>


Dj Gilcrease <digitalxero at gmail.com> added the comment:

Updated the patch and tests for py3.3

----------
keywords: +patch
nosy: +Digitalxero
Added file: http://bugs.python.org/file20928/cpython_rev68060.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue968063>
_______________________________________

From report at bugs.python.org  Sun Feb 27 04:36:26 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 27 Feb 2011 03:36:26 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1298777786.97.0.691020063502.issue7833@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Thinking more about this, I think the approach of this patch is more complex than necessary.  I think a better patch would be one which *unconditionally* removes the manifest from extension modules.  For maximum flexibility though, we should probably allow a hook so setup.py can specify the name of (or contents of) a manifest file to use when linking with the default being None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Feb 27 06:00:42 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 27 Feb 2011 05:00:42 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1298782842.59.0.756719222292.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The proposed patch was meant to be backwards compatible. Unconditionally removing the whole assembly/manifest from extensions could break extensions that have additional dependencies, such as MFC or Common Controls. PyQt4 extensions for example depend on Common Controls. 

Btw, there is a discussion at <http://psycopg.lighthouseapp.com/projects/62710/tickets/20> and <http://groups.google.com/group/modwsgi/browse_thread/thread/137f88ac6927df59> about the need to put the msvcr90 manifest back into the psycopg.pyd file in order to work properly under Apache's mod_wsgi, which is linked against msvcrt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Feb 27 06:22:45 2011
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 27 Feb 2011 05:22:45 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1298784165.48.0.207821998056.issue7833@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I'm wondering if, in practice, extensions which need a manifest can have the manifest being generated completely by the linker - ie, I expect that in most cases where something other than the CRT or MFC is needed in the manifest, the author will want to specify an explicit manifest file rather than one generated by the linker.

And worse, those extensions are going to be screwed anyway - the fact the manifest remains at all will mean they probably fail to load for reasons already discussed in this bug. IOW, not having a manifest at all is about the only way to ensure the module will be loaded correctly.

Re adding a manifest back in - I've struck the exact same problem with pywin32 - any DLLs which are "entry points" into Python need to have a manifest - eg, pythoncomxx and a few other pywin32 ones.  This left me with a dilemma for pythoncom - as it is both an "entry-point" (ie, COM loads that DLL) and a regular Python module, I simultaneously needed a manifest (to work when loaded by COM) and needed to *not* have one (to work when loaded by Python).  My solution has been to introduce another DLL with a manifest and have COM servers register using that.  This strategy seems to be working well in all my tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Feb 27 06:30:28 2011
From: report at bugs.python.org (Dj Gilcrease)
Date: Sun, 27 Feb 2011 05:30:28 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298784628.46.0.933571200525.issue10880@psf.upfronthosting.co.za>


Dj Gilcrease <digitalxero at gmail.com> added the comment:

Add a boolean format option to Py_BuildValue and Py_VaBuildValue

Also added some tests to test_capi that verifies Py_BuildValue is building the right type. I did not add tests for every possible type as it has lived this long without, but I did want to test my new code.

----------
keywords: +patch
nosy: +Digitalxero
Added file: http://bugs.python.org/file20929/issue10880_rev68064.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 07:28:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 27 Feb 2011 06:28:39 +0000
Subject: [issue11338] No list of Python hg repositories
In-Reply-To: <1298747627.22.0.769234647511.issue11338@psf.upfronthosting.co.za>
Message-ID: <1298788119.23.0.215855447089.issue11338@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Just for the record: at the moment, Python's source code isn't maintained in Mercurial at all, but in subversion. Therefore, there are no official repos - it's no surprise you didn't find any documentation what they were.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11338>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:04:21 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 27 Feb 2011 08:04:21 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298767516.92.0.858721206638.issue11332@psf.upfronthosting.co.za>
Message-ID: <131867.95274.qm@web25806.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> OK, but acceptance tests do not need to not try to get higher  test coverage. 
>For instance, for testing disable() simply using it and making  sure the outcome 
>is as expected also works.

> 
> I can understand wanting to  avoid some low-level whitebox testing, but I don't 
>think that precludes getting  better coverage  results.

Well then, it sounds like we're on the same page. I'm not arguing against better 
coverage, just against the low-level whitebox testing elements of Oliver's 
patch. He did welcome comments, after all :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:26:48 2011
From: report at bugs.python.org (blokeley)
Date: Sun, 27 Feb 2011 08:26:48 +0000
Subject: [issue11344] Add height argument to os.path.dirname()
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>


New submission from blokeley <blokeley at gmail.com>:

It is a common need to find the grandparent or great-grandparent (etc.) of a given directory, which results in this:

>>> from os.path import dirname
>>> mydir = dirname(dirname(dirname(path)))

Could a "height" parameter be added to os.path.dirname so it becomes:

>>> def dirname(path, height=1):

Then we could have usage like:

>>> path = '/ggparent/gparent/parent/myfile.txt'
>>> from os.path import dirname

>>> dirname(path)
/ggparent/gparent/parent

>>> dirname(path, 2)
/ggparent/gparent

>>> dirname(path, 3)
/ggparent

Perhaps we should throw ValueErrors for invalid height values:

>>> dirname(path, 10)
ValueError

>>> dirname(path, -1)
ValueError

Perhaps a height of 0 should do nothing:

>>> dirname(path, 0)
/ggparent/gparent/parent/myfile.txt

I can supply patches, unit tests and docs if you like.

----------
components: Library (Lib)
messages: 129616
nosy: blokeley
priority: normal
severity: normal
status: open
title: Add height argument to os.path.dirname()
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sun Feb 27 09:43:55 2011
From: report at bugs.python.org (Christoph Gohlke)
Date: Sun, 27 Feb 2011 08:43:55 +0000
Subject: [issue7833] Bdist_wininst installers fail to load extensions built
	with Issue4120 patch
In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za>
Message-ID: <1298796235.11.0.823488874257.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Actually, PyQt4 was not a good example since it is not build using distutils. Pywin32 and wxPython extensions are the only ones on my system specifying a dependency on Common Controls or MFC. No dependencies other than CRT, MFC, and Common Controls are specified in any assemblies of over 1000 pyd and dll files in my Python27 directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7833>
_______________________________________

From report at bugs.python.org  Sun Feb 27 10:53:25 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Feb 2011 09:53:25 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298800405.63.0.123023675802.issue10880@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This test is wrong::
   if (!PyBool_Check(test_var) && test_var == Py_False)
the second part is never executed.
   if (test_var != Py_False)
is enough to test the return value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 11:05:38 2011
From: report at bugs.python.org (Yuriy)
Date: Sun, 27 Feb 2011 10:05:38 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298801138.12.0.646643739004.issue10880@psf.upfronthosting.co.za>


Yuriy <irov13 at mail.ru> added the comment:

+    test_var = Py_BuildValue("?", 0);
+    if (PyBool_Check(test_var) && test_var == Py_True) {
+        PyErr_SetString(TestError, "Failed to Create boolean");
+        return NULL;
+    }
+    
+    test_var = Py_BuildValue("?", 1);
+    if (PyBool_Check(test_var) && test_var == Py_False) {
+        PyErr_SetString(TestError, "Failed to Create boolean");
+        return NULL;
+    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 11:09:13 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 27 Feb 2011 10:09:13 +0000
Subject: [issue11256] inspect.getcallargs raises TypeError on valid arguments
In-Reply-To: <1298203870.32.0.413262962206.issue11256@psf.upfronthosting.co.za>
Message-ID: <1298801353.49.0.385511671279.issue11256@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

I found another case, when this is a problem: if there are no **kwargs, but there are some keyword-only arguments:

>>> def f(*, a, b): pass
... 
>>> f(a=1, b=2)
>>> 
>>> getcallargs(f, a=1, b=2)
Traceback (most recent call last):
    ...
TypeError: f() takes no arguments (2 given)

The attached issue11256_3.diff patch also fixes this problem, and adds tests that would have detected this case.

----------
Added file: http://bugs.python.org/file20930/issue11256_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11256>
_______________________________________

From report at bugs.python.org  Sun Feb 27 11:16:45 2011
From: report at bugs.python.org (Yuriy)
Date: Sun, 27 Feb 2011 10:16:45 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298801805.41.0.0498645848245.issue10880@psf.upfronthosting.co.za>


Yuriy <irov13 at mail.ru> added the comment:

sorry ^_^

+    test_var = Py_BuildValue("?", 0);
+    if (!PyBool_Check(test_var) || test_var == Py_True) {
+        PyErr_SetString(TestError, "Failed to Create boolean");
+        return NULL;
+    }
+    
+    test_var = Py_BuildValue("?", 1);
+    if (!PyBool_Check(test_var) || test_var == Py_False) {
+        PyErr_SetString(TestError, "Failed to Create boolean");
+        return NULL;
+    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 14:05:26 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Feb 2011 13:05:26 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298811926.66.0.516973603812.issue11321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I can definitely confirm that one:

~/devel/py3k$ gcc -I/usr/local/include/python3.3m -o issue11321 issue11321.c -L/usr/local/lib/python3.3 -lpython3.3m -lm -lpthread -ldl -lutil -rdynamic
~/devel/py3k$ ./issue11321
START
Try import #0 ...SUCCESS
Try import #1 ...SUCCESS
Try import #2 ...SUCCESS
Try import #3 ...SUCCESS
Try import #4 ...SUCCESS
Try import #5 ...SUCCESS
Try import #6 ...SUCCESS
Try import #7 ...SUCCESS
Segmentation fault

I can also confirm that it isn't a regression w.r.t 3.1:

~/devel/py3k$ gcc -I/usr/include/python3.1 -o issue11321 issue11321.c -L/usr/lib/python3.1 -lpython3.1 -lm -lpthread -ldl -lutil -rdynamic
~/devel/py3k$ ./issue11321
START
Try import #0 ...SUCCESS
Try import #1 ...SUCCESS
Try import #2 ...SUCCESS
Try import #3 ...SUCCESS
Try import #4 ...SUCCESS
Try import #5 ...SUCCESS
Try import #6 ...SUCCESS
Try import #7 ...SUCCESS
Segmentation fault

It *is*, however, a regression from the 2.x line (where, presumably, cPickle simply never got reinitialised)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Sun Feb 27 14:17:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Feb 2011 13:17:57 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298812677.22.0.357439396739.issue11321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I haven't worked out where the error is happening yet, but the 13 allocated static variables and the complete lack of a module cleanup function aren't going to be helping matters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Sun Feb 27 14:43:36 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Feb 2011 13:43:36 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298814216.07.0.887426069736.issue11321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Here's a sample stack trace of it blowing up:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000479404 in type_dealloc (type=0x7ffff6a82f20) at Objects/typeobject.c:2523
2523        _PyObject_GC_UNTRACK(type);

(gdb) bt
#0  0x0000000000479404 in type_dealloc (type=0x7ffff6a82f20) at Objects/typeobject.c:2523
#1  0x0000000000465a2b in dict_dealloc (mp=0x8f61b0) at Objects/dictobject.c:1020
#2  0x00000000004e43c8 in _PyImport_FixupExtensionUnicode (mod=0x7ffff7f68ef0, 
    name=0x7fffffffcd40 "_pickle", filename=0x7ffff7f12570) at Python/import.c:611
#3  0x00000000004e7fcf in _PyImport_LoadDynamicModule (name=0x7fffffffcd40 "_pickle", 
    pathname=0x7fffffffbc70 "/usr/local/lib/python3.3/lib-dynload/_pickle.cpython-33m.so", 
    fp=<value optimised out>) at ./Python/importdl.c:85
#4  0x00000000004e5f79 in import_submodule (mod=0x796b20, subname=0x7fffffffcd40 "_pickle", 
    fullname=0x7fffffffcd40 "_pickle") at Python/import.c:2894
#5  0x00000000004e61ef in load_next (mod=0x796b20, altmod=<value optimised out>, 
    p_name=<value optimised out>, buf=0x7fffffffcd40 "_pickle", p_buflen=0x7fffffffcd38)
    at Python/import.c:2706
#6  0x00000000004e6931 in import_module_level (name=0x0, globals=0x922060, 
    locals=<value optimised out>, fromlist=0x796b20, level=<value optimised out>)
    at Python/import.c:2422
#7  0x00000000004e6e74 in PyImport_ImportModuleLevel (name=0x7ffff7e6c550 "_pickle", 
    globals=0x922060, locals=0x922060, fromlist=0x796b20, level=<value optimised out>)
    at Python/import.c:2474
#8  0x00000000004c642b in builtin___import__ (self=<value optimised out>, 
    args=<value optimised out>, kwds=<value optimised out>) at Python/bltinmodule.c:167
#9  0x000000000042c897 in PyObject_Call (func=0x7ffff7edf8c0, arg=0x8e79e0, kw=0xa2e79)
    at Objects/abstract.c:2149
#10 0x00000000004c6c73 in PyEval_CallObjectWithKeywords (func=0x7ffff7edf8c0, 
    arg=0x7ffff7e85ef0, kw=0xa2e79) at Python/ceval.c:3739
#11 0x00000000004ca6de in PyEval_EvalFrameEx (f=0xae4490, throwflag=<value optimised out>)
    at Python/ceval.c:2316
#12 0x00000000004cf343 in PyEval_EvalCodeEx (_co=0x7ffff7ea5690, globals=<value optimised out>, 
    locals=<value optimised out>, args=0x0, argcount=<value optimised out>, 
    kws=<value optimised out>, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3295
#13 0x00000000004cf5db in PyEval_EvalCode (co=0x7ffff6a82f20, globals=0x8e79e0, locals=0xa2e79)
    at Python/ceval.c:761
#14 0x0000000000419c7e in run_mod (command=<value optimised out>, flags=<value optimised out>)
    at Python/pythonrun.c:1769
#15 PyRun_StringFlags (command=<value optimised out>, flags=<value optimised out>)
    at Python/pythonrun.c:1703
#16 PyRun_SimpleStringFlags (command=<value optimised out>, flags=<value optimised out>)
    at Python/pythonrun.c:1276
#17 0x0000000000415c41 in main ()

So _pickle itself doesn't seem to be dying, but it is eventually leaving things in a bad state so that the *next* time around, the import machinery blows up. Note that switching to a different module (e.g. "_struct") eliminates the segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Sun Feb 27 14:57:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Feb 2011 13:57:06 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298815026.6.0.467825089812.issue11333@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I like the idea, and it seems to work as expected (i.e. an empty __slots__ doesn't conflict with inheritance from a C defined type or a type with non-empty __slots__).

However, __slots__ is one of the sections of the type machinery I'm least familiar with, so hopefully Guido will weigh in.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:03:37 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 27 Feb 2011 14:03:37 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298815417.28.0.317906800499.issue11321@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

It's because the _pickle module doesn't incref Pickler_Type and Unpickler_Type before calling `PyModule_AddObject()` (which steals a reference).

The attached patch fixes the issue.

----------
keywords: +patch
nosy: +Trundle
Added file: http://bugs.python.org/file20931/issue11321.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:25:30 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 27 Feb 2011 14:25:30 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298816730.43.0.785350780527.issue11258@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Humm. Would be great to have the `ldconfig -p` output of such a machine... I can't get ldconfig to recognize 64-bit libraries on my 32-bit machines, so I have no output to test against...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:35:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Feb 2011 14:35:07 +0000
Subject: [issue11329] PyEval_InitThreads() not safe before Py_Initialize()
In-Reply-To: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>
Message-ID: <1298817307.89.0.120732388202.issue11329@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11329>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:35:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Feb 2011 14:35:21 +0000
Subject: [issue11329] PyEval_InitThreads() not safe before Py_Initialize()
In-Reply-To: <1298713807.05.0.622715753988.issue11329@psf.upfronthosting.co.za>
Message-ID: <1298817321.38.0.348723617448.issue11329@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you write a patch for the documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11329>
_______________________________________

From report at bugs.python.org  Sun Feb 27 15:54:40 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 27 Feb 2011 14:54:40 +0000
Subject: [issue11345] Fix a link in library/json docs
In-Reply-To: <1298818480.03.0.395520184392.issue11345@psf.upfronthosting.co.za>
Message-ID: <1298818480.03.0.395520184392.issue11345@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

I guess this should be a link.

----------
assignee: docs at python
components: Documentation
files: fix-json-link.diff
keywords: patch
messages: 129629
nosy: docs at python, jonash
priority: normal
severity: normal
status: open
title: Fix a link in library/json docs
versions: Python 3.3
Added file: http://bugs.python.org/file20932/fix-json-link.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11345>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:00:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Feb 2011 15:00:46 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298818846.67.0.721769806084.issue11258@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an excerpt:

	libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.9) => /lib64/libc.so.6
	libc.so.6 (libc6, OS ABI: Linux 2.6.9) => /lib/libc.so.6

The "OS ABI" thing is not always there:

	libdrm.so.2 (libc6,x86-64) => /usr/lib64/libdrm.so.2
	libdrm.so.2 (libc6) => /usr/lib/libdrm.so.2

As you see, there are two of them with the same name but in a different path. If you return the absolute path, there is a 50% possibility that you are returning the wrong one ;)

There seem to be two key differences between the original implementation and yours:
- the orig impl matches the abi_type at the beginning of the parentheses, yours simply ignores the abi_type (that should have caught my eye, but that regex looked so much like magic that I didn't try to make sense of it :-))
- the orig impl returns the file name from the beginning of the matched line, yours returns the full path from the end of the line

I guess it should be doable to retain the speed benefit while implementing a matching algorithm closer to the original one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:03:13 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sun, 27 Feb 2011 15:03:13 +0000
Subject: [issue11346] Generator object should be mentioned in gc module
	document
In-Reply-To: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>
Message-ID: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto <ishimoto at gembook.org>:

In the gc.garbage of the library ref of gc module, 
  
  ... this list contains only objects with __del__() methods.

This is not true, since gc.garbage will contain generator object with try-finally block.

----------
assignee: docs at python
components: Documentation
messages: 129631
nosy: docs at python, ishimoto
priority: normal
severity: normal
status: open
title: Generator object should be mentioned in gc module document

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11346>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:04:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Feb 2011 15:04:27 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298819067.74.0.651704339505.issue11342@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does the attached patch fix the issue?

----------
assignee: tarek -> eric.araujo
components: +Distutils2
keywords: +patch
nosy: +alexis
versions: +3rd party, Python 2.7, Python 3.1, Python 3.3
Added file: http://bugs.python.org/file20933/distutils-files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:05:23 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Sun, 27 Feb 2011 15:05:23 +0000
Subject: [issue11314] Subprocess suffers 40% process creation overhead penalty
In-Reply-To: <1298674229.69.0.698157336902.issue11314@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=k6ZQ=zk2vTZQNF5sp=dsLLHrTQK6dbq3UOphQ@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

> Aaron Sherman <ajs at ajs.com> added the comment:
>
> "That's why I asked for absolute numbers for the overhead difference."
>
> Did you not follow the link in my first post? I got pretty detailed, there.
>

By the way, strace has a '-T' flag that can be used to measure the
time spent in syscalls (but for a mmap/mremap/munmap it won't be
significant).

> However, I do think that doing the performance testing before deprecating
> the previous interface would have been a good idea...
>

Once again: subprocess.Popen is actually faster than os.pipe to create
a subprocess. Just don't pass shell=True. Unless you're spawning shell
scripts, but in that case subprocess' overhead is definitely not
biggest problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11314>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:07:17 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Feb 2011 15:07:17 +0000
Subject: [issue11345] Fix a link in library/json docs
In-Reply-To: <1298818480.03.0.395520184392.issue11345@psf.upfronthosting.co.za>
Message-ID: <1298819237.3.0.380632873275.issue11345@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r88668

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11345>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:47:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Feb 2011 15:47:29 +0000
Subject: [issue11344] Add height argument to os.path.dirname()
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1298821649.91.0.434853482171.issue11344@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm -1 on this feature request.  I think it is an unnecessary complication of the API, especially since dirname corresponds to the unix shell 'dirname' command, which doesn't have such a feature.  If you need this feature in a particular application, it is easy to write a function to provide it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sun Feb 27 16:51:50 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Feb 2011 15:51:50 +0000
Subject: [issue11344] Add height argument to os.path.dirname()
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1298821910.34.0.0979946181083.issue11344@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, on the other hand, it *is* a common need.
(and I don't think mimicking the shell is a design principle for Python)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:04:58 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 27 Feb 2011 16:04:58 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1298822698.76.0.0963040316471.issue4600@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:12:19 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 27 Feb 2011 16:12:19 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298823139.37.0.946203889612.issue11342@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

@?ric: You should probably strip the colour from your diff :-)

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:14:25 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 27 Feb 2011 16:14:25 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1298823265.78.0.986050341318.issue4600@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:14:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Feb 2011 16:14:27 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298823267.76.0.735295663971.issue11342@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file20933/distutils-files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sun Feb 27 17:14:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Feb 2011 16:14:41 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298823281.81.0.592326608523.issue11342@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file20934/distutils-files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:10:10 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 27 Feb 2011 17:10:10 +0000
Subject: [issue11258] ctypes: Speed up find_library() on Linux by 500%
In-Reply-To: <1298217839.35.0.775539629492.issue11258@psf.upfronthosting.co.za>
Message-ID: <1298826610.31.0.984617700922.issue11258@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

> the orig impl matches the abi_type at the beginning of the parentheses,
> yours simply ignores the abi_type (that should have caught my eye, but that
> regex looked so much like magic that I didn't try to make sense of it :-))

Same here. :)

The version I attached seems to work for me. It's some kind of compromise -- basically it's the original regex but with the unneccessary, performance-decreasing cruft stripped away.

btw, "Jonas H." is perfectly fine - I don't care about being honored, I just want to `import uuid` without waiting forever. :-)

----------
Added file: http://bugs.python.org/file20935/faster-find-library1-py3k-with-escaped-name-try2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11258>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:21:09 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 17:21:09 +0000
Subject: [issue11282] 3.3 unittest document not kept consist with code
In-Reply-To: <1298354999.37.0.375525915954.issue11282@psf.upfronthosting.co.za>
Message-ID: <1298827269.26.0.893178172203.issue11282@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11282>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:37:57 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 27 Feb 2011 17:37:57 +0000
Subject: [issue11140] threading.Lock().release() raises _thread.error,
	not RuntimeError
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1298828277.15.0.257413757478.issue11140@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Test for releasing unacquired lock and aliasing exception.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file20936/11140.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11140>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:45:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Feb 2011 17:45:01 +0000
Subject: [issue11344] Add height argument to os.path.dirname()
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1298828701.82.0.0181279239621.issue11344@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, it isn't a design principle.  My point was that unix hasn't found it useful to add a level option to the dirname API.

I don't know that I personally have ever had occasion to peel off more than one directory level without also wanting to do something with the intermediate results, so perhaps I am not a good judge of how useful this would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:57:06 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Feb 2011 17:57:06 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298829426.35.0.849795009938.issue11333@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think the idea is reasonable. (I haven't checked the patch.)

----------
assignee: gvanrossum -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 18:58:39 2011
From: report at bugs.python.org (Paul Moore)
Date: Sun, 27 Feb 2011 17:58:39 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1298743098.29.0.77598708216.issue9931@psf.upfronthosting.co.za>
Message-ID: <AANLkTimbW7eoC9wzJzhP=niOkzURY1MhyYF0HYer4rrY@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

Seems to be correctly skipping the test now - failures are because of
other issues (a load more hg builds means that the buildslave is
getting a bit tight on space...)

This change looks fine. Thanks!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:00:32 2011
From: report at bugs.python.org (Jonas H.)
Date: Sun, 27 Feb 2011 18:00:32 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1298829632.48.0.301800168145.issue4600@psf.upfronthosting.co.za>


Jonas H. <jonas at lophus.org> added the comment:

Here comes a patch, changing the behaviour to:

./python -q
>>> class C:
...   pass
... 
>>> (1).__class__ = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ must be set to a class defined by a class statement, not 'int' object
>>> (1).__class__ = object
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: class__ must be set to a class defined by a class statement, not 'object'
>>> (1).__class__ = C
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: only for instances of classes defined by class statements

----------
keywords: +patch
nosy: +jonash
Added file: http://bugs.python.org/file20937/4600.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:22:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Feb 2011 18:22:10 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1298830930.81.0.469707378219.issue9931@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, great !
The hg builders are temporary - or, rather, the SVN builders will get removed once the transition is over.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9931>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:23:49 2011
From: report at bugs.python.org (Dj Gilcrease)
Date: Sun, 27 Feb 2011 18:23:49 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298831029.52.0.06160293452.issue10880@psf.upfronthosting.co.za>


Dj Gilcrease <digitalxero at gmail.com> added the comment:

Correct the tests. They passed before but had a logic flaw that caused them to never test that the correct boolean value was being returned.

----------
Added file: http://bugs.python.org/file20938/issue10880_68064.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:23:53 2011
From: report at bugs.python.org (Dj Gilcrease)
Date: Sun, 27 Feb 2011 18:23:53 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1298831033.75.0.790431060302.issue10880@psf.upfronthosting.co.za>


Changes by Dj Gilcrease <digitalxero at gmail.com>:


Removed file: http://bugs.python.org/file20929/issue10880_rev68064.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:25:43 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Feb 2011 18:25:43 +0000
Subject: [issue4600] __class__ assignment: new-style? heap? == confusing
In-Reply-To: <1228771522.72.0.688992536212.issue4600@psf.upfronthosting.co.za>
Message-ID: <1298831143.53.0.0710531390524.issue4600@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is not really accurate:

>>> class x(int): pass
... 
>>> class y(object): pass
... 
>>> x().__class__ = y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: 'x' object layout differs from 'y'
>>> y().__class__ = x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: 'y' object layout differs from 'x'

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4600>
_______________________________________

From report at bugs.python.org  Sun Feb 27 19:58:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Feb 2011 18:58:58 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1298833138.36.0.0123208666019.issue8271@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch turned out to be less trivial than I initially thought.

The current algorithm checks for invalid continuation bytes in 4 places:
1) before the switch/case statement in Objects/unicodeobject.c when it checks if there are enough bytes in the string (e.g. if the current byte is a start byte of a 4-bytes sequence and there are only 2 more bytes in the string, the sequence is invalid);
2) in the "case 2" of the switch, where it's checked if the second byte is a valid continuation byte;
3) in the "case 3" of the switch, where it's checked if the second and third bytes are valid continuation bytes, including additional invalid cases for the second bytes;
3) in the "case 4" of the switch, where it's checked if the second, third, and fourth bytes are valid continuation bytes, including additional invalid cases for the second bytes;

The correct algorithm should determine the maximum valid subpart of the sequence determining the position of the first invalid continuation byte. Continuation bytes are all in range 80..BF except for the second  byte of 3-bytes sequences that start with E0 or ED and second byte of 4-bytes sequences that start with F0 or F4 (3rd and 4th continuation bytes are always in range 80..BF).
This means that the above 4 cases should be changed in this way:
1) if there aren't enough bytes left to complete the sequence check for valid continuation bytes considering the special cases for the second bytes (E0, ED, F0, F4) instead of using the naive algorithm that checks only for continuation bytes in range 80..BF;
2) the "case 2" is fine as is, because the second byte is always in range 80..BF;
3) the "case 3" should check (pseudocode):
  if (second_byte_is_not_valid) max_subpart_len = 1
  else if (third_byte not in 80..BF) max_subpart_len = 2
  else  # the sequence is valid
the "second_byte_is_not_valid" part should consider the two special cases for E0 and ED.
4) the "case 4" should check (pseudocode):
  if (second_byte_is_not_valid) max_subpart_len = 1
  else if (third_byte not in 80..BF) max_subpart_len = 2
  else if (fourth_byte not in 80..BF) max_subpart_len = 3
  else  # the sequence is valid
here the "second_byte_is_not_valid" part should consider the two special cases for F0 and E4.

In order to avoid duplication of code I was thinking to add 2 macros (something like IS_VALID_3_SEQ_2ND_BYTE, IS_VALID_4_SEQ_2ND_BYTE) that will be used in the cases 1) and 3), and 1) and 4) respectively.
The change shouldn't affect the decoding speed, but it will increase the lines of code and complexity of the function.
Is this OK?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Sun Feb 27 20:42:21 2011
From: report at bugs.python.org (Oliver Drake)
Date: Sun, 27 Feb 2011 19:42:21 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298835741.79.0.028266242992.issue11332@psf.upfronthosting.co.za>


Oliver Drake <obdrake11 at gmail.com> added the comment:

Thanks for the comments and prompt response :) I think I misunderstood the nature and level of these unit tests. I will fix the specific issues you mentioned, and either cut or modify the less useful/too low level tests (e.g. disable). In general I will change my approach to be more high level. I will steer away from testing the implementation line by line, but I believe there should be unit tests that enforce the API that is published to the user - i.e. one unit test for every class, method and function, testing inputs, outputs, exception handling and general behavior. So if a developer changes the API or the general behavior of a function he/she should have to change the documentation and the appropriate unit test - or do we want to avoid this type of testing completely?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:26:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 20:26:28 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

1. libpython3.so has soname "llibpython3.so" due to needless "l" in "-Wl,-hl$@".
2. libpython3.so is not linked against libpython$(LDVERSION).so when -Wl,--as-needed flag is used. -Wl,--as-needed flag is used by default in Gentoo due to major benefits.
>From `info ld`:
`--as-needed'
`--no-as-needed'
     This option affects ELF DT_NEEDED tags for dynamic libraries
     mentioned on the command line after the `--as-needed' option.
     Normally the linker will add a DT_NEEDED tag for each dynamic
     library mentioned on the command line, regardless of whether the
     library is actually needed or not.  `--as-needed' causes a
     DT_NEEDED tag to only be emitted for a library that satisfies an
     undefined symbol reference from a regular object file or, if the
     library is not found in the DT_NEEDED lists of other libraries
     linked up to that point, an undefined symbol reference from
     another dynamic library.  `--no-as-needed' restores the default
     behaviour.

I'm attaching the patch.

----------
components: Build
files: libpython3.so.patch
keywords: patch
messages: 129649
nosy: Arfrever, loewis
priority: normal
severity: normal
status: open
title: libpython3.so: Broken soname and linking
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20939/libpython3.so.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:28:48 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Feb 2011 20:28:48 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298838528.7.0.925788249595.issue11347@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:33:39 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Feb 2011 20:33:39 +0000
Subject: [issue11332] Increase logging/__init__.py coverage to 97%
In-Reply-To: <1298719084.44.0.947118780186.issue11332@psf.upfronthosting.co.za>
Message-ID: <1298838819.06.0.55926228494.issue11332@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Testing the documented API is definitely wanted, Oliver. Any change in behaviour needs to be detected to ensure there is not backwards-compatibility regressions without it being intentional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11332>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:38:33 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Feb 2011 20:38:33 +0000
Subject: [issue11340] test_distutils fails
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1298839113.44.0.371477812626.issue11340@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Can you provide the test's failing report and traceback?

----------
nosy: +brett.cannon
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11340>
_______________________________________

From report at bugs.python.org  Sun Feb 27 21:52:38 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 20:52:38 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298839958.2.0.606859505036.issue11347@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Regardless of this patch, such a libpython3.so regular file cannot exist in Gentoo. Gentoo package manager disallows installation, when it detects file collisions. If I rename libpython3.so of Python 3.2 to libpython3-3.2.so and libpython3.so of Python 3.3 to libpython3-3.3.so, then ldconfig will create libpython3.so symlink pointing to potentially wrong target library. This problem can be avoided by removing soname from libpython3.so, so whole -Wl,-h${soname} could be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:05:24 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Feb 2011 21:05:24 +0000
Subject: [issue11340] test_distutils fails
In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za>
Message-ID: <1298840724.57.0.600453192483.issue11340@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

My mistake; missed the attachment.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11340>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:20:21 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 21:20:21 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

$ nice -n20 python3.3 -m test.test_os
...
test_set_get_priority (__main__.ProgramPriorityTests) ... FAIL

======================================================================
FAIL: test_set_get_priority (__main__.ProgramPriorityTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.3/test/test_os.py", line 1280, in test_set_get_priority
    self.assertEqual(os.getpriority(os.PRIO_PROCESS, os.getpid()), base + 1)
AssertionError: 19 != 20

----------
components: Tests
messages: 129654
nosy: Arfrever, giampaolo.rodola
priority: normal
severity: normal
status: open
title: test_os: test_set_get_priority() fails when high niceness is set
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:27:23 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 27 Feb 2011 21:27:23 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298842043.33.0.148521205288.issue11348@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Of course the test fails: a process can't have a nice value higher than a certain limit, which I think can vary depending on the UNIX variant in use. The fix is not to use "nice -n20".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:37:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:37:07 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298842627.36.0.976242542567.issue11339@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This would be an important fix-up if we could find some way to implement it.

The basic problem is that the class object is defined after the class definitions have been made, so the target of the Graph reference isn't known when the method definitions are being compiled.

One approach to solving this problem is to use a deferred/resolved pattern (creating a valid reference to Graph that is visible during method compilation, but gets filled-in with the other methods afterwards).

I haven't thought this through completely but think it could be done if we let the compiler write to the class dictionary (this is normally off-limits and protected by a dict_proxy).  If we let the system punch a hole in the proxy, it is possible to resolve deferred class definitions.

Here's a concept sketch:

class Prepared(type):
    'Preload the class with a reference to itself'
    @classmethod
    def __prepare__(mcl, name, bases):
        return {name: type(name, bases, {})}
    def __new__(mcl, name, bases, mapping):
        global deferred_class
        tmpcls = super().__new__(mcl, name, bases, mapping)
        deferred_class = mapping[name]
        deferred_class.__dict__.update(tmpcls.__dict__)  # XXX need writeable dict_proxy
        return deferred_class

class Graph(metaclass=Prepared):
    def reverse(self) -> Graph:
        ...

----------
nosy: +arigo, rhettinger, stutzbach
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:37:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:37:36 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298842656.2.0.361370289359.issue11339@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg129656

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:37:53 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:37:53 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298842673.94.0.0386048546407.issue11339@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This would be an important fix-up if we could find some way to implement it.

The basic problem is that the class object is defined after the class definitions have been made, so the target of the Graph reference isn't known when the method definitions are being compiled.

One approach to solving this problem is to use a deferred/resolved pattern (creating a valid reference to Graph that is visible during method compilation, but gets filled-in with the other methods afterwards).

I haven't thought this through completely but think it could be done if we let the compiler write to the class dictionary (this is normally off-limits and protected by a dict_proxy).  If we let the system punch a hole in the proxy, it is possible to resolve deferred class definitions.

Here's a concept sketch:

class Prepared(type):
    'Preload the class with a reference to itself'
    @classmethod
    def __prepare__(mcl, name, bases):
        return {name: type(name, bases, {})}
    def __new__(mcl, name, bases, mapping):
        tmpcls = super().__new__(mcl, name, bases, mapping)
        deferred_class = mapping[name]
        deferred_class.__dict__.update(tmpcls.__dict__)  # XXX need writeable dict_proxy
        return deferred_class

class Graph(metaclass=Prepared):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:39:54 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 27 Feb 2011 21:39:54 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298842794.02.0.0430497717422.issue11348@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I actually wanted to use 'nice -n19 python3.3 -m test.test_os', which also fails.
Test suite of Python can be run be a package manager, which automatically sets high niceness.
If niceness is high, then maybe this test could try to decrease it instead of increasing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:42:27 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:42:27 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298842947.13.0.739253094281.issue11339@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg129657

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:42:39 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:42:39 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298842959.81.0.931750765114.issue11339@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

class Prepared(type):
    'Preload the class with a reference to itself'

    @classmethod
    def __prepare__(mcl, name, bases):
        return {name: type(name, bases, {})}

    def __new__(mcl, name, bases, mapping):
        tmpcls = super().__new__(mcl, name, bases, mapping)
        deferred_class = mapping[name]
        deferred_class.__dict__.update(tmpcls.__dict__)  # XXX need writeable dict_proxy
        return deferred_class

class Graph(metaclass=Prepared):
    def reverse(self) -> Graph:
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:43:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:43:31 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298843011.47.0.285057947954.issue11339@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg129659

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:44:15 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 21:44:15 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298843055.51.0.144063338717.issue11339@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This would be an important fix-up if we could find some way to implement it.

The basic problem is that the class object is defined after the class definitions have been made, so the target of the Graph reference isn't known when the method definitions are being compiled.

One approach to solving this problem is to use a deferred/resolved pattern (creating a valid reference to Graph that is visible during method compilation, but gets filled-in with the other methods afterwards).

I haven't thought this through completely but think it could be done if we let the compiler write to the class dictionary (this is normally off-limits and protected by a dict_proxy).  If we let the system punch a hole in the proxy, it is possible to resolve deferred class definitions.


class Prepared(type):
    'Preload the class with a reference to itself'

    @classmethod
    def __prepare__(mcl, name, bases):
        return {name: type(name, bases, {})}

    def __new__(mcl, name, bases, mapping):
        tmpcls = super().__new__(mcl, name, bases, mapping)
        deferred_class = mapping[name]
        deferred_class.__dict__.update(tmpcls.__dict__)  # XXX need writeable dict_proxy
        return deferred_class

class Graph(metaclass=Prepared):
    def reverse(self) -> Graph:
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:50:02 2011
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 27 Feb 2011 21:50:02 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298843402.2.0.678862512349.issue11339@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:53:22 2011
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 27 Feb 2011 21:53:22 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298843602.35.0.603726023538.issue11339@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Sun Feb 27 22:55:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Feb 2011 21:55:00 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298843700.94.0.700786666576.issue11348@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:00:07 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 22:00:07 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298844007.77.0.720310884136.issue11333@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It looks like everyone is in favor of the change.  I'll apply the patch after adding some comments and tests.

----------
assignee: ncoghlan -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:00:10 2011
From: report at bugs.python.org (Boris FELD)
Date: Sun, 27 Feb 2011 22:00:10 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1298844010.03.0.226304532288.issue10154@psf.upfronthosting.co.za>


Boris FELD <lothiraldan at gmail.com> added the comment:

Bug confirmed on python2.5+ and python3.2-.

If it works with the dash, is agree with the Marc-Andre solution.

----------
nosy: +Boris.FELD
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:24:21 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 27 Feb 2011 22:24:21 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1298845461.17.0.876887137728.issue5979@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

But this is exactly how strptime in C. Consider this:

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){
    
    char buf[255];
    struct tm tm;
    
    memset(&tm, 0, sizeof(tm));
    strptime("123", "%m%d", &tm);
    strftime(buf, sizeof(buf), "%d %b %Y %H:%M", &tm);
    printf("%s\n", buf);
    
    return 0;
    
}

This produces output:

03 Dec 1900 00:00


Shouldn't it stay consistent with how C function works?

----------
nosy: +gruszczy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5979>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:58:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 22:58:12 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298847492.88.0.824099405257.issue11333@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Until and unless this gets fixed, perhaps we should document some sort of workaround.  One possibility is attached.

----------
Added file: http://bugs.python.org/file20940/annotations_workaround.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:58:34 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 22:58:34 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298847514.68.0.45689485205.issue11333@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg129664

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:58:43 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 22:58:43 +0000
Subject: [issue11333] Add empty __slots__ to collections.abc abstract base
	classes
In-Reply-To: <1298723074.18.0.581998347487.issue11333@psf.upfronthosting.co.za>
Message-ID: <1298847523.03.0.40997639155.issue11333@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


Removed file: http://bugs.python.org/file20940/annotations_workaround.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11333>
_______________________________________

From report at bugs.python.org  Sun Feb 27 23:59:31 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Feb 2011 22:59:31 +0000
Subject: [issue11339] annotation for class being defined
In-Reply-To: <1298751820.01.0.369994267539.issue11339@psf.upfronthosting.co.za>
Message-ID: <1298847571.25.0.935370632746.issue11339@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Until and unless this gets fixed, perhaps we should document some sort of workaround.  One possibility is attached.

----------
Added file: http://bugs.python.org/file20941/annotations_workaround.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11339>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:02:02 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 27 Feb 2011 23:02:02 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1298847722.93.0.0643480219404.issue8933@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Here is a simple patch, that sets metadata version in PKG-INFO to 1.1, if finds classifier or download_url parametres in setup. If it's any good, I'll try to write a test. If not, I'll be happy to get some advice on how to provide a better one.

----------
keywords: +patch
nosy: +gruszczy
Added file: http://bugs.python.org/file20942/8933.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:19:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 27 Feb 2011 23:19:11 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1298848751.22.0.114137562981.issue8933@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your help.  Tests would be very much appreciated; we don?t strictly follow the test-before-code method, but in this case it?s the best method to make sure we comply with the PEP: I can review the test against the PEP, then check if the unpatched code fails, apply a patch and check that it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8933>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:28:45 2011
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sun, 27 Feb 2011 23:28:45 +0000
Subject: [issue11346] Generator object should be mentioned in gc module
	document
In-Reply-To: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>
Message-ID: <1298849325.08.0.830105850756.issue11346@psf.upfronthosting.co.za>


Atsuo Ishimoto <ishimoto at gembook.org> added the comment:

Oh, Not only try-finally block, generators contains try-except or with block will be added to gc.garbage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11346>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:34:17 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Feb 2011 23:34:17 +0000
Subject: [issue9197] Crash when importing an extension after Py_Initialize,
	Py_Finalize and Py_Initialize
In-Reply-To: <1278579237.82.0.673928899274.issue9197@psf.upfronthosting.co.za>
Message-ID: <1298849657.1.0.0376507984551.issue9197@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does the patch for issue11321 fix this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9197>
_______________________________________

From report at bugs.python.org  Mon Feb 28 00:34:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 27 Feb 2011 23:34:27 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298849667.31.0.299255354896.issue11321@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good. It may also fix issue9197, which fails in a similar fashion

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:20:41 2011
From: report at bugs.python.org (LW)
Date: Mon, 28 Feb 2011 00:20:41 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298852441.06.0.940328496229.issue11342@psf.upfronthosting.co.za>


LW <cjejuni2000 at yahoo.com> added the comment:

hi eric: thanks for the reply. here is what i'm getting from 'patch --dry-run' command:

les at Liquid:~/Desktop$ patch -i ~/Desktop/distutils_files.diff -d ~/Downloads/Python-3.2/Lib/distutils --dry-run --backup
patching file bdist_wininst.py
Hunk #1 FAILED at 245.
1 out of 1 hunk FAILED -- saving rejects to file bdist_wininst.py.rej
patching file bdist_rpm.py
Hunk #1 FAILED at 511.
1 out of 1 hunk FAILED -- saving rejects to file bdist_rpm.py.rej
patching file upload.py
Hunk #1 FAILED at 124.
1 out of 1 hunk FAILED -- saving rejects to file upload.py.rej
patching file sdist.py
Hunk #1 FAILED at 294.
Hunk #2 FAILED at 359.
2 out of 2 hunks FAILED -- saving rejects to file sdist.py.rej
patching file sysconfig.py
les at Liquid:~/Desktop$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:22:21 2011
From: report at bugs.python.org (Hoyt Koepke)
Date: Mon, 28 Feb 2011 00:22:21 +0000
Subject: [issue11275] Linking to gcc's gomp causes crash later.
In-Reply-To: <1298310879.67.0.760994081627.issue11275@psf.upfronthosting.co.za>
Message-ID: <1298852541.72.0.54970244427.issue11275@psf.upfronthosting.co.za>


Hoyt Koepke <hoytak at gmail.com> added the comment:

Okay, finally got to test this on a system with python 2.7.1+ (development branch, r88606, and indeed, the same crash occurs.  This one was compiled from scratch with gcc 4.5.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11275>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:23:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Feb 2011 00:23:10 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298852590.25.0.86400220269.issue11342@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you test with a checkout of the py3k branch?  http://docs.python.org/devguide/setup#checking-out-the-code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Mon Feb 28 01:24:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 00:24:25 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298852665.67.0.366481441492.issue11321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While Andreas's patch does indeed prevent the crash, there is something more going on here.

I modified his patch to print out the reference counts immediately after the new INCREF commands.

With the INCREF commands commented out, it looks like this:

~/devel/py3k$ ./issue113213.3
START
Try import #0 ...Initialising _pickle
Pickler type references: 10
Unpickler type references: 8
Module initialised
SUCCESS
Try import #1 ...Initialising _pickle
Pickler type references: 10
Unpickler type references: 8
Module initialised
SUCCESS
Try import #2 ...Initialising _pickle
Pickler type references: 9
Unpickler type references: 7
Module initialised
SUCCESS
Try import #3 ...Initialising _pickle
Pickler type references: 8
Unpickler type references: 6
Module initialised
SUCCESS
Try import #4 ...Initialising _pickle
Pickler type references: 7
Unpickler type references: 5
Module initialised
SUCCESS
Try import #5 ...Initialising _pickle
Pickler type references: 6
Unpickler type references: 4
Module initialised
SUCCESS
Try import #6 ...Initialising _pickle
Pickler type references: 5
Unpickler type references: 3
Module initialised
SUCCESS
Try import #7 ...Initialising _pickle
Pickler type references: 4
Unpickler type references: 2
Module initialised
SUCCESS
Try import #8 ...Initialising _pickle
Pickler type references: 3
Unpickler type references: 1
Module initialised
Segmentation fault

Note that it does the right thing the first time Py_Finalize is called, but the reference counts start going down after that.

When the INCREF is included, the count goes up initially and then levels out.

So I believe the simple patch is just masking the problem instead of fixing it. The correct answer is to follow the documentation and implement the module finalisation protocol for _pickle (i.e. move all the static globals into the module struct and implement module traversal and finalisation functions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:05:34 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 28 Feb 2011 01:05:34 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298855134.63.0.390210020396.issue11321@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

That initial increase you can see happens because the module's dict is copied in `_PyImport_FixupExtensionUnicode()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:15:24 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 01:15:24 +0000
Subject: [issue9197] Crash when importing an extension after Py_Initialize,
	Py_Finalize and Py_Initialize
In-Reply-To: <1278579237.82.0.673928899274.issue9197@psf.upfronthosting.co.za>
Message-ID: <1298855724.37.0.145814358438.issue9197@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Merging this into issue11321 since that relates to the same underlying problem and includes a simpler test case.

----------
nosy: +ncoghlan
resolution:  -> duplicate
status: open -> closed
superseder:  -> 9th import of module _pickle always crashes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9197>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:29:11 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 01:29:11 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As discussed in issue11321, _pickle allocates a number of module level objects, but doesn't use the appropriate PEP 3121 mechanisms to manage their lifecycle.

It should be updated to follow the relevant development guidelines in the documentation.

----------
components: Extension Modules
messages: 129677
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: _pickle should implement the module finalisation protocol
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11349>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:29:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 01:29:14 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298856554.13.0.759983716787.issue11347@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:30:29 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 28 Feb 2011 01:30:29 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298856629.25.0.0213659643603.issue11349@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11349>
_______________________________________

From report at bugs.python.org  Mon Feb 28 02:31:20 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 01:31:20 +0000
Subject: [issue11321] 9th import of module _pickle always crashes
In-Reply-To: <1298649081.58.0.623637694114.issue11321@psf.upfronthosting.co.za>
Message-ID: <1298856680.19.0.320187425576.issue11321@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Looking at the example of _struct.c, I'll withdraw my objection to the patch. The segfault is due to the attempt to destroy a statically allocated type object, and the only viable solution to that is to ensure the reference count never drops to 0, even during Py_Finalize.

I also created issue11349 to cover the fact that _pickle really shouldn't be stashing things in static globals now that a better alternative is available.

----------
nosy: +loewis
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11321>
_______________________________________

From report at bugs.python.org  Mon Feb 28 04:09:51 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Feb 2011 03:09:51 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298862591.43.0.800714920753.issue11349@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Unfortunately "proper" module finalization is an invitation to more segfaults because modules can be finalized before objects in them are, resulting in segfaults when its attempted to access modules.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11349>
_______________________________________

From orsenthil at gmail.com  Mon Feb 28 04:41:56 2011
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Mon, 28 Feb 2011 11:41:56 +0800
Subject: [issue11283] incorrect pattern in the re module docs for
	conditional regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
References: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
	<1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <20110228034156.GA2521@kevin>

On Tue, Feb 22, 2011 at 08:48:20AM +0000, wesley chun wrote:
> 
> The fix is to add the end char '$' to the regex to get all 4 working:

Better would be a regex for white-space '\s' which would achieve the
same purpose plus it would satisfy the other requirement for using it
with search and can do the search in-middle of the document too.

From report at bugs.python.org  Mon Feb 28 04:42:15 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Feb 2011 03:42:15 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <20110228034156.GA2521@kevin>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Tue, Feb 22, 2011 at 08:48:20AM +0000, wesley chun wrote:
> 
> The fix is to add the end char '$' to the regex to get all 4 working:

Better would be a regex for white-space '\s' which would achieve the
same purpose plus it would satisfy the other requirement for using it
with search and can do the search in-middle of the document too.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Mon Feb 28 05:01:44 2011
From: report at bugs.python.org (LW)
Date: Mon, 28 Feb 2011 04:01:44 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298865704.15.0.909929934393.issue11342@psf.upfronthosting.co.za>


LW <cjejuni2000 at yahoo.com> added the comment:

seemed no errors. end of check attach:

U   py3k
Checked out revision 88674.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:31:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Feb 2011 06:31:37 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298874697.36.0.227990054722.issue11347@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Having the soname be libpython3 is the whole point of the library, it serves no other reason.

It is intentional that there are file collisions with that file, and either the local admin or the distributor must make an explicit choice which libpython3 should be installed; it should be the one that corresponds to /usr/bin/python (if you install it into /usr/lib).

As for file20939: it's GNU-ld-specific, so it likely breaks if the linker is not GNU ld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 07:41:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Feb 2011 06:41:39 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298875299.39.0.389181240848.issue11347@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The -hl -> -h part seems correct though.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 08:39:17 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 28 Feb 2011 07:39:17 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298878757.24.0.922427938541.issue11348@psf.upfronthosting.co.za>


Charles-Francois Natali <neologix at free.fr> added the comment:

> If niceness is high, then maybe this test could try to decrease it instead of increasing.

You must be root or have CAP_SYS_NICE to do that.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:18:07 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Feb 2011 09:18:07 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1298833138.36.0.0123208666019.issue8271@psf.upfronthosting.co.za>
Message-ID: <4D6B684D.3090804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The patch turned out to be less trivial than I initially thought.
> 
> The current algorithm checks for invalid continuation bytes in 4 places:
> 1) before the switch/case statement in Objects/unicodeobject.c when it checks if there are enough bytes in the string (e.g. if the current byte is a start byte of a 4-bytes sequence and there are only 2 more bytes in the string, the sequence is invalid);
> 2) in the "case 2" of the switch, where it's checked if the second byte is a valid continuation byte;
> 3) in the "case 3" of the switch, where it's checked if the second and third bytes are valid continuation bytes, including additional invalid cases for the second bytes;
> 3) in the "case 4" of the switch, where it's checked if the second, third, and fourth bytes are valid continuation bytes, including additional invalid cases for the second bytes;
> 
> The correct algorithm should determine the maximum valid subpart of the sequence determining the position of the first invalid continuation byte. Continuation bytes are all in range 80..BF except for the second  byte of 3-bytes sequences that start with E0 or ED and second byte of 4-bytes sequences that start with F0 or F4 (3rd and 4th continuation bytes are always in range 80..BF).
> This means that the above 4 cases should be changed in this way:
> 1) if there aren't enough bytes left to complete the sequence check for valid continuation bytes considering the special cases for the second bytes (E0, ED, F0, F4) instead of using the naive algorithm that checks only for continuation bytes in range 80..BF;
> 2) the "case 2" is fine as is, because the second byte is always in range 80..BF;
> 3) the "case 3" should check (pseudocode):
>   if (second_byte_is_not_valid) max_subpart_len = 1
>   else if (third_byte not in 80..BF) max_subpart_len = 2
>   else  # the sequence is valid
> the "second_byte_is_not_valid" part should consider the two special cases for E0 and ED.
> 4) the "case 4" should check (pseudocode):
>   if (second_byte_is_not_valid) max_subpart_len = 1
>   else if (third_byte not in 80..BF) max_subpart_len = 2
>   else if (fourth_byte not in 80..BF) max_subpart_len = 3
>   else  # the sequence is valid
> here the "second_byte_is_not_valid" part should consider the two special cases for F0 and E4.
> 
> In order to avoid duplication of code I was thinking to add 2 macros (something like IS_VALID_3_SEQ_2ND_BYTE, IS_VALID_4_SEQ_2ND_BYTE) that will be used in the cases 1) and 3), and 1) and 4) respectively.
> The change shouldn't affect the decoding speed, but it will increase the lines of code and complexity of the function.
> Is this OK?

Sure.

It would be great if you could time the difference in
performance. In tight loops like the codec ones, small changes
in the way you write things can often make a big difference.

Please also include a Misc/NEWS entry to point to the change
and possibly consequences for existing code relying on the
previous behavior.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
title: str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0 -> str.decode('utf8',	'replace') -- conformance with Unicode 5.2.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8271>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:31:06 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Feb 2011 09:31:06 +0000
Subject: [issue11283] incorrect pattern in the re module docs for conditional
	regex
In-Reply-To: <1298364500.67.0.815268640848.issue11283@psf.upfronthosting.co.za>
Message-ID: <1298885466.88.0.42994658146.issue11283@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thinking about the regex pattern again. The example given is not really wrong. It does what it claims to match, that is '<user at example.com>' and 'user at example.com' and reject <user at example.com' kind of string. Nothing is said about 'user at example.com>' kind of string. 

Also, this is not an example of validating an email address or finding an email address pattern in text data. A good regex for that purposes would be more complex[1][2].

Having said that, if example of conditional regex has been given - the current one is sufficient (in which case no change is required) or a simpler one can be presented, which may not like matching a email address and thus devoid of any expectations of valid patterns.

Also, if we 'really' think that rejecting 'user at example>' is good idea in the example documentation, then having '$' in no-pattern of regex is good enough. No need to think for regex search cases for the explanation given about.


1: http://www.regular-expressions.info/email.html
2: http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11283>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:41:52 2011
From: report at bugs.python.org (=?utf-8?b?T251ciBLw7zDp8O8aw==?=)
Date: Mon, 28 Feb 2011 09:41:52 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1298886112.51.0.454118770303.issue10524@psf.upfronthosting.co.za>


Onur K???k <onur at pardus.org.tr> added the comment:

Is this patch going to be applied ?

 platform.dist() is a function which detects and returns the distribution name and version, and it fails to detect Pardus distribution name and version. Since the attached patch fixes this, this should be considered as a bugfix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Mon Feb 28 10:53:06 2011
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 28 Feb 2011 09:53:06 +0000
Subject: [issue11350] __setitem__()'s problem of dbm.dumb object pointed out
	by comments
In-Reply-To: <1298886786.25.0.421725723062.issue11350@psf.upfronthosting.co.za>
Message-ID: <1298886786.25.0.421725723062.issue11350@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

By reading the Lib/dbm/dumb.py source, there seems to be an distinct problem which is pointed out in comments: the __setitem__() should call self._commit() in order to keep .dat file and .dir file consist.

Here is a piece of comment found at the end of __setitem__():

# Note that _index may be out of synch with the directory
# file now:  _setval() and _addval() don't update the directory
# file.  This also means that the on-disk directory and data
# files are in a mutually inconsistent state, and they'll
# remain that way until _commit() is called.  Note that this
# is a disaster (for the database) if the program crashes
# (so that _commit() never gets called).


And another piece found in __delitem__():

# XXX It's unclear why we do a _commit() here (the code always
# XXX has, so I'm not changing it).  __setitem__ doesn't try to
# XXX keep the directory file in synch.  Why should we?  Or
# XXX why shouldn't __setitem__?


One probable reason I guess is that the self._commit() method which writes the keys information to .dir file is regarded as a slow process, and the __setitem__() is called frequently at most cases while __deltiem__ is not, so calling self._commit() at each __setitem__ could make the program very slow.

But based on the fact that "The dbm.dumb module is not written for speed and is not nearly as heavily used as the other database modules."(found on dbm's library document), maybe correctness is more important than speed.

So I think it should be fixed:

Index: Lib/dbm/dumb.py
===================================================================
--- Lib/dbm/dumb.py	(revision 88674)
+++ Lib/dbm/dumb.py	(working copy)
@@ -196,6 +196,7 @@
             # remain that way until _commit() is called.  Note that this
             # is a disaster (for the database) if the program crashes
             # (so that _commit() never gets called).
+            self._commit()
 
     def __delitem__(self, key):
         if isinstance(key, str):

And the remaining comments can be deleted.

----------
components: Library (Lib)
messages: 129688
nosy: ysj.ray
priority: normal
severity: normal
status: open
title: __setitem__()'s problem of dbm.dumb object pointed out by comments
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11350>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:04:00 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 12:04:00 +0000
Subject: [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>


New submission from Steffen Daode Nurpmeso <sdaoden at googlemail.com>:

Antoine, i made you noisy because you took care about Issue11323.
I'm at r88671 (271057c7c6f3).
I'm opening this because the buildbot URL (thanks) doesn't show
anything about sendfile(2).

12:47 ~/arena/code.extern.repos/py3k.hg $ ./python.exe -Wd -m test.test_os -r -w -v

...
test_headers (__main__.TestSendfile) ... FAIL
test_invalid_offset (__main__.TestSendfile) ... ok
test_offset_overflow (__main__.TestSendfile) ... ok
test_send_at_certain_offset (__main__.TestSendfile) ... ok
test_send_whole_file (__main__.TestSendfile) ... ok
test_trailers (__main__.TestSendfile) ... /Users/steffen/arena/code.extern.repos/py3k.hg/Lib/unittest/case.py:387: ResourceWarning: unclosed file <_io.BufferedReader name='@test_28253_tmp2'>
  function()
ok
test_set_get_priority (__main__.ProgramPriorityTests) ... ok

======================================================================
FAIL: test_headers (__main__.TestSendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1517, in test_headers
    self.assertEqual(total_sent, len(expected_data))
AssertionError: 163840 != 164352

----------------------------------------------------------------------
Ran 92 tests in 0.447s

FAILED (failures=1, skipped=10)
Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1573, in <module>
    test_main()
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1569, in test_main
    ProgramPriorityTests,
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/support.py", line 1187, in run_unittest
    _run_suite(suite)
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/support.py", line 1170, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/Users/steffen/arena/code.extern.repos/py3k.hg/Lib/test/test_os.py", line 1517, in test_headers
    self.assertEqual(total_send, len(expected_data))
AssertionError: 163840 != 164352

----------
components: Library (Lib)
messages: 129689
nosy: pitrou, sdaoden
priority: normal
severity: normal
status: open
title: (test_os) os.sendfile() error
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:13:47 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 12:13:47 +0000
Subject: [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298895227.35.0.0449812619444.issue11351@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

It's about the headers[]:

       def test_headers(self):
            total_sent = 0
            sent = os.sendfile(self.sockno, self.fileno, 0, 4096,
                               headers=[b"x" * 512])
            total_sent += sent
            print("HEADER SENT:", sent)

prints

test_headers (__main__.TestSendfile) ... HEADER SENT: 4096

Well.  'man 2 sendfile' tells me it is supporting headers and
trailers since Darwin 9.0 aka Mac OS X 10.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:14:21 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 28 Feb 2011 12:14:21 +0000
Subject: [issue11352] Buf in cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>


New submission from Pierre Quentel <pierre.quentel at gmail.com>:

Hi,

I wrote a patch for the cgi module in version 3.2rc1 (#4953). Small changes should be done to the documentation of this module to reflect the changes in the module API :

- in section "20.2.2. Using the cgi module"

original text :
"If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as a string. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute:"

proposed new text (for files, value is bytes, not string, and the read() method on file also returns bytes) :
"If a field represents an uploaded file, accessing the value via the value attribute or the getvalue() method reads the entire file in memory as bytes. This may not be what you want. You can test for an uploaded file by testing either the filename attribute or the file attribute. You can then read the data at leisure from the file attribute (the read() and readline() methods will return bytes) :"

- version 3.2 introduced a parameter "encoding" for the FieldStorage constructor, used to decode the bytes received on the HTTP connection for fields other than files. This encoding must the one defined in the HTML document holding the form submitted to the CGI script ; it is usually defined by a meta tag :
<meta http-equiv="Content-type" content="text/html;charset=latin-1">
or by the Content-Type header for this document

I'm not sure where this should be mentioned in the module documentation. Maybe in "20.2.9. Common problems and solutions" for the moment. But there are plans (#11066) to introduce another interface to change the encoding of sys.stdout in the CGI script itself, so another option would be to open a specific section about encodings

Hope it's clear enough
Pierre

----------
assignee: docs at python
components: Documentation
messages: 129691
nosy: docs at python, quentel
priority: normal
severity: normal
status: open
title: Buf in cgi module doc
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11352>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:16:33 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Mon, 28 Feb 2011 12:16:33 +0000
Subject: [issue11352] Bug in cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1298895393.7.0.435409107098.issue11352@psf.upfronthosting.co.za>


Pierre Quentel <pierre.quentel at gmail.com> added the comment:

"bug", not "buf"...

----------
title: Buf in cgi module doc -> Bug in cgi module doc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11352>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:24:28 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Feb 2011 12:24:28 +0000
Subject: [issue5542] Socket is closed prematurely in httplib,
	if server sends response before request body has been sent
In-Reply-To: <1237800550.85.0.782891199129.issue5542@psf.upfronthosting.co.za>
Message-ID: <1298895868.5.0.965194561839.issue5542@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Guy, if the issue you describe in relevant to py3.x or 2.7, can you open a new issue?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5542>
_______________________________________

From report at bugs.python.org  Mon Feb 28 13:31:50 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 12:31:50 +0000
Subject: [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228123141.GA39505@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

posixmodule.c:
	iov_setup():
		IOV[i]: buffer:0x10152b8f0, len:512
		iov_setup() leave ok
	before sendfile: sf=0x7fff5fbfb410, sf.headers=0x10036c780
	sf.headers[0].iov_base=0x10152d950, .iov_len=512
	after sendfile: sbytes=4096

Maybe Mac OS X does not support headers (i'm on Mac OS X 10.6)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:10:31 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 13:10:31 +0000
Subject: [issue1720250] PyGILState_Ensure does not acquires GIL
Message-ID: <1298898631.6.0.682809660577.issue1720250@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the deprecation of PyEval_ReleaseLock in issue10913, should this be closed as "out of date"?

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720250>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:11:46 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Feb 2011 13:11:46 +0000
Subject: [issue11350] __setitem__()'s problem of dbm.dumb object pointed out
	by comments
In-Reply-To: <1298886786.25.0.421725723062.issue11350@psf.upfronthosting.co.za>
Message-ID: <1298898706.7.0.760422367795.issue11350@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you construct a test case that demonstrates the corruption?

----------
nosy: +r.david.murray
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11350>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:14:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Feb 2011 13:14:45 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298865704.15.0.909929934393.issue11342@psf.upfronthosting.co.za>
Message-ID: <4D6B9FC2.8060107@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

So the patch fixes the resource warnings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:15:57 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 13:15:57 +0000
Subject: [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228131546.GA62794@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Did you know that 'sbytes' is not adjusted to match possibly 
existent headers and trailers in posixmodule.c? 
This however is required according to Mac OS X 'man 2 sendfile'.
I'll attach a simple, naive patch for a very intelligent and 
outstanding operating system.

----------
Added file: http://bugs.python.org/file20943/posixmodule.naive-apple-patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________
-------------- next part --------------
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -5867,9 +5867,10 @@
 
 #ifdef HAVE_SENDFILE
 #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__)
-static int
+static off_t
 iov_setup(struct iovec **iov, Py_buffer **buf, PyObject *seq, int cnt, int type)
 {
+    off_t ret = 0;
     int i, j;
     *iov = PyMem_New(struct iovec, cnt);
     if (*iov == NULL) {
@@ -5880,7 +5881,7 @@
     if (*buf == NULL) {
         PyMem_Del(*iov);
         PyErr_NoMemory();
-        return 0;
+        return ret;
     }
 
     for (i = 0; i < cnt; i++) {
@@ -5889,14 +5890,18 @@
             PyMem_Del(*iov);
             for (j = 0; j < i; j++) {
                 PyBuffer_Release(&(*buf)[j]);
-           }
+            }
             PyMem_Del(*buf);
-            return 0;
+            ret ^= ret;
+            return ret;
         }
         (*iov)[i].iov_base = (*buf)[i].buf;
-        (*iov)[i].iov_len = (*buf)[i].len;
-    }
-    return 1;
+        do {    off_t x = (*buf)[i].len;
+                (*iov)[i].iov_len = x;
+                ret += x;
+        } while (0);
+    }
+    return ret;
 }
 
 static void
@@ -5954,10 +5959,15 @@
                 "sendfile() headers must be a sequence or None");
             return NULL;
         } else {
+            off_t i = 0; /* Uninitialized warning */
             sf.hdr_cnt = PySequence_Size(headers);
-            if (sf.hdr_cnt > 0 && !iov_setup(&(sf.headers), &hbuf,
-                    headers, sf.hdr_cnt, PyBUF_SIMPLE))
+            if (sf.hdr_cnt > 0 &&
+                !(i = iov_setup(&(sf.headers), &hbuf,
+                                headers, sf.hdr_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
     if (trailers != NULL) {
@@ -5966,10 +5976,15 @@
                 "sendfile() trailers must be a sequence or None");
             return NULL;
         } else {
+            off_t i = 0; /* Uninitialized warning */
             sf.trl_cnt = PySequence_Size(trailers);
-            if (sf.trl_cnt > 0 && !iov_setup(&(sf.trailers), &tbuf,
-                    trailers, sf.trl_cnt, PyBUF_SIMPLE))
+            if (sf.trl_cnt > 0 &&
+                !(i = iov_setup(&(sf.trailers), &tbuf,
+                                trailers, sf.trl_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
 

From report at bugs.python.org  Mon Feb 28 14:18:35 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 13:18:35 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298899115.8.0.538178238171.issue11351@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso <sdaoden at googlemail.com>:


----------
title: (test_os) os.sendfile() error -> Mac OS X os.sendfile()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:24:22 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Mon, 28 Feb 2011 13:24:22 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298899462.82.0.275076620422.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Patch attached.

----------
Added file: http://bugs.python.org/file20944/smtp_lib_source_address.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:25:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Feb 2011 13:25:13 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1298886112.51.0.454118770303.issue10524@psf.upfronthosting.co.za>
Message-ID: <4D6BA233.2000704@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Marc-Andr? already approved it; he must just have lacked time.  We?re
all volunteers with a lot of bugs on our radar, so thanks for the reminder.

Marc-Andr?: I can commit this if you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:25:16 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Mon, 28 Feb 2011 13:25:16 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298899516.69.0.819946001967.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

oops...

----------
Added file: http://bugs.python.org/file20945/smtp_lib_source_address.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:26:56 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Feb 2011 13:26:56 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298899616.54.0.426426618281.issue11348@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We could, however, raise SkipTest if getpriority returns 19 or higher with a message like "unable to reliably test setpriority at current nice level of NN".  My guess is that no system we support has a lower upper limit on nice.  If someone wants to customize the test/message per OS, that would probably be even better; but not, I think, required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:32:10 2011
From: report at bugs.python.org (Paulo Scardine)
Date: Mon, 28 Feb 2011 13:32:10 +0000
Subject: [issue11281] smtplib: add ability to bind to specific source IP
	address/port
In-Reply-To: <1298347855.65.0.0117652407614.issue11281@psf.upfronthosting.co.za>
Message-ID: <1298899930.49.0.859019023993.issue11281@psf.upfronthosting.co.za>


Paulo Scardine <paulo at scardine.com.br> added the comment:

Sorry for the last post, I had the impression that I forgot to attach the patch. I'm slow this Monday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11281>
_______________________________________

From report at bugs.python.org  Mon Feb 28 14:33:00 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Feb 2011 13:33:00 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298899980.52.0.793156996036.issue11348@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

To be clear: raise SkipTest if prio is 19 or above *and* the increment fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:17:46 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 14:17:46 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298902666.43.0.169093131014.issue11351@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Likely explanation is http://bugs.python.org/issue10882#msg129555.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:18:05 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Feb 2011 14:18:05 +0000
Subject: [issue11301] cookielib.LWPCookieJar.save() doesn't save cookies
In-Reply-To: <1298494227.02.0.739636898922.issue11301@psf.upfronthosting.co.za>
Message-ID: <1298902685.61.0.606118745537.issue11301@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11301>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:21:27 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 14:21:27 +0000
Subject: [issue11351] (test_os) os.sendfile() error
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228142024.GA74538@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Before i'm going down, here is the paragraph from 'man 2 sendfile':

  When a header or trailer is specified the value of len returned will
  include the size of header or trailer sent. The user should provide suf-
  ficiently large value of len as argument including the size of header or
  trailer, otherwise only part of file data will be sent following the header.

----------
title: Mac OS X os.sendfile() -> (test_os) os.sendfile() error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:25:51 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 14:25:51 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298902666.43.0.169093131014.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228142411.GB74538@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(But see msg12970.  And the test runs fine with my patch applied.)

On Mon, Feb 28, 2011 at 02:17:46PM +0000, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Likely explanation is http://bugs.python.org/issue10882#msg129555.
> 
> ----------
> nosy: +giampaolo.rodola
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11351>
> _______________________________________

----------
title: (test_os) os.sendfile() error -> Mac OS X os.sendfile()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:32:17 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 14:32:17 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <20110228142411.GB74538@sherwood.local>
Message-ID: <20110228143209.GC74538@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

(Should have been msg129706, sorry.)

P.S.: yes, you're right.
But now: issue 10882 is on adding os.sendfile(), not on fixing 
errors on os.sendfile().  ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:37:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 14:37:16 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298903836.51.0.0360506310736.issue11351@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch is not cleaned up. There are strange things like:

+            ret ^= ret;

(while would you xor an off_t?)

and

+        do {    off_t x = (*buf)[i].len;
+                (*iov)[i].iov_len = x;
+                ret += x;
+        } while (0);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:48:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 14:48:10 +0000
Subject: [issue1720250] PyGILState_Ensure does not acquires GIL
Message-ID: <1298904490.63.0.387876815283.issue1720250@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Given the deprecation of PyEval_ReleaseLock in issue10913, should this 
> be closed as "out of date"?

Indeed :)

----------
resolution:  -> out of date
stage: test needed -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720250>
_______________________________________

From report at bugs.python.org  Mon Feb 28 15:49:29 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 14:49:29 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298903836.51.0.0360506310736.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228144837.GD74538@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

Will this do?  Otherwise feel free to adjust the patch the way 
Python needs it, i'll learn from that, then, for possible future 
things.  (I need to go down now.)

On Mon, Feb 28, 2011 at 02:37:16PM +0000, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Your patch is not cleaned up. There are strange things like:
> 
> +            ret ^= ret;
> 
> (while would you xor an off_t?)
> 
> and
> 
> +        do {    off_t x = (*buf)[i].len;
> +                (*iov)[i].iov_len = x;
> +                ret += x;
> +        } while (0);

----------
keywords: +patch
Added file: http://bugs.python.org/file20946/issue11351.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________
-------------- next part --------------
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -5867,10 +5867,11 @@
 
 #ifdef HAVE_SENDFILE
 #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__)
-static int
+static off_t
 iov_setup(struct iovec **iov, Py_buffer **buf, PyObject *seq, int cnt, int type)
 {
     int i, j;
+    off_t len, ret = 0;
     *iov = PyMem_New(struct iovec, cnt);
     if (*iov == NULL) {
         PyErr_NoMemory();
@@ -5880,7 +5881,7 @@
     if (*buf == NULL) {
         PyMem_Del(*iov);
         PyErr_NoMemory();
-        return 0;
+        return ret;
     }
 
     for (i = 0; i < cnt; i++) {
@@ -5889,14 +5890,17 @@
             PyMem_Del(*iov);
             for (j = 0; j < i; j++) {
                 PyBuffer_Release(&(*buf)[j]);
-           }
+            }
             PyMem_Del(*buf);
-            return 0;
+            ret = 0;
+            return ret;
         }
         (*iov)[i].iov_base = (*buf)[i].buf;
-        (*iov)[i].iov_len = (*buf)[i].len;
-    }
-    return 1;
+        len = (*buf)[i].len;
+        (*iov)[i].iov_len = len;
+        ret += len;
+    }
+    return ret;
 }
 
 static void
@@ -5954,10 +5958,15 @@
                 "sendfile() headers must be a sequence or None");
             return NULL;
         } else {
+            off_t i = 0; /* Uninitialized warning */
             sf.hdr_cnt = PySequence_Size(headers);
-            if (sf.hdr_cnt > 0 && !iov_setup(&(sf.headers), &hbuf,
-                    headers, sf.hdr_cnt, PyBUF_SIMPLE))
+            if (sf.hdr_cnt > 0 &&
+                !(i = iov_setup(&(sf.headers), &hbuf,
+                                headers, sf.hdr_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
     if (trailers != NULL) {
@@ -5966,10 +5975,15 @@
                 "sendfile() trailers must be a sequence or None");
             return NULL;
         } else {
+            off_t i = 0; /* Uninitialized warning */
             sf.trl_cnt = PySequence_Size(trailers);
-            if (sf.trl_cnt > 0 && !iov_setup(&(sf.trailers), &tbuf,
-                    trailers, sf.trl_cnt, PyBUF_SIMPLE))
+            if (sf.trl_cnt > 0 &&
+                !(i = iov_setup(&(sf.trailers), &tbuf,
+                                trailers, sf.trl_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
 

From report at bugs.python.org  Mon Feb 28 16:13:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 15:13:43 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298894639.33.0.0182835623383.issue11351@psf.upfronthosting.co.za>
Message-ID: <1298906023.12.0.283851478426.issue11351@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> giampaolo.rodola
nosy: +rosslagerwall
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:31:58 2011
From: report at bugs.python.org (David)
Date: Mon, 28 Feb 2011 16:31:58 +0000
Subject: [issue11353] Python 2.7.1 cannot be built by 2.x baselines of Python
In-Reply-To: <1298910718.29.0.514753176943.issue11353@psf.upfronthosting.co.za>
Message-ID: <1298910718.29.0.514753176943.issue11353@psf.upfronthosting.co.za>


New submission from David <w004dal at xsmail.com>:

I tried to download and install the latest Python tarball (2.7.1) and use Python 2.6 to execute "setup.py".

I got the error "No module named sysconfig" when running setup.py. "sysconfig" was introduced with Python 3.2 (per http://docs.python.org/dev/library/sysconfig.html).

I am running Ubuntu 10.04.2 LTS and Python 2.6 trying to update to 2.7.x since Django does not support Python 3.x. It seems like a lot of trouble to install Python 3.x to downgrade to the Python version I need.

Recommend providing deb source packages that can be built on Ubuntu 10.04 and 10.10, or fixing this bug.

----------
components: Build
messages: 129712
nosy: w004dal
priority: normal
severity: normal
status: open
title: Python 2.7.1 cannot be built by 2.x baselines of Python
type: compile error
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11353>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:37:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 16:37:09 +0000
Subject: [issue11353] Python 2.7.1 cannot be built by 2.x baselines of Python
In-Reply-To: <1298910718.29.0.514753176943.issue11353@psf.upfronthosting.co.za>
Message-ID: <1298911029.61.0.690242746781.issue11353@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The way to build Python is to run "./configure" followed by "make". This is explained in the README.

----------
nosy: +barry, pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11353>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:51:35 2011
From: report at bugs.python.org (=?utf-8?q?Wojciech_Mu=C5=82a?=)
Date: Mon, 28 Feb 2011 16:51:35 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>


New submission from Wojciech Mu?a <wojciech_mula at poczta.onet.pl>:

Hi, sometimes it is needed to grab variable, but limited, number of options.
For example --point could accept 2, 3 or 4 values: (x,y) or (x,y,z) or
(x,y,z,w). Current version of argparse requires postprocessing:

	parser.add_argument('--point', action='append', default=[])
	nmps = parser.parse_args()
	if not (2 <= len(nmsp.point) <= 4):
		raise argparse.ArgumentTypeError("--point expects 2, 3 or 4 values")

I propose to allow pass range of options count to nargs, including
lower/upper bound. For example:
	
	parser.add_argument('--point', nargs=(2,4) )	# from 2 to 4
	parser.add_argument('--foo', nargs=(9, None) )	# at least 9
	parser.add_argument('--bar', nargs=(None, 7) )	# at most 7
	nmsp = parser.parse_args()

I've attached tests and patch made against Python3.2 lib from Debian.

w.

----------
components: Library (Lib)
files: argparse-nargs.patch
keywords: patch
messages: 129714
nosy: wm
priority: normal
severity: normal
status: open
title: argparse: nargs could accept range of options count
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20947/argparse-nargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:52:28 2011
From: report at bugs.python.org (=?utf-8?q?Wojciech_Mu=C5=82a?=)
Date: Mon, 28 Feb 2011 16:52:28 +0000
Subject: [issue11354] argparse: nargs could accept range of options count
In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za>
Message-ID: <1298911948.0.0.616295213269.issue11354@psf.upfronthosting.co.za>


Wojciech Mu?a <wojciech_mula at poczta.onet.pl> added the comment:

tests

----------
Added file: http://bugs.python.org/file20948/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11354>
_______________________________________

From report at bugs.python.org  Mon Feb 28 17:54:03 2011
From: report at bugs.python.org (LW)
Date: Mon, 28 Feb 2011 16:54:03 +0000
Subject: [issue11342] ResourceWarning: unclosed file <_io.TextIOWrapper
In-Reply-To: <1298756342.35.0.600188157912.issue11342@psf.upfronthosting.co.za>
Message-ID: <1298912043.13.0.0189952380371.issue11342@psf.upfronthosting.co.za>


LW <cjejuni2000 at yahoo.com> added the comment:

only the sysconfig.py was patched, the rest were "reject'ed." no compilation yet at this time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11342>
_______________________________________

From report at bugs.python.org  Mon Feb 28 19:41:29 2011
From: report at bugs.python.org (Ryan Coyner)
Date: Mon, 28 Feb 2011 18:41:29 +0000
Subject: [issue8728] 2.7 regression in httplib.py: AttributeError: 'NoneType'
	object has no attribute 'makefile'
In-Reply-To: <1273960882.3.0.07398568579.issue8728@psf.upfronthosting.co.za>
Message-ID: <1298918489.41.0.748490436239.issue8728@psf.upfronthosting.co.za>


Changes by Ryan Coyner <rcoyner at gmail.com>:


----------
nosy: +rcoyner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8728>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:20:23 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Feb 2011 19:20:23 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1298920823.13.0.989730901779.issue8594@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r88679.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8594>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:22:55 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Mon, 28 Feb 2011 19:22:55 +0000
Subject: [issue11351] Mac OS X os.sendfile()
In-Reply-To: <1298903836.51.0.0360506310736.issue11351@psf.upfronthosting.co.za>
Message-ID: <20110228191750.GA1580@sherwood.local>


Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

This version uses Py_ssize_t for the lengths and seems to be more 
Python-style beside that, too. 
It compiles clean and the test is ok.

----------
Added file: http://bugs.python.org/file20949/issue11351-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11351>
_______________________________________
-------------- next part --------------
diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -5867,36 +5867,42 @@
 
 #ifdef HAVE_SENDFILE
 #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__)
-static int
+static Py_ssize_t
 iov_setup(struct iovec **iov, Py_buffer **buf, PyObject *seq, int cnt, int type)
 {
     int i, j;
+    Py_ssize_t blen, total = 0;
+
     *iov = PyMem_New(struct iovec, cnt);
     if (*iov == NULL) {
         PyErr_NoMemory();
-        return 0;
-    }
+        return total;
+    }
+
     *buf = PyMem_New(Py_buffer, cnt);
     if (*buf == NULL) {
         PyMem_Del(*iov);
         PyErr_NoMemory();
-        return 0;
+        return total;
     }
 
     for (i = 0; i < cnt; i++) {
-        if (PyObject_GetBuffer(PySequence_GetItem(seq, i), &(*buf)[i],
-                type) == -1) {
+        if (PyObject_GetBuffer(PySequence_GetItem(seq, i),
+                               &(*buf)[i], type) == -1) {
             PyMem_Del(*iov);
             for (j = 0; j < i; j++) {
                 PyBuffer_Release(&(*buf)[j]);
-           }
+            }
             PyMem_Del(*buf);
-            return 0;
+            total = 0;
+            return total;
         }
         (*iov)[i].iov_base = (*buf)[i].buf;
-        (*iov)[i].iov_len = (*buf)[i].len;
-    }
-    return 1;
+        blen = (*buf)[i].len;
+        (*iov)[i].iov_len = blen;
+        total += len;
+    }
+    return total;
 }
 
 static void
@@ -5954,10 +5960,15 @@
                 "sendfile() headers must be a sequence or None");
             return NULL;
         } else {
+            Py_ssize_t i = 0; /* Avoid uninitialized warning */
             sf.hdr_cnt = PySequence_Size(headers);
-            if (sf.hdr_cnt > 0 && !iov_setup(&(sf.headers), &hbuf,
-                    headers, sf.hdr_cnt, PyBUF_SIMPLE))
+            if (sf.hdr_cnt > 0 &&
+                !(i = iov_setup(&(sf.headers), &hbuf,
+                                headers, sf.hdr_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
     if (trailers != NULL) {
@@ -5966,10 +5977,15 @@
                 "sendfile() trailers must be a sequence or None");
             return NULL;
         } else {
+            Py_ssize_t i = 0; /* Avoid uninitialized warning */
             sf.trl_cnt = PySequence_Size(trailers);
-            if (sf.trl_cnt > 0 && !iov_setup(&(sf.trailers), &tbuf,
-                    trailers, sf.trl_cnt, PyBUF_SIMPLE))
+            if (sf.trl_cnt > 0 &&
+                !(i = iov_setup(&(sf.trailers), &tbuf,
+                                trailers, sf.trl_cnt, PyBUF_SIMPLE)))
                 return NULL;
+#ifdef __APPLE__
+            sbytes += i;
+#endif
         }
     }
 

From report at bugs.python.org  Mon Feb 28 20:27:43 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Feb 2011 19:27:43 +0000
Subject: [issue11348] test_os: test_set_get_priority() fails when high
	niceness is set
In-Reply-To: <1298841621.88.0.37486577556.issue11348@psf.upfronthosting.co.za>
Message-ID: <1298921263.54.0.142184444007.issue11348@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Committed in r88680.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11348>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:30:15 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 28 Feb 2011 19:30:15 +0000
Subject: [issue8594] Add a "source_address" option to ftplib
In-Reply-To: <1272745982.51.0.743868524528.issue8594@psf.upfronthosting.co.za>
Message-ID: <1298921415.0.0.176741177919.issue8594@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8594>
_______________________________________

From report at bugs.python.org  Mon Feb 28 20:40:38 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 19:40:38 +0000
Subject: [issue11355] os.mkdir() and os.mkdirat() don't apply SUID/SGID
	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

os.mkdir() and os.mkdirat() use libc's mkdir() and mkdirat(), which can ignore SUID/SGID permissions. This problem occurs at least on systems using glibc. The solution is to call chmod() / fchmodat() to ensure that given directory has been created with requested permissions. I'm attaching the patch.

----------
files: python-mkdir.patch
keywords: patch
messages: 129720
nosy: Arfrever
priority: normal
severity: normal
status: open
title: os.mkdir() and os.mkdirat() don't apply SUID/SGID permissions
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20950/python-mkdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11355>
_______________________________________

From report at bugs.python.org  Mon Feb 28 21:13:05 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Feb 2011 20:13:05 +0000
Subject: [issue11355] os.mkdir() and os.mkdirat() don't apply SUID/SGID
	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298923985.32.0.237258694301.issue11355@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11355>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:24:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 21:24:51 +0000
Subject: [issue11355] os.mkdir() and os.mkdirat() don't apply SUID/SGID
	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298928291.43.0.684119462305.issue11355@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The new patch restores respecting of umask.

----------
Added file: http://bugs.python.org/file20951/python-mkdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11355>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:25:45 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 21:25:45 +0000
Subject: [issue11355] os.mkdir() and os.mkdirat() don't apply SUID/SGID
	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298928345.71.0.0254375290147.issue11355@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


Removed file: http://bugs.python.org/file20950/python-mkdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11355>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:43:36 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 21:43:36 +0000
Subject: [issue11355] os.mkdir() and os.mkdirat() don't apply SUID/SGID
	permissions
In-Reply-To: <1298922038.05.0.695997862178.issue11355@psf.upfronthosting.co.za>
Message-ID: <1298929416.89.0.842334424532.issue11355@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

A side effect of this patch is that it fixes failure of test_exist_ok_existing_directory() from test_os.py in situation when top-level directory of Python sources has SGID bit set. (test_exist_ok_existing_directory() exists only in Python >=3.2.)

$ chmod g+s .
$ LD_LIBRARY_PATH=$(pwd) ./python Lib/test/test_os.py
...
======================================================================
ERROR: test_exist_ok_existing_directory (__main__.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_os.py", line 653, in test_exist_ok_existing_directory
    os.makedirs(path, mode=mode, exist_ok=True)
  File "/var/tmp/portage/dev-lang/python-3.3_pre20110227/work/python-3.3_pre20110227/Lib/os.py", line 152, in makedirs
    mkdir(name, mode)
OSError: [Errno 17] File exists: '@test_32218_tmp/dir1'

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11355>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:56:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Feb 2011 21:56:37 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298875299.39.0.389181240848.issue11347@psf.upfronthosting.co.za>
Message-ID: <4D6C1A14.6020203@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The -hl -> -h part seems correct though.

Indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 22:57:50 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Feb 2011 21:57:50 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298838388.1.0.376759565651.issue11347@psf.upfronthosting.co.za>
Message-ID: <1298930270.98.0.593292336807.issue11347@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

"Having the soname be libpython3 is the whole point of the library": I think that the point of this library is "libpython3.so" filename, not soname. Everything should still work if libpython3.so had no soname at all.

(If somebody has installed unpatched Python 3.2, then ldconfig will create llibpython3.so symlink (e.g. /usr/lib/llibpython3.so) and linker will hardcode dependency on llibpython3.so in generated libraries/executables during linking against libpython3.so (e.g. when -lpython3 has been specified).)

(I will work on improved patch for -Wl,--no-as-needed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:04:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 28 Feb 2011 22:04:53 +0000
Subject: [issue11347] libpython3.so: Broken soname and linking
In-Reply-To: <1298930270.98.0.593292336807.issue11347@psf.upfronthosting.co.za>
Message-ID: <4D6C1C03.4070105@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "Having the soname be libpython3 is the whole point of the library":
> I think that the point of this library is "libpython3.so" filename,
> not soname. Everything should still work if libpython3.so had no
> soname at all.

IIUC, the linker will hard-code the full path name (include directory
name) into DT_NEEDED if the shared library has no soname. That would
be undesirable - the DT_NEEDED reference must be just the file name,
not the full path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11347>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:07:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Feb 2011 22:07:26 +0000
Subject: [issue11140] threading.Lock().release() raises _thread.error,
	not RuntimeError
In-Reply-To: <1297092927.55.0.763535906906.issue11140@psf.upfronthosting.co.za>
Message-ID: <1298930846.01.0.558394817234.issue11140@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r88682, thank you!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11140>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:14:42 2011
From: report at bugs.python.org (Charles-Francois Natali)
Date: Mon, 28 Feb 2011 22:14:42 +0000
Subject: [issue11341] test_os fails
In-Reply-To: <1298758905.8.0.691563693808.issue11341@psf.upfronthosting.co.za>
Message-ID: <AANLkTin=55H1TO+ryWxDdWuwbeVHTE_miBObFwZT7Yh-@mail.gmail.com>


Charles-Francois Natali <neologix at free.fr> added the comment:

Alright, digging a little further, it's a kernel bug introduced by this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a3956c790290efeb647bbb0c3a90476bb57800e

Note that this should only affect 64-bit systems (comparison between
long long int and unsigned long int). Also, it's only present since
2.6.37.

It has been fixed by this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cccb5a1e698535fa5a734ffe21c7061c97f8d8c5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11341>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:25:13 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 22:25:13 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298931913.31.0.809188226469.issue11349@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In that case, the request should probably read "_pickle should implement the module finalisation protocol, and module finalisation should be designed so that doing so isn't a recipe for segfaults".

It strikes me as being very similar to the existing problems we have with modules setting everything to None during shutdown, so my estimation of the difficulty of this request has risen accordingly :P

----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11349>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:30:45 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Feb 2011 22:30:45 +0000
Subject: [issue11356] Include module name on ImportError
In-Reply-To: <1298932245.21.0.726100579882.issue11356@psf.upfronthosting.co.za>
Message-ID: <1298932245.21.0.726100579882.issue11356@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Catching ImportError in order to switch to an alternate implementation can mask real failures in imported modules. Attaching the module name as an attribute would allow this to be handled correctly by doing something like:

try:
 import simplejson
except ImportError as err:
 if err.module_name != 'simplejson':
   raise
 <backup plan>

See http://mail.python.org/pipermail/python-ideas/2011-February/009209.html

----------
components: Interpreter Core
messages: 129729
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Include module name on ImportError
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11356>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:43:41 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Feb 2011 22:43:41 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1298933021.94.0.0546494610143.issue11349@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It's a chicken and egg problem because proper module finalization techniques like #812369 are bogged down by static globals in extension modules, and proper state storage in modules is prevented by proper module finalization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11349>
_______________________________________

From report at bugs.python.org  Mon Feb 28 23:52:29 2011
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 28 Feb 2011 22:52:29 +0000
Subject: [issue11356] Include module name on ImportError
In-Reply-To: <1298932245.21.0.726100579882.issue11356@psf.upfronthosting.co.za>
Message-ID: <1298933549.36.0.459830240863.issue11356@psf.upfronthosting.co.za>


Changes by Ram Rachum <cool-rr at cool-rr.com>:


----------
nosy: +cool-RR

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11356>
_______________________________________